claude-skills

Implements an existing plan file via gated, context-isolated sub-agents. User-invoked only: /implement-plan <plan-file> [PRD_FILE=...] [ADR_FILES=...]. Orchestrates TDD-gated lanes (RED, GREEN, review+fix, independent verify), freezes cross-lane contracts before fan-out, scouts each lane once into a shared brief, treats the plan as a living artifact updated from sub-agent feedback, and maintains an evidence-based progress ledger. Produces implemented, reviewed, independently verified code plus an as-built plan file.

Doc-aware planning skill. Turns a PRD, ADR, existing plan, or raw idea into a tracer-bullet implementation plan via a relentless one-question-at-a-time interview. Reads accepted ADRs and a PRD together as constraints: ADRs fix architectural decisions; the PRD supplies goals, non-goals, and acceptance criteria that gate each phase. Drafts Proposed ADRs — asking whether a decision is new or supersedes an existing one — and updates CONTEXT.md as terms resolve. Optional tribunal stress-test before finalizing. Use when asked to "plan with docs", "plan this ADR", "turn this PRD into a plan", "break this down into phases", "tracer bullets", "review my plan", "stress test this approach", or /plan-with-docs.

Transforms loose ideas or refined concepts into structured PRDs that capture the what, who, and why — problem, target users, goals, non-goals, and testable acceptance criteria — while deliberately deferring the how (architecture, data models, APIs, delivery phasing) to the planning phase. Works through a progressive interview, light de-risking of risky assumptions, and optional codebase exploration. Use when asked to "write a PRD", "create a PRD", "design a feature", "flesh out this idea", "turn this into a spec", "product requirements", "spec this out", or /prd-designer. Outputs a markdown PRD at docs/prds/{name}.md. Optionally creates a GitHub issue via gh CLI. Dependencies: gh CLI (optional, for issue creation).

Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices, saved as a local Markdown file in ./plans/. Use when user wants to break down a PRD, create an implementation plan, plan phases from a PRD, or mentions "tracer bullets".

Answer one question that can't be settled by reading or arguing — build the smallest throwaway thing that makes the answer visible, inside a timebox, against a decision rule declared before the build starts. Returns a 4-line finding (Q / Tried / Found / Decides) plus a manipulable micro-world when the thing has a visible surface, then deletes the spike. Use when the user says "spike this", "try both and see", "we won't know until we build it", "is X fast enough", "which of A or B", "prototype it first", when an interview hits "I don't know yet" on something no one can know, or when `sightline` resolves a PROBE row. Standalone: /probe <question> [--rule "..."] [--box "..."].

Deep research on an idea before writing a PRD. Explores existing solutions via web search, analyzes competitors, assesses technical feasibility, and optionally explores the codebase. Use when asked to "research this idea", "investigate this feature", "what already exists for X", "explore solutions for X", "do research before the PRD", "look into X", or /research. Outputs a structured research document at docs/research/{name}.md. Suggests running /prd-designer as the next step. Dependencies: WebSearch (optional).

Interview the user relentlessly about a plan or implementation idea until reaching shared understanding, resolving each branch of the decision tree. For existing plans, refines them. For raw ideas, builds a plan from scratch. Then stress-tests the plan through a tribunal of AI personas (Skeptic, Critic, Advocate) and produces a verdict with strengths, weaknesses, risks, and action items. Use when asked to "review my plan", "review my idea", "challenge my design", "stress test this approach", "get feedback on my plan", "flesh out this idea", or /review-idea.

Handle the parts of a plan that can't be decided by talking — answer every question the PRD, prompt, or codebase can already settle, then resolve what's genuinely unknowable with timeboxed probes and manipulable prototypes, gating progress on the user actually understanding what was decided. Keeps its map and findings on disk so an effort can span many context resets. Use this alongside or inside an interview-based planning skill such as plan-with-docs, whenever the user answers "I don't know yet", says a plan feels premature, says they need to prototype first, says they don't understand what the agent produced, or when the work is too big for one session. Also use it when a previous plan turned out to be wrong once building started, or to resume a fogged effort already underway.

Build, audit, and improve Claude Code skills through guided interview and generation. Use when user says "create a skill", "build a skill", "make a new skill", "write a skill", "improve this skill", "audit this skill", "review my skill", "skill from scratch", "turn this into a skill", or /skill-builder. Produces guide-compliant skill directories with SKILL.md, references, and scripts.

Stages and commits git changes using semantic commits with logical grouping. Use when the user asks to "commit my changes", "commit these changes", "commit staged files", "commit unstaged files", "commit specific files", "make a commit", "create commits", or /commit. Defaults to staged-only scope. Warns if unstaged changes exist. Groups related changes into separate semantic commits with meaningful titles and body descriptions. Supports three scopes: staged (default), unstaged, or specific files/paths provided by the user.