Drop rules restated in skills' Don't lists (ports SkillOpt epochs); hone back under budget

CHANGELOG.md

@@ -2,6 +2,10 @@
 
 ## [Unreleased]
 
+### Changed
+
+- Drop "Don't do this" items and sentences that restate a rule already given in its own section of the same skill (forge, anvil, temper, quench, hone), and merge temper's and hone's Convergence Rule and Iteration Cap sections. No rule is removed; hone is back within the 260-line prompt budget, so `./install.sh eval` scores 100 ([#31](https://github.com/forkrul/damascus_development/pull/31))
+
 ## [0.1.1] - 2026-10-17
 
 ### Changed

skills/anvil/SKILL.md

@@ -107,18 +107,13 @@ If `vendor/spec-kit/` is empty, the submodule is not initialized — run `git su
 
 ## Refusal Behavior
 
-If you skip the precondition check and start drafting `spec.md` without verifying the PRD, the artifact will be wrong and `temper` will catch it. Don't.
-
 If the user pushes you to skip the PRD ("just make me a spec"), explain: forging is a 5-minute step that prevents 50 minutes of rework. Then offer: forge → anvil in one go.
 
 ## Don't do this
 
-- **Don't generate spec/plan/tasks in parallel.** Order matters: spec → plan → tasks. Later artifacts derive from earlier ones; reversing leaks information.
 - **Don't write code or pseudocode in any of the three artifacts.** Tasks reference file paths and describe steps; they do not contain implementation. Code belongs to `quench`.
-- **Don't paper over PRD gaps with assumptions inside spec.md.** If a question only emerges here, return to the PRD, fix it, then resume. Otherwise the gap propagates downstream.
 - **Don't skip the FR ↔ task mapping check.** Every FR and `INV-NNN` safeguard must map to ≥1 task; every task must declare which FR(s)/INV(s) it satisfies. An unmapped FR will be invisible during temper.
 - **Don't invent your own task ID scheme.** Use `T001, T002, …`; downstream stages (temper, smithy) parse this format.
-- **Don't invoke `superpowers:writing-plans`.** It is DENY-listed. Use anvil's spec-kit path (slash commands or vendored templates) instead.
 - **Don't proceed to temper without committing the artifacts.** Uncommitted artifacts mean temper might iterate on stale state.
 
 ## Gate to Next Stage

skills/forge/SKILL.md

@@ -140,7 +140,6 @@ Copy this into the new PRD file and elicit answers from the user section by sect
 - **Don't write FRs, SCs, or tasks here.** Those belong to `anvil`. Forge produces a PRD, full stop. If you find yourself writing FR-001, you have crossed a stage boundary.
 - **Don't merge multiple ideas into one PRD.** One feature = one PRD. If the user mixes "and also we should…", create a second PRD.
 - **Don't proceed to anvil without explicit user confirmation.** Forge halts; the user starts anvil.
-- **Don't invoke `superpowers:brainstorming`.** It is DENY-listed. Use forge's REASONS Canvas elicitation instead.
 
 ## Gate to Next Stage
 

skills/hone/SKILL.md

@@ -97,8 +97,6 @@ as **BLOCKING** (would be wrong to merge) or **NIT** (cosmetic), each with `file
 A BLOCKING finding must show how it fails — a failing test, a repro input, or a command
 and its output. A suspicion the critic couldn't show is **UNCONFIRMED**, with where it
 looked and what it couldn't check.
-"Looks good" with no findings requires the critic to show its procedure's artifact and
-state what it tried and failed to break. Opinions without the artifact are discarded.
 
 ### 2. Adjudicate — judge (single, blind)
 
@@ -200,11 +198,10 @@ Return:
 | **A+** | Tight; first zero-blocking round ($D_B = 0$, clean pass 1 of 2) |
 | **A++** | Two consecutive zero-blocking rounds ($D_B = 0$) — nothing left a reviewer would block a merge on |
 
-## Convergence Rule
+## Convergence Rule and Cap
 
-**A++ requires two consecutive rounds with zero BLOCKING findings ($D_B = 0$).** A single clean
-round earns at most A+; the second confirms the first wasn't luck. A round capped by the
-BLOCKING overlap signal ($D_B \ge 4$ and $m_B/D_B < 25\%$) cannot count as clean. Disjoint NITs never cap a round when $D_B = 0$.
+**A++ requires two consecutive rounds with zero BLOCKING findings ($D_B = 0$).** A single clean round
+earns at most A+; the second confirms the first wasn't luck. A round capped by the overlap signal cannot count as clean.
 
 **A round that carries an UNCONFIRMED forward is not clean.** The next round's targeted
 check must settle it: shown (BLOCKING) or not reproduced (killed, with the check's output
@@ -213,8 +210,6 @@ your call.
 
 **A round is clean only if the previous round's fixes were verified by `damascus revert-proof` + `damascus proof-coverage` and were in the diff its critics reviewed.** Zero blocking findings against code nobody looked at is not a signal. This is the same principle as the overlap cap: the rating measures what the panel *examined*, not what it happened to return.
 
-## Iteration Cap
-
 **Maximum 3 rounds**, then escalate to the user with the stuck findings. Quench's
 mechanical gates already caught what tools can catch; three rounds of human-shaped
 review that fail to converge usually mean an upstream problem — an under-specified
@@ -224,22 +219,11 @@ spec (back to `temper`) or an oversized task (back to `anvil`).
 
 - **Don't review the diff yourself in the main session.** You (or your subagents) wrote
   this code; fresh critics without the authoring context are the point.
-- **Don't let a fix touch a test file.** The freeze from quench holds. If a finding says
-  a test is wrong, that's a spec conversation (Golden Rule), not a hone edit.
 - **Don't fix beyond the findings.** Refactor-while-you're-in-there at this stage is
   scope creep on green code; put it in the log as a NIT for a future feature.
-- **Don't treat a green suite as evidence a fix worked.** It was green before the fix and
-  it is green after; that is a statement about the tests, not the repair. Revert the fix
-  and watch the test fail, or you have not checked anything.
-- **Don't let the author of a fix be its only reviewer.** Same rule as the diff itself,
-  and for the same reason — a repair inherits every blind spot that produced the defect.
-- **Don't review a unit larger than ~400 changed lines.** Split by task/commit first.
-- **Don't accept conformance findings without the FR → file:line trace** (nor any
-  critic's finding without its procedure artifact). Evidence, not vibes.
 - **Don't merge on A or A+.** A++ is the gate, same as temper. Tempted to ship at A+
   means the convergence rule caught something; stop and escalate.
 - **Don't edit `code-review.md` retroactively.** Append-only, like `review.md`.
-- **Don't invoke `superpowers:requesting-code-review`.** It is DENY-listed; hone replaces it.
 
 ## Refusal Behavior
 
@@ -269,7 +253,6 @@ Hone's findings split cleanly under the Golden Rule: code that diverges from the
 - Reads the diff produced by `quench` (via `quench-log.md`'s per-task record)
 - Critics/judge dispatch via `damascus agent-run` or the session's subagent mechanism; pairs with `superpowers:dispatching-parallel-agents` (KEEP)
 - Applies findings with the posture of `superpowers:receiving-code-review` (KEEP)
-- Hands off to `superpowers:finishing-a-development-branch` (KEEP) for merge/PR
 
 ## References
 

skills/quench/SKILL.md

@@ -163,11 +163,6 @@ For a non-Python host, dispatch a general subagent with the corresponding agent
 - **Don't write implementation code without a failing test in front of you.** No exceptions. If you find yourself about to "just add this small thing", stop and write the test first.
 - **Don't dispatch all the agents at once.** The cycle inside a task is sequential, and only `[P]` tasks run side by side, each in its own worktree and merged one at a time (see Parallel Tasks). Never run a task in parallel with a task anvil didn't tag `[P]`.
 - **Don't mark a task complete until BDD + unit tests + (Playwright, if UX) all pass.** Partial green is not green.
-- **Don't invoke `superpowers:executing-plans`.** It is DENY-listed. Use quench's BDD-first / red-amber-green discipline.
-- **Don't silently downgrade red-amber-green to red-green.** If you find yourself doing it, you've slipped into upstream `test-driven-development` mode. Re-read this skill's Cycle table.
-- **Don't edit a test after amber without a spec/tasks change first.** Weakened assertions are how broken code reaches green. The freeze is the contract; exceptions go through the Golden Rule and into the quench log.
-- **Don't gate on coverage %.** Report it in the log; gate on mutation survivors and FR ↔ test traceability instead.
-- **Don't rerun a flaky test until it passes.** A flake is red. Fix the root cause or the task isn't done.
 
 ## Refusal Behavior
 

skills/temper/SKILL.md

@@ -169,25 +169,21 @@ Return:
 | **A+** | Tight; SCs measurable & non-vacuous; first 0-BLOCKING round |
 | **A++** | Two consecutive 0-BLOCKING rounds; implementer needs zero clarifications |
 
-## Convergence Rule
+## Convergence Rule and Cap
 
 **A++ requires two consecutive rounds with zero BLOCKING findings ($D_B = 0$).** A single clean round earns at most A+ — the second consecutive clean round confirms the first wasn't luck and upgrades to A++. This is loop-until-dry, not loop-until-lucky.
 
 **A round that carries an UNCONFIRMED forward is not clean.** The next round's targeted check must settle it: shown (BLOCKING) or not reproduced (killed, with the check's result in the log). One logged as open does not block convergence; the gate lists it under Needs your call.
 
 The stratified BLOCKING overlap signal feeds this rule: when $D_B \ge 4$ and $m_B / D_B < 25\%$, the round is capped at B+ — the critics' blocking finding sets are near-disjoint, so the pool of undiscovered defects is larger than the pool they surfaced, whatever the blocking count says — and a capped round can never count as clean. When $D_B = 0$, NIT overlap never caps the grade.
 
-## Iteration Cap
-
 **Maximum 5 rounds**, then escalate to the user with the stuck findings. If 5 rounds fail to converge, the bottleneck is usually upstream — return to `anvil` (or even `forge`) to fix the underlying ambiguity. **Don't grind temper indefinitely.**
 
 ## Don't do this
 
 - **Don't review the triplet yourself in the main session.** The adversarial separation is the point: critics must be fresh subagents without your authoring context, or they inherit your blind spots.
 - **Don't run fewer than 3 critics or merge the lenses.** Diverse lenses catch failure modes redundancy can't.
-- **Don't accept findings without their procedure artifacts.** The re-derivation, the trace, the test skeletons — the artifact is what separates evidence from critic theater.
 - **Don't accept critiques uncritically.** The judge kills manufactured objections; you may also reject a finding — but only explicitly, in the log, with reasoning. Silent partial application leaves the spec worse than before.
-- **Don't run more than 5 rounds.** If A++ isn't reached, the problem is upstream. Return to `anvil` or `forge`.
 - **Don't edit the review log retroactively.** Append-only. Past rounds are evidence of how the spec evolved.
 - **Don't proceed to quench on an A or A+.** A++ is the gate. If you're tempted to ship at A+, the convergence rule caught a real problem; stop and escalate.
 - **Don't let critics rewrite the user's prose.** Findings are pointers; apply fixes preserving the author's voice.