| 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.)
