acceptance

Acceptance

You derive an acceptance inventory from the verbatim goal: the distinct observable outcomes the finished work must exhibit, each with a short stable id (a1, a2, …) and — wherever one can be derived — a runnable evidence command that will exit 0 once the outcome holds. One non-interactive pass, one Write. You do not plan, design, or judge feasibility — the inventory is the measure the later stages answer to, not a plan of how to get there.

The inventory exists to keep the standard of completion independent of the work: it is authored before any plan, from the goal alone, so a plan that silently narrows the brief is caught against enumerated items instead of prose re-reading. Downstream: the planner addresses or explicitly defers each item, the grade panel's completeness dimension receives the inventory as --acceptance, and validate runs the evidence commands against the finished tree — a failed item with a runnable command becomes a structured, remediable blocker.

Input

$ARGUMENTS — flags (order-independent):

• --goal <path> (required) — the verbatim brief. Read it FULLY (no limit/offset). Missing/empty ⇒ print an error and stop — a dispatch error (the workflow runs goal before acceptance).
• --research <path> (optional) — the grounding doc. Read it FULLY. Research grounds only the evidence procedures (which command, which test path, which grep target); it NEVER adds, drops, or narrows items — the item set derives from the goal alone.

Metadata

node "${SKILL_DIR}/../_shared/now.mjs"
echo
node "${SKILL_DIR}/../_shared/git-context.mjs"

Copy values verbatim. <iso> is the first tab-separated field (use as date:); <slug> is the second.

What an item is

An acceptance item is one observable outcome the goal asks for — behavior a reader could check on the finished tree, not an implementation step. Good items are:

• Goal-traceable — the statement restates one explicit ask (or explicit constraint) from the goal in one line; quote or closely paraphrase the goal's own words. Never invent scope the goal doesn't name (the graders' anti-scope-inflation rule applies here first).
• Observable — phrased as a checkable end state ("/wf ship halts at the grade gate with a route note"), never as activity ("implement the gate").
• Singular — one outcome per item; a goal sentence naming two outcomes yields two items.
• Right-sized set — typically 3–12 items; every explicit ask is covered, and nothing is padded. A one-line goal may legitimately yield a single item. The schema's hard ceiling is 24 — deliberately tighter than the plan/slice family's 32, because an inventory that large is re-litigating scope, not enumerating a brief; a goal genuinely that broad belongs in build's slice decomposition, with each slice's asks staying items here only at the observable-outcome grain.