agentleFS
SteveVitaliSteveVitali/agent-skills/skills/synthesize-spec/SKILL.md

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.

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
  1. Very specific:

    run: All rows done, no spec yet (or a new round) → synthesize.

    line 56

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 — so drive-build.sh --skill synthesize-spec can drive it, honoring pauseRequested and stopping at operator-decision points. It hands off to decompose-spec by writing docs/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.md yet → plan (§ modes/plan.md).
  • Ledger present → read its CURRENT STATE block (nextUnit, projectStatus, round). projectStatus: DONE or spec Status canonical → nothing to do; report and stop. An open research/design row is nextUnit → 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 mode input overrides.
  • pauseRequested: true or 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 — updatedAt not older than the newest change-log stamp, lastCompleted the newest done row, nextUnit not done. Every stamp you write comes from date -u at that moment (BM-CLOCK-01); only one session writes CURRENT STATE.

Then follow the matching mode file below; each ends by updating the ledger's CURRENT STATE + change log and returning here.

The modes

ModeFileWhat it does
planmodes/plan.mdSeed 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.
runmodes/run.mdExecute 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.
synthesizemodes/synthesize.mdWrite 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.
reviewmodes/review.mdFresh-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.
ratifymodes/ratify.mdPresent 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-spec and decompose-spec guard against). review runs in a fresh context given the spec + the ledger, not the authoring history.
  • Operator decisions are first-class. The §Q register and ⚑ markers make the human's rulings part of the durable record, and ratify is the one place they are required — no spec goes canonical with open questions.

What this skill does NOT do

  • No decomposition, no implementation — it produces the spec and the decomposition-prompt.md hand-off; decompose-spec and implement-spec take 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 — canonical requires the operator's answers to the open Q rows.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.