record-decision
Capture a design or architecture decision as an ADR in docs/adr/ and update CONTEXT.md if terminology is affected. Use when the user says "document this decision", "record this design choice", "write an ADR", "capture the decision to X", or after any implementation where a non-obvious trade-off was made. Also trigger after refactors or design changes where the *why* isn't visible in the code: if a decision just landed that meets the ADR criteria below, offer to record it.
- License 许可
- MIT
- 最近更新
- 2026-11-11
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- record-decision
- description
- Capture a design or architecture decision as an ADR in docs/adr/ and update CONTEXT.md if terminology is affected. Use when the user says "document this decision", "record this design choice", "write an ADR", "capture the decision to X", or after any implementation where a non-obvious trade-off was made. Also trigger after refactors or design changes where the *why* isn't visible in the code: if a decision just landed that meets the ADR criteria below, offer to record it.
03 SKILL.md 正文
Take the decision as stated — no interview, no grilling. Write the ADR immediately. The one check is against the global skills below; it is not an interview about the decision's merits.
Steps
-
Scan for existing ADRs — check
docs/adr/for the highest existing number and increment. Create the directory if it doesn't exist. -
Check against the global skills — compare the decision with
go-idiomatic,go-testingandpostgres-best-practiceswhere they cover its area. Global skills outrank repo ADRs: a decision that conflicts with one is rewritten to follow the skill, never recorded as an exception. Tell the user which rule it conflicted with and how the ADR changed. When an existing ADR conflicts, amend that ADR rather than writing a new one beside it. If the user insists on the exception, the skill is what changes; point them toskill-updater. -
Write the ADR —
docs/adr/NNNN-kebab-title.md, matching the existing ADRs' format. With none to match, use a# ADR NNNN — Titleheading and one paragraph covering the context, the decision and its consequences. -
Update CONTEXT.md if relevant — if the decision establishes or changes the canonical name for a concept, or resolves a naming ambiguity in the codebase, update the relevant entry. If no CONTEXT.md exists, only create one if the decision is fundamentally about naming/terminology.
CONTEXT.md updates
Update only when the decision:
- Establishes or changes the canonical name for a concept (e.g. "params" →
CreateApplicationInputin thedtopackage) - Resolves a naming ambiguity in the codebase
Keep definitions to one sentence. List terms to avoid. Follow the existing file's format — don't restructure it.
04 同仓库更多 Skills
vault-recall
Answer the user's conceptual or technical question using their Obsidian vault as well as general knowledge. Use when the user asks a question (not a task) whose topic appears in the vault MOC digest from session start. Not for task instructions, not mid-task, and not for writing to the vault (that is to-vault).
ingest
Ingest one external source (an article, course lesson, doc, PDF or URL) into the user's Obsidian vault: save the original to raw/, then build wiki/ pages per the vault's § Ingest. Use when the user types /ingest, or says "ingest this", "add this source to my wiki", "put this article/lesson in the vault as a wiki page". Works from any repo. Routing rule: someone else's words go to wiki/ (this skill); the user's own learnings and decisions go to notes/ (/to-vault).
to-tickets
Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs/plans/<feature>.md`, from /to-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers /to-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.
to-seams
Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — "record a seam for X", "we agreed on this schema, seam it", "add a seam so Y can build against Z's new field". Halts for approval before writing either file.
to-roadmap
Prioritises settled features into a Now / Next / Later kanban board, rendered as a self-contained ./ideas/roadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via /to-prd -> /to-plan -> /to-tickets. Boards the features in ./docs/approach.md, or the "## Accepted ideas" in ./ideas/CONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.
to-prd
Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs/prds/<feature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (/to-prd -> /to-plan -> /to-tickets).