Loading
Scope a feature end to end and write an implementation spec under specs/ from an accepted proposal — current-system mapping, goals/non-goals, a Decision Log for one-way-door choices, a live Open Quest
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add inkeep/open-knowledge --skill write-a-spec -a cursor -y
Scope a feature end to end and write an implementation spec under specs/ from an accepted proposal — current-system mapping, goals/non-goals, a Decision Log for one-way-door choices, a live Open Questions backlog, and a real migration + test plan. Read when asked to write a spec, scope this feature, turn this proposal into a spec, plan the implementation, or break this into tasks. Do NOT fire on frame a proposal or write the PRD (sibling frame-a-proposal — a PRD frames a change before it is accepted; this skill starts once one is), record a decision or write the ADR (record-a-decision), write a postmortem (write-a-postmortem), or review this design (review-a-design) — those are separate skills. Complements the platform open-knowledge skill; does not replace it.
Scope a feature end to end and write an implementation spec under specs/ from an accepted proposal — current-system mapping, goals/non-goals, a Decision Log for one-way-door choices, a live Open Questions backlog, and a real migration + test plan. Read when asked to write a spec, scope this feature, turn this proposal into a spec, plan the implementation, or break this into tasks. Do NOT fire on frame a proposal or write the PRD (sibling frame-a-proposal — a PRD frames a change before it is accepted; this skill starts once one is), record a decision or write the ADR (record-a-decision), write a postmortem (write-a-postmortem), or review this design (review-a-design) — those are separate skills. Complements the platform open-knowledge skill; does not replace it.
ok seed --pack software-lifecycle (ok-beta for Beta)."
metadata:
pack: "software-lifecycle"
author: "Inkeep"
repository: "https://github.com/inkeep/open-knowledge-skills"This skill is pack guidance. The platform
/open-knowledgeskill (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.
| Mode | Behavior | How entered |
|---|---|---|
| Supervised (default) | STOP at the Step 2 scoping gate for user confirmation of Goals / Non-goals / change shape. Route open decisions interactively. | Default when a user drives the session. |
| Headless | Auto-confirm the scoping proposal after presenting it; auto-select routing decisions. All other gates (parent-proposal check, current-system mapping, Decision Log, validation, grounding) still enforced. | Explicit "don't wait for me", "just proceed", "run headless" — or non-interactive container environments. |
In headless mode, propose the scope AND proceed immediately; record in the Decision Log that scope was auto-confirmed without user sign-off.
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.
spec.md from the spec template; allocate NNN by listing, not guessing.plan.md + tasks.md — only when the spec is going to be built.draft.A spec implements a decision that was already made. Before scoping anything, find the accepted proposal it derives from.
exec("ls -A proposals/") — surface the proposal set with frontmatter enrichment.exec("ls -A decisions/") — an accepted proposal often has a matching frozen record here.search({ query: "<feature name or problem statement>" }) — semantic match across both folders when the name differs from the filename.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:
parent_proposal: in the spec frontmatter. Proceed to Step 1.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?"/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.
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.
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:
spec.mdAllocate the next NNN by listing, not guessing:
exec("ls -A specs/") — read the existing NNN-name/ folders. Take the highest NNN, add one, zero-pad to the existing width (003 → 004).specs/004-payment-retries/.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.
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.
Edit ## Design. It has two layers, in order:
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.
The spec template does NOT ship a Decision Log — you append it. Add an ## Decision Log section to spec.md after ## Test plan. This is the single most valuable artifact in the spec: it is what a new owner reads to understand why the system is shaped the way it is, without having to re-derive it or ask someone who has left.
Each entry is a short block:
### DL-1: <the question, as a question>
- **Options:** A [...], B [...], C [...]
- **Choice:** B
- **Rationale:** [why B beat A and C — the trade-off accepted, the evidence]
- **Date:** YYYY-MM-DD
- **Reverses if:** [what new fact or condition would force revisiting this]
Discipline:
Reverses if line is not optional — a decision with no stated reversal condition can never be re-examined honestly.decisions/ is the sibling /record-a-decision skill's job; do not write ADRs here.A spec ships with its open questions MARKED, not silently resolved. Guessing at an answer and writing it as settled is how a spec misleads everyone downstream.
Append an ## Open Questions section (the template does not ship one). Keep it as a live backlog:
### OQ-1: <the unresolved question>
- **Blocks:** [which goal / design decision this gates, or "nothing — nice to know"]
- **Closed by:** [the evidence that would resolve it — a benchmark, a load test, a product call, a spike]
- **Decider:** [who has authority to close it — a role, not a name that will rot]
- **Status:** open
Discipline:
Status: open to resolved → DL-N and move the resolution into the Decision Log — don't just delete the question.Both real, not decorative. A migration section that says "migrate the data" and a test plan that says "add tests" are worse than nothing — they signal coverage that doesn't exist.
## Migration — name the STATES a live system passes through, in order, and what is true at each. A running system does not teleport from old to new; it lives in intermediate states where both must work:
## Test plan — name WHAT is verified and at WHICH tier, and explicitly what is NOT verifiable and why:
plan.md and tasks.mdOnly when the spec is actually going to be built. A spec at status: draft that may not be implemented does not need these yet — creating them early produces stale scaffolding. Create them when the spec is greenlit for implementation.
write({ document: { path: "specs/004-payment-retries/plan.md", template: "spec-plan" } })
write({ document: { path: "specs/004-payment-retries/tasks.md", template: "spec-tasks" } })
Set parent_spec: ./spec.md in both frontmatter blocks.
plan.md (## Approach, ## Phases, ## Risks + unknowns, ## Dependencies, ## Rollout) — the how-to-build sequenced into phases. Risks + unknowns pulls from the Open Questions that block implementation; Rollout mirrors the Migration states.
tasks.md (## Tasks checklist, ## Done when, ## Out of scope) — the work broken down. Two rules:
## Done when restates the spec's Goals as the completion bar. ## Out of scope mirrors the Non-goals.
Specs that don't link back are islands. Wire the spec into the graph and prove it's clean:
derived from [Payment retries proposal](./proposals/0004-payment-retries.md). Plain markdown relative link — never backticked, never an HTML anchor.decisions/, link it where it's relied upon.links({ kind: "backlinks", ... }) to confirm the reverse edge registered.audit({ path: "specs/004-payment-retries/spec.md" }) returns clean (every lint violation + broken internal link) — fix every finding.type, description, status, owner, parent_proposal, created, tags all present.Close the loop with the user:
## Recap
- Spec at specs/004-payment-retries/spec.md, status: draft
- Derived from [proposal] (or: proceeding without one, logged as DL-N)
- N goals, M non-goals (all temporal, with reasons)
- Decision Log: K one-way-door choices recorded
- Open Questions: J open — [name the ones that block the design]
- Migration: [one line] · Test plan: [what's covered / what can't be]
**To move out of `draft`:** [the specific things — usually: close the design-blocking open questions, get the owner's sign-off, and create plan.md + tasks.md once greenlit for build]
State plainly what is still open. A spec's honesty about its own gaps is what makes it trustworthy.
decisions/. That's the sibling /record-a-decision skill. The spec's Decision Log is scoped to THIS spec's one-way doors; it is not the project's ADR record.## Design before Step 1's map with real pointers.shipped before the work ships. status reflects reality. A spec is draft until built, and only shipped once the code is live — never aspirationally./write-a-postmortem skill's job, not an addendum here.