synthesize-spec
Skill16 starsChanged 4 months agoMITView on GitHub
Turn a brief into a ratified, decomposable spec the way orchestrate-build turns a plan into a build: a durable research ledger whose rows are executed in fresh contexts, then synthesis, adversarial review, and operator ratification. Use it for the UPSTREAM half of a large build — when the spec does not yet exist or is still a moving target and the work spans research, design, and operator decisions across multiple sessions. Pairs with decompose-spec (it writes the decomposition-prompt.md hand-off). For a spec that already exists, skip this and run decompose-spec.
In this repository10 other files it gives its agents.
- address-pr-commentsSkill
- agent-docsSkill
- build-memorySkill
- decompose-specSkill
- implement-specSkill
- orchestrate-buildSkill
- reconcile-buildSkill
- refresh-repo-docsSkill
- review-prSkill
- self-reviewSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 56
run: All rows done, no spec yet (or a new round) → synthesize.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Synthesize Spec
Produce a ratified, decomposable spec from a brief — the upstream half of a large build. Both reference
builds' upstream halves were multi-day, multi-context efforts with operator decision rounds; a single-context
"write me a spec" call cannot hold that. So this skill has the same shape as the build itself: a durable
research ledger whose rows are executed in fresh contexts, exactly as orchestrate-build executes
tickets, then synthesis, adversarial review, and operator ratification.
The mental model. State lives on disk (
docs/research-ledger.md). Cognition lives in fresh contexts (each research/design row; the review pass). Sequencing is a loop that reads the ledger, runs the next unit, writes the ledger back — sodrive-build.sh --skill synthesize-speccan drive it, honoringpauseRequestedand stopping at operator-decision points. It hands off todecompose-specby writingdocs/decomposition-prompt.md.
The layout it reads and writes (docs/research-ledger.md, docs/research/, docs/design/, the spec,
docs/decomposition-prompt.md) is defined in skills/build-memory/layout.md; this skill cites it and does not
restate the tree.
Orient (every invocation)
Resolve the mode from the ledger, the way orchestrate-build orients:
- No
docs/research-ledger.mdyet →plan(§modes/plan.md). - Ledger present → read its
CURRENT STATEblock (nextUnit,projectStatus,round).projectStatus: DONEor spec Statuscanonical→ nothing to do; report and stop. An open research/design row isnextUnit→run. All rows done, no spec yet (or a new round) →synthesize. Spec written, not yet reviewed →review. Reviewed and dispositioned, awaiting operator →ratify. - An explicit
modeinput overrides. pauseRequested: trueor an unanswered operator-decision (⚑) row that blocks progress → report and stop (this is the human's decision surface, like a gate).- Freshness first (V14):
check-build-memory.sh --planning docs/research-ledger.md—updatedAtnot older than the newest change-log stamp,lastCompletedthe newest done row,nextUnitnot done. Every stamp you write comes fromdate -uat that moment (BM-CLOCK-01); only one session writesCURRENT STATE.
Then follow the matching mode file below; each ends by updating the ledger's CURRENT STATE + change log and
returning here.
The modes
| Mode | File | What it does |
plan | modes/plan.md | Seed docs/research-ledger.md: theses, lettered research/design streams as | id | item | owner | status | evidence | tables, the §O process, the §Q operator register, and a CURRENT STATE block so the loop can drive it. |
run | modes/run.md | Execute one open ledger row per fresh context → a note under docs/research/ or docs/design/ in the CONVENTIONS.md finding format, emitting REQ-<STREAM>-<n> requirements and open questions. |
synthesize | modes/synthesize.md | Write the spec: front matter, §0 how-to-read + requirement-ID convention, decision register, appendices A–E, and (with a brief) OUTLINE_TRACE.md proving superset coverage. |
review | modes/review.md | Fresh-context adversarial pass (consistency, coverage of every ledger row, MVP realism, self-contradiction); delta-only when a prior version exists; findings dispositioned in Appendix E. |
ratify | modes/ratify.md | Present open Q rows, record answers, flip the spec to canonical, freeze the ledger, and write docs/decomposition-prompt.md — the hand-off to decompose-spec. |
Why fresh contexts and a ledger (not one big prompt)
- Research is broad and lossy. A single context that reads dozens of sources to write a spec has forgotten the early sources by the end. Each row's fresh context reads exactly its sources and writes a durable note; the spec is synthesized from the notes, not from a decayed context.
- Review must be independent. A context that just wrote the spec is a biased reviewer of it (the same
self-preference bias
implement-specanddecompose-specguard against).reviewruns in a fresh context given the spec + the ledger, not the authoring history. - Operator decisions are first-class. The
§Qregister and⚑markers make the human's rulings part of the durable record, andratifyis the one place they are required — no spec goescanonicalwith open questions.
What this skill does NOT do
- No decomposition, no implementation — it produces the spec and the
decomposition-prompt.mdhand-off;decompose-specandimplement-spectake it from there. - No inventing findings — nothing is cited that was not read (the ledger's standing rule); an inaccessible
source is recorded as
INACCESSIBLE, never paraphrased into a claim. - No ratifying on the model's own say-so —
canonicalrequires the operator's answers to the open Q rows.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

