Stats
Actions
Tags
From ck
Creates, amends, and backpropagates bugs into SPEC.md at the repo root. Handles new specs from ideas, distilling specs from existing code, and recording bugs with root cause analysis.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ck:specThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Read `FORMAT.md` at repo root if not already loaded. Caveman skill applies to all writes here.
Read FORMAT.md at repo root if not already loaded. Caveman skill applies to all writes here.
Inspect user request and project state:
SPEC.md at repo root AND args describe idea → NEWSPEC.md AND from-code in args → DISTILLSPEC.md exists AND args start bug: → BACKPROPSPEC.md exists AND args start amend → AMENDSPEC.md exists, no args → ask user which modeThe other verbs produce material; spec writes it. Ingest their handoff blocks into the right section, show a diff, write on OK:
⊥ rewrite a section the handoff did not name. Sectioned ownership (see FORMAT.md).
Input: user idea. If it arrived fuzzy, prefer running grill first.
Steps:
., ids T1…id|date|cause|fix).Write to SPEC.md. Show user full file. Ask: "spec OK? /review if high-blast-radius, else /build."
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.
Input: bug: <description>.
Steps:
V<next>.B<next>|<date>|<cause>|V<N>.Rule: every bug gets a §B entry. Invariant optional but preferred.
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.
FORMAT.md.cites column ! list §V/§I deps: T5|.|impl auth mw|V2,I.api.npx claudepluginhub juliusbrussee/cavekit --plugin ckCreates or updates SPEC.md documents from requirements, notes, or interview output, structuring into sections for goals, design, edge cases, security, testing, and success criteria. Use for feature specs.
Write and manage spec files with search, conflict detection, and reporting. Use when user asks to create a spec, update a spec, write a spec, or mentions 스펙 생성, 스펙 업데이트, 스펙 작성, 스펙 만들어줘. Proactively trigger whenever the user's request involves specification documents, even if they don't explicitly say "spec".
Manages specification files with template-driven creation, duplicate detection, and conflict reporting. Automatically activates when creating or updating specs.