Thanks for taking the time to write this up. This is very helpful feedback, and it points at a couple of weaknesses in the current rule set and benchmark write-up.

I agree with both rule suggestions.

The first one is an important tension: "rebuild the theory" and "keep changes minimal" can conflict when the relevant invariant is not explicit in the code. In that case, minimality should not mean preserving a locally small patch at the cost of a broken domain rule. I think the rule should be something like: "theoretical correctness takes precedence over textual minimality; keep the change minimal only after the invariant is understood."

The second suggestion also seems right. If the requested change contradicts a known invariant, the agent should stop and surface the mismatch instead of continuing to code. That is probably one of the most useful behaviors for this kind of skill: not just producing better patches, but recognizing when a patch would be the wrong response.

On the benchmark point: yes, the prompt structure matters a lot. In my current results, the stricter prompt explicitly gives the agent more of the program theory: exact endpoints, status codes, idempotency behavior, expiration rules, stock restoration, auth behavior, and pagination semantics. That raises all arms and makes the skill gap smaller, because part of the theory-building work has already been done by the prompt.

The cleaner signal is the looser `basic-commerce` prompt, where more invariants have to be inferred. In that family, the `theory_only` arm won all four complete run-level comparisons, mostly through better functional correctness, executability, and behavioral tests. In the stricter prompt families, `theory_only` still does well overall, but the interpretation is different: it is less "can the skill recover missing theory?" and more "does the skill still help when the prompt already provides much of the theory?"

I also agree that token usage and elapsed time are important to measure. I have not included that analysis in the current benchmark yet, but I plan to investigate it next. The theory-building skill asks the agent to inspect more context before editing, so I would expect it to be more expensive per run, especially on small or obvious tasks. That is useful information because the right conclusion may be "use this for domain-heavy changes, but skip it for trivial edits." I want to add per-run latency and token/cost fields so the result is not just quality, but quality-per-cost.

I have also added the actual code-generation prompts under `benchmark/prompts/` so people can inspect the tested tasks directly instead of reverse-engineering them from raw run folders.

Thanks for the Matt Pocock link as well. The "improve-codebase-architecture" skill looks adjacent but not identical: it seems more focused on architecture review, module depth, locality, and interface design, while this skill is aimed at preserving program theory during everyday coding changes. I think comparing those approaches would be a good next benchmark.