Write A Spec

Write a spec — scope a feature and commit an implementation spec

This skill is pack guidance. The platform /open-knowledge skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers spec-writing craft on top.

A spec is the contract between "we decided to build this" and "here is how it gets built." It is derived from an ACCEPTED proposal, maps the system that exists TODAY before proposing a change, and records its one-way-door choices in a Decision Log so the reasoning survives the author leaving. A spec that skips the current-system mapping, or resolves its open questions silently, is a liability — it reads authoritative while being unfounded.

specs/ uses a folder-per-spec shape: specs/NNN-name/ holding spec.md, and (when the work is actually going to be built) plan.md + tasks.md. The pack ships all three templates. status on spec.md flows draft → ... → shipped.

Autonomy mode

In headless mode, propose the scope AND proceed immediately; record in the Decision Log that scope was auto-confirmed without user sign-off.

Mandatory execution order

Hard gates — do NOT skip ahead. If you find yourself about to write ## Design before you have read the actual code the change touches, STOP — you skipped Step 1.

0. Find the parent proposal. No accepted proposal behind a spec is a smell.
1. Map the CURRENT system. Read real code + prior specs + guides. Write what exists today, with pointers.
2. Scoping STOP gate. Propose Goals / Non-goals / change shape. In Supervised mode, WAIT.
3. Create the spec folder + spec.md from the spec template; allocate NNN by listing, not guessing.
4. Fill Goals / Non-goals — non-goals temporal, each with a reason.
5. Design — options considered, one chosen, why; one-way doors flow to the Decision Log.
6. Decision Log — append the section; each entry survives the author.
7. Open Questions — a live backlog, each with its closing evidence and decider.
8. Migration + Test plan — real states, real tiers, explicit gaps.
9. plan.md + tasks.md — only when the spec is going to be built.
10. Link + validate — backlinks, dead-links clean, frontmatter complete.
11. Recap — and what would move it out of draft.

Step 0: Find the parent proposal

A spec implements a decision that was already made. Before scoping anything, find the accepted proposal it derives from.

1. exec("ls -A proposals/") — surface the proposal set with frontmatter enrichment.
2. exec("ls -A decisions/") — an accepted proposal often has a matching frozen record here.
3. search({ query: "<feature name or problem statement>" }) — semantic match across both folders when the name differs from the filename.
4. For the 1-2 strongest candidates, exec("cat proposals/0004-x.md") — read the accepted design and its unresolved questions in full; those unresolved questions become your Open Questions seed.

Route on what you find:

• Accepted proposal exists → note its path; it becomes parent_proposal: in the spec frontmatter. Proceed to Step 1.
• Proposal exists but is not accepted (draft, fcp, rejected) → STOP. A spec for an un-accepted proposal builds on sand. Surface this: "The proposal <path> is at status: <x>, not accepted. A spec should follow an accepted proposal. Want me to help get it accepted first, or proceed anyway?"
• No proposal at all → say so plainly: "There's no accepted proposal behind this feature. Specs derive from proposals — the proposal is where we argue whether to build; the spec is how. I can frame a proposal first (that's the /frame-a-proposal skill), or, if you acknowledge the risk, proceed straight to a spec and record that we skipped the proposal." If the user opts to proceed, record that choice in the Decision Log (Step 6) with its rationale. Do not silently skip it.

HARD GATE: do not create spec.md until the parent-proposal question is resolved one way or the other and, if skipped, acknowledged by the user.

Step 1: Map the CURRENT system before designing the change

The most common spec failure is designing against an imagined system. You cannot write a sound ## Design or a real ## Migration without knowing what the running system does today.

Read the code that exists — with native host tools. Source code (.ts, .py, config, schema) lives OUTSIDE the knowledge base, so read it with the host's native file tools (Read / Grep / Glob), not OpenKnowledge verbs. Trace the actual flow end to end: the entry points, the modules the change will touch, the data shapes, the call chain across boundaries.

Read the knowledge base with OpenKnowledge verbs. Prior specs and guides ARE in-scope markdown:

• exec("ls -A specs/") — see what's been specced before; a sibling spec may already map the same subsystem.
• exec("cat specs/003-x/spec.md") — read the closest prior spec's Design + Migration for the shape and the pointers.
• exec("ls -A guides/") then exec("cat guides/<runbook>.md") — runbooks describe operational reality the code alone won't tell you.
• search({ query: "<subsystem name>" }) — surface adjacent decisions and postmortems that constrain the design.

Write what exists today into the spec's Design section as a "Current system" subsection first, with file/module pointers (src/foo/bar.ts, the handleX function, the widgets table). Concrete pointers are what make the spec verifiable and let a reviewer check your map against the code.

HARD GATE: do not draft the proposed ## Design until the current-system map is written with real pointers. If you cannot point at where a behavior lives today, you do not yet understand it well enough to change it.

Step 2: Scoping STOP gate

Before writing the spec body, propose the scope and get confirmation. Getting Goals / Non-goals wrong is expensive to unwind after the spec is drafted.

Present this to the user:

## Proposed scope

**Parent proposal:** [path — or "none; proceeding without one per your acknowledgement"]

**Goals** (what this spec delivers):
1. [Goal — an observable capability or change]
2. ...

**Non-goals** (explicitly out of THIS spec, and why):
1. [Thing] — deferred because [reason]
2. ...

**Shape of the change:** [2-4 sentences: the approach at a high level, and which modules from the Step 1 map it touches]

**Open questions I already see:** [1-3 — the ones that will gate the design]

Supervised mode: STOP and WAIT for confirmation. Do not create the spec folder until the user confirms or adjusts.

Headless mode: present the scope AND proceed; note the auto-confirmation in the Decision Log.

Scoping discipline:

• If the feature is vague, narrow it here, not in the Design. "Which surfaces? For whom? What's explicitly deferred?"
• Name the beneficiary of each goal — a goal with no one who benefits is scope creep.
• Do not invent requirements the proposal never established (see Non-goals for this skill). If a goal isn't traceable to the parent proposal, flag it and ask.

Step 3: Create the spec folder + spec.md

Allocate the next NNN by listing, not guessing:

1. exec("ls -A specs/") — read the existing NNN-name/ folders. Take the highest NNN, add one, zero-pad to the existing width (003 → 004).
2. Choose a short kebab-case name from the feature: specs/004-payment-retries/.
3. Create the spec:

write({ document: { path: "specs/004-payment-retries/spec.md", template: "spec" } })

The spec template ships frontmatter and these H2 sections in order: ## Goals, ## Non-goals, ## Design, ## Migration, ## Test plan. Fill the frontmatter now:

type: spec
description: "<one line: what this spec delivers>"
status: draft
owner: <user>
target_release:
created: <today YYYY-MM-DD>
parent_proposal: ./proposals/0004-payment-retries.md   # or note the skip
tags: [spec]

Set parent_proposal: to the relative markdown path from Step 0. Leave target_release: blank until the plan exists.

Step 4: Fill Goals and Non-goals

Edit the ## Goals and ## Non-goals sections via edit({ ... }).

Goals — each an observable outcome, not an implementation detail. "Failed payments retry with backoff and surface a final status" is a goal; "add a retryCount column" is a design choice. Tie each goal to the beneficiary and, where possible, to the parent proposal's motivation.

Non-goals are TEMPORAL, not eternal. Frame each as "not in THIS spec" with the reason it's deferred — never as "we will never do this." "Multi-currency retries — deferred; the retry engine is currency-agnostic and multi-currency is its own proposal" tells a future reader the door is open and why it's closed for now. "We don't support multi-currency" reads as a permanent product stance the spec has no authority to make. Every non-goal carries its why.

Step 5: Design

Edit ## Design. It has two layers, in order:

1. Current system (from Step 1) — what exists today, with file/module pointers. Keep this; it is what makes the proposed change legible.
2. Proposed change — the options you considered, the one you chose, and why.

For each meaningful design fork, write: the options on the table, the one chosen, and the reasoning. Name the trade-off you accepted. A design that presents only the chosen option hides the fact that a choice was made — and hides it from the reviewer whose job is to pressure-test it.

Every one-way-door choice goes to the Decision Log (Step 6). A one-way door is a decision that is expensive or impossible to reverse once code ships on it: a wire format, a schema migration that drops data, a public API shape, a security boundary. Reversible choices (an internal helper name, a log level) do not need a log entry — keep the log to decisions that will cost real money to undo.