Spec

juliusbrussee/cavekit/skills/spec

作者 juliusbrussee7421e87d5b51無授權條款1.1K 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫7 週前更新

Create, amend, or backprop bugs into SPEC.md at repo root. Sole mutator of the project spec. Triggers when the user asks to write a spec, start a new spec, distill a spec from existing code, add invariants, amend sections (§G, §C, §I, §V, §T, §B), or record a bug via backprop. Common phrasings: "write the spec for...", "new spec", "bug: ...", "amend §V.3", "distill spec from code", "spec this idea". Reads and follows FORMAT.md for the caveman encoding rules and pipe-table shape of §T and §B.

AI 產生的概覽

在倉庫根目錄建立、修訂 SPEC.md,或透過回傳方式把缺陷記錄進規格檔案。

功能
作為專案規格檔案 SPEC.md 的唯一修改者,位於倉庫根目錄。它在多種模式間分派:依想法撰寫新規格、從現有程式碼提煉規格、透過回傳記錄缺陷,或修訂指定章節。它產生目標、限制、介面、不變量、任務與缺陷記錄等章節,顯示差異,並僅在使用者確認後寫入。
適用情境
當使用者要求撰寫或開始一份規格、從現有程式碼提煉規格、加入不變量、修訂 §G、§C、§I、§V、§T 或 §B 等章節,或透過回傳記錄缺陷時使用。它用於把單一專案規格文件維護為權威來源。不用於規格完成後的自動建置,也不用於產生儀表板、日誌或額外狀態檔案。
執行需求
不需腳本,僅提供指示。需要倉庫根目錄有 SPEC.md,以及描述 caveman 編碼規則與管線表格格式的 FORMAT.md。未提及憑證或網路存取。

spec — spec mutator

Read FORMAT.md at repo root if not already loaded. Caveman skill applies to all writes here.

DISPATCH

Inspect user request and project state:

  1. No SPEC.md at repo root AND args describe idea → NEW
  2. No SPEC.md AND from-code in args → DISTILL
  3. SPEC.md exists AND args start bug: → BACKPROP
  4. SPEC.md exists AND args start amend → AMEND
  5. SPEC.md exists, no args → ask user which mode

INPUTS — spec is the sole mutator

The other verbs produce material; spec writes it. Ingest their handoff blocks into the right section, show a diff, write on OK:

  • grill → sharpened §G + §C
  • research → §R rows (add the §R section if absent)
  • review → drafted §V lines + the risk verdict
  • deepen → §I/§V/§T amendments

⊥ rewrite a section the handoff did not name. Sectioned ownership (see FORMAT.md).

NEW — idea → spec

Input: user idea. If it arrived fuzzy, prefer running grill first.

Steps:

  1. Extract goal (1 line, caveman). → §G.
  2. List constraints user stated or implied. → §C.
  3. List external surfaces user named. → §I.
  4. §R only if research ran — else omit the section (right-size).
  5. Propose initial invariants. → §V (numbered V1…).
  6. Break goal into ordered tasks. → §T pipe table, all status ., ids T1…
  7. §B section with header row only (id|date|cause|fix).

Write to SPEC.md. Show user full file. Ask: "spec OK? /review if high-blast-radius, else /build."

DISTILL — code → spec

Walk repo. Produce §G (infer from README/package.json/main entry), §C (infer from stack), §I (enumerate public APIs/CLIs/configs), §V (derive from tests and assertions), §T (one task per known TODO or missing test), §B (empty).

Caveman everywhere. Flag uncertain items with ? in text so user can confirm.

BACKPROP — bug → §B + §V

Input: bug: <description>.

Steps:

  1. Parse bug description.
  2. Find root cause (read relevant code).
  3. Decide: would a new invariant catch recurrence? If yes → draft V<next>.
  4. Append §B row: B<next>|<date>|<cause>|V<N>.
  5. Append new invariant to §V.
  6. If fix also changes behavior → add/update §T rows.
  7. Show diff. Apply only on user OK.

Rule: every bug gets a §B entry. Invariant optional but preferred.

AMEND — targeted edit

Input: amend §V.3 or amend §T etc.

Read that section. Show current. Ask user what changes. Write. Show diff.

Never silently rewrite sections user did not name.

OUTPUT RULES

  • Caveman format per FORMAT.md.
  • Preserve identifiers, paths, code verbatim.
  • Numbering monotonic — never reuse §V.N or §B.N.
  • §T row cites column ! list §V/§I deps: T5|.|impl auth mw|V2,I.api.

NON-GOALS

  • No sub-agents. Main thread writes.
  • No dashboards, no logs, no state files beyond SPEC.md itself.
  • No auto-build after spec. User invokes build explicitly.

來源與署名

來源:juliusbrussee/cavekit位於skills/spec提交7421e87

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架