§B · USAGE
Run the chain.
Then close the loop.
A skill is a reusable workflow your agent loads from a local file. You invoke it
explicitly by typing /<skill-name>, or implicitly when its description matches your
request. Here is how the three run together, and how the hardened spec turns into a built outcome.
For the per-skill detail, see the skills reference.
§B1 · RUN THE THREE IN ORDER
/goal-formatter
Describe your idea in plain language. You get back a structured, testable goal: measurable
end state, success criteria, verification method. Add "and a spec" to also get a
draft specification, with anything undecided marked as a [GAP].
/goal-spec
Turn that goal into a complete engineering spec. It asks you targeted clarifying questions for anything the goal left undecided, grounded in what you said you want, then resolves every gap (by asking, or by recording a sensible-default assumption).
/spec-review
Harden the spec autonomously. A roundtable of engineering-discipline reviewers (Architect, Security, Test/QA, Operations, Product) critiques it round after round until no critical or major issues remain, with no check-ins required. You get the converged spec plus a round-by-round summary.
If your client does not support subagents, spec-review can run the personas inline (one model voicing each discipline). That is faster, but with less genuine independence between reviewers.
The three share one 8-section engineering spec template (Problem & Context, Scope, Requirements, Constraints, Design Approach, Success Criteria, Risks & Mitigations, Open Questions), so handoffs line up with no renamed sections.
§B2 · THEN EXECUTE IT
The kit's deliverable is a trustworthy spec, not a running system. Authoring ends at convergence; execution is a separate, deliberate step you perform with whatever executor you like:
- Claude Code
/goal: paste the goal; point it at the hardened spec as the detailed design. - An autonomous loop (autopilot or ralph-style runner): feed it the spec as the source of truth and let it build to the spec's Success Criteria.
- An
executorsubagent: dispatch with the spec inline, then verify the output against the spec's Success Criteria and Verification section.
The spec's Success Criteria are the acceptance gate: the work is done when every criterion is observably met. Run the executor, check against those criteria, iterate if any fail. That is how the loop closes on a built outcome, not just a written one.
§B3 · TIPS
- Run the three in order for a brand-new effort; jump in at
goal-specif you already have a goal, or atspec-reviewif you already have a spec. - Keep the spec file on disk between steps so each skill can read and revise the same artifact.
- For high-stakes specs, read spec-review's round-by-round summary and the autonomous decisions it made on your Open Questions before you execute. That is where it filled gaps for you.