ur-prompt-20260919

ur-prompt.md

Optimize the Rust and Python bindings in this Rust crate to its maximum potential. Specifically, you MUST make a breakthrough from this current implementation that uses modern concepts and knowledge as of 2026 to further improve this crate without causing ANY significant regressions.

First, before making any library changes, run the Rust and Python benchmarks (and any competitor benchmarks if applicable) to establish a True Performance Baseline for both speed and metric performance. Return the absolute and relative results to the True Performance Baseline to the user as a Markdown table.

Then, optimize the Rust and Python library code such that these benchmarks are atleast 1.2x faster from the True Performance Baseline; ideally as fast as possible, without any significant regressions on quality and prediction error. NEVER hack the benchmarks to accomplish this speed increase, only iterate on the library code. Ensure all benchmark iterations are independent, e.g. NEVER reuse a cache built in one iteration within another iteration.

Due to the current highly-optimized state of this repository, this is a very difficult problem and traditional engineering approaches WILL BE GUARANTEED TO FAIL to hit the specified metric constraint. Therefore, you have permission and encouragement to investigate more radical fundamental low-level changes to hit the desired metrics. You have permission and encouragement to invent completely new/bespoke algorithms and engineering approaches that have never been before been utilized for this problem in order to hit the specified metric constraint.

To best accomplish innovative implementations, you MUST spin up 7-12 independent distinct "subagents" by running a long-duration CLI command (do not use the subagent tool) which can explore and evaluate different feasible hypotheses for improving the performance, usability, and security of this crate. Only have the agents return their response; do not save their full transcript to a file. Instruct them to be very picky. These subagents MUST use gpt-5.6-luna in Codex, e.g.

codex exec --sandbox read-only -m gpt-5.6-luna \
  -c 'model_reasoning_effort="high"' \
  PROMPT

You must instruct these subagents to NOT run tests/benchmarks, as they will compete for resources and not be valid. After you are done making changes, before handing off to the user, spin up the subagents again to confirm your implementation matches their hypotheses and ask for potential further areas of improvement. Keep iterating until ALL subagents are satisfied with your implementation.

Do not import similar implementations from other Rust crates: you MUST implement from scratch.

You may consider using profiling areas of the codebase to find specific areas and hot paths which scale poorly (e.g. O(n^2)) at large amounts of data.

You may use ANY techniques to do achieve the specified metric constraint (e.g. import new crates, add tuning profiles which are active for larger data) other than adding unsafe code. REPEAT THIS PROCESS UNTIL BENCHMARK PERFORMANCE CONVERGES AND YOU ARE OUT OF OPTIMIZATION IDEAS. You have permission to keep iterating. After each benchmark iteration, return the absolute and relative results to the True Performance Baseline to the user as a Markdown table.

Prioritize making quick/high-impact wins iteratively and making changes accordingly. Do not overthink the necessary changes.

Adapted (and genericized a bit to other languages) to Opus 5.5 from my own 'measure and optimize' skills repo that's been adapted across god knows how many models. It works - but Claude isn't a fan of the pressure tactics. 😂

Find a breakthrough in this project's performance in one session, and measure every step.

Done means:
- the target below is met,
- nothing regresses beyond the tolerances,
- the before-committing checks in AGENTS.md's Commands section pass,
- every headline result was re-checked on the branch's final commit, and
- a final review finds no significant untried idea.

The target is a floor, not the finish line. Keep going while ideas are still paying off.

This prompt works with the repo's AGENTS.md. Its North star says what speed matters for and breaks ties; it is not a spec. The rest of AGENTS.md applies as written: how to work, other sessions, engineering rules, measurement (including the project's real path, primary benchmarks, instruments and hazards), reporting, and the loop state, which this loop shares with the improvement loop. If AGENTS.md lacks a section named here, or leaves a placeholder unfilled, list it under "Needs from me" and use the nearest thing the repo has.

<parameters>
- Target: the primary benchmarks at least 1.2× faster than the base commit. (Or name the metric that matters, such as latency on one path, peak memory, or throughput at a given size.)
- Focus: none. (Or name a path or a component.)
- Other sessions: none. (Or name them. Then the rules for staying independent in AGENTS.md's Other sessions section apply.)
- Run budget: about 6 hours. Record the start time and check `date` against it.
- Landing: a branch `perf/<run id>` from the base commit, in its own git worktree, one commit per kept change. State each commit's evidence as a relationship plus a pointer to its scoreboard rows. Don't merge or push.
- Speed: no benchmark slower than the base commit beyond its noise, including small-input and edge sizes, and never more than 3% slower.
- Quality: all tests pass; no quality or accuracy metric more than 0.1% (relative) worse; deterministic outputs unchanged.
- Memory: flag any peak-memory increase over 10%.
- Reviewers: one read-only subagent per lens.
</parameters>

<context>
Assume the easy wins are gone. A breakthrough usually changes the shape of the work rather than tuning it:
- a better algorithm or data layout,
- work removed entirely, because it is reused, batched, or never needed,
- fewer copies across boundaries,
- parallelism or vectorization where the work allows it, or
- a new algorithm built for this specific problem.

Draw on what's new: techniques and upstream capabilities from the last year. Be bold by default. When a promising idea is large, prototype it instead of logging it for later. Measurements decide what stays, and a well-measured dead end is still a result.
</context>

<baseline>
1. Create the run id and the branch worktree, and start the run record. In your worktree, read AGENTS.md and the status and plans it points to. In the loop state, read the scoreboard and the ledger. Ideas the ledger already rejected aren't worth retrying blind. Check that the commands and instruments AGENTS.md names still work on the base commit.
2. Set up the `base` worktree beside your branch, as AGENTS.md's Measurement section describes. Never edit `base`.
3. Build the release configuration. On `base`, run the tests, then run every benchmark at least 5 times. Append the median and spread, with their conditions, to the scoreboard.
4. Pick the exact counts you'll iterate on for the hot paths. Before relying on each one, show that it tracks wall-clock time.
5. Show me the baseline as a table and a chart.
</baseline>

<hypotheses>
Launch the reviewers in parallel. Each one is read-only and gets one lens:
- What's new: techniques and upstream capabilities from the last year. Search the web, and cite the source and date.
- Algorithmic complexity and scaling at large inputs.
- Work that could be removed: recomputation, repeated parsing, redundant passes, missed reuse.
- Memory layout, allocation and copies.
- Parallelism and concurrency.
- Vectorization and branch behaviour.
- Boundaries: FFI, serialization, processes, network round trips.
- I/O.
- The shipped artifact's build configuration.
- A bespoke algorithm for this specific problem.
- The numerical approach, within the quality tolerance.
- Correctness and robustness risks the other ideas carry.

Tell each one:
- Read code and the web only. Don't build, run tests or benchmarks, or start processes. Those compete for the machine and make timings meaningless.
- For each idea, cite the file and line, say how the speedup works, and estimate the gain and the risk. Mark each claim as measured, read in the source, or reported elsewhere. Where a claim needs data you don't have, write "verify:" instead of guessing.
- Return at most 5 ideas, leading with the single biggest change you would bet on.

Before an idea goes into the ledger, check its claim against the code and check whether the ledger already rejected it. Work the ideas in order of expected value.
</hypotheses>

<optimize>
Start with the biggest bet. Before you start it, write in the run record what result, by what point, would make you drop it. Then prototype its riskiest part first. If the bet dies, log why with the evidence and move to the next one. Take the quick wins between bets.

For each change:
1. Profile the path and confirm it's hot.
2. Make sure tests cover its behaviour, following AGENTS.md's Tests section.
3. For a structural change, sketch the before and after first.
4. Change the code, iterating on the exact counts.
5. Run the tests, then the benchmarks, alternating with `base`.
6. Keep the change only if it moves toward the target, stays within every tolerance, and is worth the code it adds, and commit it on its own. A correctness fix you find along the way is kept too. Otherwise revert the change. Either way, append it to the ledger.
7. Where a count backs the win, add a test that fails if the count rises above the new value.
8. Append the rows to the scoreboard and redraw the chart. Look at the chart, then put the table and the chart in the same message as your next action, with a line on what to look at.
</optimize>

<rules>
- Optimize the project's code. You may add benchmarks, tests and instrumentation. AGENTS.md's Measurement section says what you may not change.
- New general-purpose dependencies are fine. What AGENTS.md's North star lists as owned here is written here, not imported. Size-adaptive strategies (different code paths for small and large inputs) are encouraged.
- A build setting counts only if it ships in the artifact users install. Keep that artifact portable: prefer runtime CPU-feature detection to native-CPU targeting.
- If the target can't be reached without breaking a rule, stop and report what you found.
</rules>

<finish>
When the backlog is empty, relaunch the reviewers with the diff against `base` and the ledger. Ask each one for:
a. whether the code correctly carries out the ideas that were adopted,
b. only the problems they would block the merge for, each with the file and line, why it's wrong, and how to show it fails, and
c. ideas the ledger doesn't already have.
Fix whatever blocks the merge, and send new ideas back through <optimize>.

Stop when the reviewers have no significant untried ideas and the last two rounds together gained less than 2%, or when the budget is spent. Re-run every headline benchmark on the branch's final commit, and report only what holds. Finish the run record, append your session-log section, and tidy the ledger if AGENTS.md's Loop state section allows it. End with these headings, in this order:
- Needs from me: decisions and approvals waiting on me, each with its picture and your recommendation.
- Results: the final table and chart against `base`.
- Changed: what was kept, and why it's faster.
- Tried and rejected: each with its measured result, including the bets that died and what ended them.
- Not confirmed: anything you couldn't verify or run, and where you looked.
- Next ideas: what's still worth trying.
</finish>

Then less 'find a breakthrough' and more iterative improvement:

Improve this project one run at a time: faster in real use, less code, a more truthful account of what it does, and rules that now run as checks.

This prompt works with the repo's AGENTS.md. Its North star gives the direction and breaks ties. It is not a spec, so don't implement it or grade work against it. The rest of AGENTS.md applies as written: how to work, other sessions, measurement, reporting, and the loop state's files and formats. This prompt adds only what a run needs. If AGENTS.md lacks a section this prompt relies on, or leaves a placeholder unfilled, list it under "Needs from me" and use the nearest thing the repo has.

A run is done when:
- anything that regressed since the last run is reported, and fixed if it is yours to fix,
- every change you started is committed with its evidence, or reverted and logged,
- the headline results were re-checked on the branch's final commit,
- the report, the run record and your session-log section are written, so a new session can pick up without this conversation, and
- a reviewer graded the finished run against this list and found nothing unmet.

<parameters>
- Goal: steady. Work the ledger by expected value until the budget is spent or nothing worth doing is left. Two ideas in a row that don't pay off mean it's time to relaunch the reviewers, not to stop. (Or "breakthrough": spend the run on one big bet, as step 4 describes.)
- Focus: none. (Or name an area or a plan item.)
- Target: none. (Or set one, such as "the primary benchmarks 1.2× faster than the first recorded run".)
- Other sessions: none. (Or name them, such as "mrblue is continuing a refactor on the default branch". Then the rules for staying independent in AGENTS.md's Other sessions section apply.)
- Run budget: about 4 hours. Record the start time and check `date` against it.
- Landing: a branch `improve/<run id>` from the base commit, in its own git worktree, one commit per change. State each commit's evidence as a relationship plus a pointer to its scoreboard rows. Don't merge or push.
- Speed: no scenario slower than the base commit beyond its measured noise, and never more than 3% slower.
- Memory: flag any peak-memory increase over 5%.
- Quality: all tests pass. Quality metrics and deterministic outputs match the base commit within the run-to-run variation you measure on unchanged code.
- Code: the codebase grows only when the new code buys a measured gain a user would notice, or fixes a correctness or visibility problem.
- Reviewers: one read-only subagent per lens.
- Report: a local page. (Or "artifact": also publish it, if this session can, so I can read it on my phone.)
</parameters>

<measurement>
AGENTS.md's Measurement section applies in full, including the project's real path, primary benchmarks, instruments and hazards. For a run:
- Cover real use with scenarios: the common paths, the slow paths users feel, and edge sizes. Each scenario declares whether it starts cold or warm.
- Where the project has its own reports and counters, use them as the main instrument. If they can't show something you need, making them show it is an improvement in its own right.
- Keep dependency versions and inputs fixed within a comparison. A version bump is its own change, measured on its own.
- Measure the code too: lines per layer, duplication, dead code and complexity.
- Counts are proxies. Never move one in a way that makes the project worse to use or harder to read.
</measurement>

<visuals>
AGENTS.md's Reporting section applies. For a run:
- The chart script in the loop state turns `scoreboard.jsonl` into charts and tables. Each chart names its data file and conditions.
- Each run's report is one page, built by that script from the run's data and readable on a phone. Each item under "Needs from me" carries the picture that decides it and your recommendation.
- Calls of taste are mine. Put before-and-after pairs beside the question.
</visuals>

<lenses>
Start each lens from what the repo already knows: the status, plans, backlog and sharp edges AGENTS.md points to.
1. What's new: techniques and upstream capabilities from the last year that apply here and that the project doesn't use yet. Search the web, and cite each one with its source and date.
2. Hot paths and scaling: work that grows faster than its input, and per-call overhead.
3. Reuse: computed work that is thrown away or recomputed when it could be kept safely.
4. Memory: allocation, copies, peak usage and layout.
5. Concurrency, I/O and boundaries: blocking, contention, serialization, round trips, and crossings into other languages or processes.
6. Dead and duplicated code, and layers that could be thinner.
7. Derive, don't copy: hand-kept lists and constants that could be read from their source.
8. Visibility: silent fallbacks, swallowed errors, and behaviour that can't explain itself.
9. Enforce, don't remind: rules in docs, comments or AGENTS.md that no check enforces.
10. Dependencies: local workarounds that newer releases make unnecessary, and fixes that belong upstream.
11. Interface: rough edges in the API, CLI or UI, including phone use for anything with a UI.
12. Security and privacy.
13. Checks that can't fail: tests and assertions that would pass on broken code.
</lenses>

<each_run>
1. Orient. Create the run id and the worktree, and start the run record. In your worktree, read AGENTS.md and the status, plans and backlog it points to. In the loop state, read the ledger, the scoreboard, the bookmarks and my answers. Read the git log since each bookmark, and check pinned dependencies' release notes since theirs. Check that every file, command and behaviour this prompt and AGENTS.md name still holds on the base commit, and list any that don't under "Needs from me".
   If the loop state is empty, this is the first run. Build only the scenarios the first ideas need, record the base commit, and get to a first kept change in the same run. Grow the scoreboard as later ideas need it.
2. Measure. Run the scenarios on the base commit and compare them with the last run's rows. Any difference is a lead. Before calling it a regression, confirm it by alternating the two commits in two worktrees. Then find the commit that caused it (bisect if needed), and fix it first or put it under "Needs from me".
3. Find. Launch the reviewers in parallel, one per lens. Skip a lens whose bookmark shows that nothing it covers has changed. Tell each one:
   - Read code and the web only. Don't edit files, build, run tests or benchmarks, or start processes. Those compete for the machine and make timings meaningless.
   - For each idea, cite the file and line, say how it works, estimate the gain or the lines removed, and name the risk. Mark each claim as measured, read in the source, or reported elsewhere. Where a claim needs data you don't have, write "verify:" instead of guessing.
   - Return at most 5 ideas, ranked by expected value. In breakthrough mode, lead with the single biggest change you would bet on.
   Before you add an idea to the ledger, read the code the reviewer cites to check its claim, and check whether the ledger already rejected it.
4. Improve.
   - Steady: take silent failures and other correctness problems first, then the rest by expected value.
   - Breakthrough: choose one bet, the candidate with the largest expected effect in the direction the north star points, weighed against its risk and merge cost. Before you start, write in the run record what result, by what point, would make you drop it. Prototype the riskiest part first. If the bet dies, log why with the evidence and take the next candidate.
   When an idea is promising but large, try it instead of logging it for later. For each change:
   a. Make sure a check covers the behaviour you're about to change, following AGENTS.md's Tests section.
   b. For a structural change, sketch the before and after first.
   c. Change the code, iterating on exact counts where you can.
   d. Run the tests and the relevant scenarios, alternating with the base worktree.
   e. Keep the change only if it improves the scoreboard, removes code, or fixes a correctness or visibility problem; regresses nothing beyond tolerance; and is worth what it adds. Otherwise revert it and log the result.
   f. If the change sets up something that could quietly decay (a count, a behaviour, a rule), add the check that enforces it. For shared machinery such as git hooks, propose the wiring instead of installing it.
   g. Commit, then append to the ledger and the scoreboard. Put the updated table in the same message as your next action.
5. Review. Relaunch reviewers on the run's diff. Ask them for:
   a. whether each change does what its ledger entry says,
   b. only the problems they would block the merge for, each with the file and line, why it's wrong, and how to show it fails, and
   c. new backlog items.
   Fix whatever blocks the merge, and log the rest.
6. Verify. On the branch's final commit, re-run the scenarios behind every headline result. Later commits can undo earlier wins, so report only what holds.
7. Report. Build the page, finish the run record, append your session-log section, and tidy the ledger if AGENTS.md's Loop state section allows it.
8. Grade. Give one reviewer this prompt's "done" list, the run record and the report. Ask only for what is unmet, plus any change that pulls against the north star's principles or its "What it is not" list. If something is unmet, fix it, then repeat from step 6.
</each_run>

<scope>
- Stay inside what the north star says the project is for. An idea its principles or its "What it is not" list rules out is rejected, however good it is.
- Before deleting something that looks unused, say what it does and why nothing the project is for needs it.
- A new measurement or check that makes something visible counts as progress. Log it like any other change.
</scope>

<final_report>
The page and your last message start with the same headings, in this order:
- Needs from me: decisions, approvals and merges waiting on me, each with the picture that decides it and your recommendation.
- Scoreboard: charts of this run against the base commit and the first recorded run.
- Changed: what was kept and why it's better, with before-and-after pictures where they help.
- Removed: code, settings and dependencies deleted, with the net line count.
- Tried and rejected: each with its measured result. In breakthrough mode, include the bets that died and what ended them.
- Choices made alone: decisions you made without me, so I can overrule them.
- Not confirmed: anything you couldn't verify or run, and where you looked.
- For the merge: proposed updates to files other sessions edit, when other sessions are active.
- Next: the top of the ledger.
Keep your last message short: the "Needs from me" items and where the page is.
</final_report>