freeze-acceptance

name	freeze-acceptance
description	Use after intent is clear and before building anything heavy — break the work into stages, write an acceptance table (expected value × how to verify × measurable/judgment), and freeze it with the human. Part of meta-workflow (Step ②); uses superpowers writing-plans for the breakdown. This is the core asset superpowers does not have.

Step ② — Freeze the acceptance criteria

Why this exists: if you set the bar after seeing the result, you will set it wherever the result landed. Freezing the bar before building is the one thing that makes "lower the bar to pass" detectable instead of invisible.

Done = the table is frozen

Take the three pieces from Step ①, break the work into stages, and for each stage write a row:

## Acceptance Table — <task>  (type: design/build/fix/exploration · frozen on <date>)
| # | Stage | Expected value | How to verify | Nature |
|---|-------|----------------|---------------|--------|
| 1 | …     | what this stage's output must satisfy | who, with what data, doing what | measurable / judgment (anchor: …) |
Cross-stage coupling (if any): stage A × stage B — what constraint / who guarantees it / how it's checked
Task-level bar: which stages are hard gates (no ship if failed) / downgraded items: reason + recovery trigger + owner
Change log: none | <date + what changed + why + human sign-off>

• Expected value comes from: the success criteria from ① + the abstract quality bar instantiated (see references/quality-bar.md) + task-specific requirements.
• How to verify must pass a tool-validity self-check: can this method actually measure this expected value? (Testing a new pipeline against a frozen snapshot of the old one measures nothing — that's a mismatch, not a verification.)
• Nature honestly tagged: judgment rows get a semi-objective anchor; never invent an unmeasurable number just to have a metric.

Freezing

Who/when: end of ②, before ③ starts. You draft, the human confirms — that confirmation is the freeze. Light tasks can be self-drafted, but still shown to the human.

Change after freezing (the anti-lowering rule)

Allowed: align toward truth (the table itself was set wrong). Forbidden: lower the bar because it turned out hard.

Adjudicate with a time anchor: the evidence that a value was wrong must be something that was available when you first set it and got overlooked — an existing baseline, an external constraint. Difficulty discovered during execution, or "I should have checked but didn't," count as can't-do-it, not set-wrong — those don't earn a lower bar; you either ship-with-defect (recorded) or go back to root cause. Every change needs an explicit declaration + reason + human sign-off + a trace in the table.

Relationship to superpowers

Run this after superpowers writing-plans: writing-plans does the stage breakdown, then this skill adds what it doesn't have — the frozen bar per stage and the anti-lowering time anchor.

This ordering also resolves a real clash. superpowers brainstorming ends with a hard rule: "the only skill you invoke next is writing-plans." Because freeze-acceptance runs after writing-plans — not directly after brainstorming — it does not compete with that rule. It is the upstream judgment step wrapping the plan, not a rival next-skill. (If you tried to invoke freeze-acceptance straight after brainstorming, brainstorming's terminal gate would skip it — so always go brainstorming → writing-plans → freeze-acceptance.)