cape

Use this skill whenever the user is deliberately starting or resuming work for an existing epic in its own worktree. This includes explicit requests like "start work on ABU-123", "create a worktree for this epic", "set up the epic worktree", "/cape:worktree", or being on the default branch before BUILD work. Do NOT use for ordinary git branch creation, PR preparation, rebasing, merging, deleting worktrees, or creating the epic itself.

Use BEFORE writing any code for new features, integrations, or system changes. Triggers when the user describes something to build, asks "how should I approach X", is unsure between approaches, or mentions adding/creating/building functionality. Also use when requirements are vague, architecture is unclear, or the task involves design decisions (e.g., choosing libraries, data models, API patterns). Do NOT use for bug fixes, straightforward code cleanup, executing existing plans, or tasks where the implementation path is already clear. This skill researches the codebase, asks Socratic questions, generates competing designs under different constraints, and produces a design summary for `cape:write-plan` to formalize into a Linear tracker epic.

Create atomic git commits with conventional commit format and selective staging. Use whenever the user wants to commit changes — explicit requests ("commit this", "make a commit", "let's commit", "/cape:commit") and implicit ones ("we're done, save this", "wrap this up"). Also use when another cape skill finishes a unit of work and needs to commit. Covers staging decisions, splitting large diffs into separate logical commits, and writing thorough commit messages that explain the change. Do NOT use for pushing, creating PRs, or branch operations.

Meta-skill that activates cape's workflow system. Injected at session start; always active and never manually triggered. Routes every task to the right cape skill and enforces workflow chains: brainstorm before planning, plan before coding, TDD during implementation, diagnosis before fixing. If a cape skill matches the user request, using it is mandatory.

Build from a Linear tracker epic, one task at a time. The counterpart to cape:write-plan: write-plan creates the epic and first sub-issue, execute-plan implements it. Triggers on: "continue", "next task", "resume", "let's go", "work on the plan", a Linear issue ID, or transitioning after planning is complete. Uses the local tracker cache for orientation and refreshes that cache after every Linear write. Do NOT use for bug fixes (use cape:fix-bug), exploratory design (use cape:brainstorm), or acting on inbound PR review comments (use cape:pr-feedback).

Verify and hand off a Linear tracker epic after all tasks are complete. Use when the user says "finish the epic", "we're done", "close out the epic", all tasks are done and the user wants to close it, or execute-plan detects all acceptance criteria appear met. Runs final verification, checks acceptance criteria with evidence, optionally writes a minimal outcome summary to Linear, and hands off to review/PR. Linear's GitHub integration closes the epic when the PR merges; cape never sets Linear status.

End-to-end bug fix workflow from discovery to closure. Triggers on: "fix this bug", "can you fix", user wants to address a diagnosed Linear bug issue, fixing a regression, patching broken behavior, or investigating a defect before fixing it. Do NOT use for feature work (use execute-plan) or cleanup without a specific defect.

Resolve inbound PR review comments end to end: fetch the threads with their node IDs, judge each comment's validity, fix the accepted ones, then reply, resolve the matching threads via GraphQL, and commit referencing the review. Use whenever the user wants to act on review feedback: "fetch comments on PR, are they valid?", "resolve threads that are fixed", "push and resolve threads we fixed", "resolve the comment threads that are fixed or ignored", "fix the valid issues and resolve", "/cape:pr-feedback". Do NOT use for reviewing your own pre-PR diff (use cape:review), fixing a single diagnosed defect with no PR thread (use cape:fix-bug), or creating a PR (use cape:pr).

Create a pull request with clear description and actionable test plan. Use whenever the user wants to open a PR — explicit requests ("create a PR", "open a pull request", "let's PR this", "/cape:pr") and implicit ones ("ship it", "ready for review", "push this up"). Also use when finish-epic completes and the user wants to publish their work. Runs automatable test plan items before creating the PR. Do NOT use for reviewing someone else's PR (use cape:review) or committing (use cape:commit).

Review code changes for bugs, logic errors, security issues, design problems, and documented convention violations using structural analysis from the committed graphify graph plus cape conform. Use whenever the user wants a code review: "review my changes", "review this", "check my code", "/cape:review", "anything wrong here?", "is this ready?", or reviewing another PR or branch. Do NOT use for writing prose, committing, or acting on inbound PR review comments (use cape:pr-feedback).

Drive behavioral changes with tests that are written before the production code they justify. Use this skill whenever implementing a feature, fixing a bug, adding behavior, or changing logic that automated tests can verify. Also use when another cape skill (fix-bug, execute-plan) says to follow TDD. Do NOT use for: verification testing (manual run-the-app checks), documentation changes, configuration changes, or refactoring that has no behavioral change.

Reference for cape's tracker seam: Linear MCP writes plus local cache refreshes. Use whenever a cape skill needs to create, list, update, close, or cache tracker work. Triggers on: issue tracking, Linear epic/task/bug workflow, tracker cache, ready work, closing tracked work, and rewiring skills that previously used local issue tracking. Do NOT use for implementation planning itself; use the chain skill and load this only for tracker protocol details.

Formalize a brainstorm design into a Linear tracker epic with one first sub-issue task. Use after cape:brainstorm has produced a design summary. Triggers on: user runs /cape:write-plan, "create the epic", "formalize this design", "write the plan", transitioning from brainstorm to implementation. Do NOT use for initial exploration (use cape:brainstorm), executing existing plans (use cape:execute-plan), or bug diagnosis and fixes (use cape:fix-bug).

Interview-first front end for an autonomous epic run. Asks how to achieve the goal -- worker agent, how to split tasks, review strategy -- then STAGES a reviewable draft: a `/goal` completion condition plus an approach prompt that primes the run. The draft opens in an editor; the user reviews and launches it with `:wq`; set-goal never launches itself. Takes a Linear epic id or a free-form description (turned into a lean epic first). Triggers on: "set up an autonomous run", "draft a /goal for this epic", "prep an AFK run", "/cape:set-goal ABU-123", "/cape:set-goal <description>". Do NOT use for: actually driving a run (that is the approach prompt fed to `/goal`), a single supervised task (cape:execute-plan), or interactive PLAN exploration with a human in the loop (cape:brainstorm / cape:write-plan).