cai

Build a detail design's work breakdown unit by unit, test-first, verifying and committing each one before the next starts — or, with no design document, cut checkpointed units yourself. Usage: /cai:build <detail design doc, or what to build>

Find the root cause of a bug before proposing any fix — a test that fails, a crash, a stack trace, unexpected behaviour, or something that used to work and stopped. Use when the user says "this is broken", "it's not working", "the test fails", "fix this bug", "為什麼會壞", "這段程式有 bug", or pastes an error message or stack trace. Not for a diff that might not be mergeable (`verify`), code that behaves correctly but is hard to read (`refactor`), or a question about what's unknown before any code exists (`discover`) — this is for something that demonstrably does not work right now.

Write a design document for review — high-level (weighs architecture options, stops before implementation detail), detail (turns an approved high-level design into something a team can build from), or delta (recovers the decisions from a branch already built). Usage: /cai:design <what to design, or the mode: high-level|detail|delta>

Surface what the user doesn't know before writing implementation code — a blindspot pass, a vocabulary ladder, an interview, an option space, or a mock, whichever unknown would change the most work. Use whenever the codebase area is unfamiliar, the requirements are ambiguous, the solution space has not been explored, or the result will be judged by look and feel. Also use when the user invokes /cai:discover, or says "what am I missing", "find my blindspots", "interview me about this", "brainstorm the options", "show me some directions", "mock this up first", "I've never touched this code", or "I don't know what X is".

Use this whenever the user asks to run a git or GitHub CLI operation — full form (git commit, git add, git push, git pull, git merge, git rebase, git stash, branch create/switch, gh pr create) or shorthand (commit, add, push, pull, pr), including combined requests like "commit + push + pr" or "commit, push" — so it executes on the chore tier instead of the main session model.

Review a design doc, then route it: a document with a work breakdown schedule is built unit by unit, everything else goes to a single implementer — both lanes converge on the same test-and-report step. Usage: /cai:goal <path to design/plan doc>

Turn a request into an acceptance-testable problem statement before any code exists — explore context, ask one question at a time, propose 2-3 approaches with a recommendation, then wait for approval. Usage: /cai:intake <request>

Lay out two or more ways forward so a person can actually choose between them: shared comparison dimensions, six fields per option including an everyday-life ELI5 analogy, a recommendation and the condition that voids it. Use before a list of options goes out, and after one already did and the reader could not act on it — 看不懂 / 這是什麼意思 / 差在哪 / 幫我展開 / 講白話一點 / 比較一下 / expand that / what is the difference / explain it simply / which should I pick. Usage: /cai:options <what to compare, or nothing to rewrite the previous message>

Review an implementation plan, architecture design, or technical spec the way a senior architect would — trace every design element back to a requirement, surface over-engineering, check the software-engineering consequences the plan glossed over, and hunt wording too vague to implement from. Use when the user asks to review a plan, design doc, spec, RFC, or ADR, says "審一下這份計畫", "is this over-engineered", "does this match the requirements", "poke holes in this design", "這份規格夠精準嗎", "is this spec precise enough to build from" — and also on your own implementation plans before handing them over.

Quiz yourself on a diff before merging — a report on what changed and the non-obvious behaviours, then questions you have to answer correctly. Usage: /cai:quiz [base-ref]

Use when improving the internal structure of existing code without changing its behaviour - cleaning up a long method, breaking up a god class, removing duplication, taming conditionals, fixing an inheritance hierarchy, or when the user says refactor, code smell, technical debt, tidy up, restructure, or names a specific refactoring such as Extract Method or Replace Conditional with Polymorphism. Also use before adding a feature to code that resists the change.

Finish installing cai — copy the shared rules into ~/.claude/rules/, set your preferred response language, verify the bash guard actually fires, and optionally install the status line. Run once after installing the plugin, and again after each /plugin update.

Squash a PR branch into one conventional commit, write a release note, and stop before merging, tagging, or publishing until a person confirms. Usage: /cai:ship [base commit id]

Carry one feature through the six SDLC stages (intake, discover, design, build, verify, ship), keeping state in .claude/track/ so a new session with no memory of this conversation can resume. Usage: /cai:track [<feature>|status|skip <stage> --reason "<why>"|done]

Review a branch diff before merging by dispatching three read-only reviewers (correctness, conformance, coverage) in parallel and reconciling their findings, then fix Blockers and Majors with a failing test run before and a passing one after. Use when the user asks to review a diff, branch, or PR before merging, says "review my changes", "check this before I merge", "審一下這個 diff", "找出這次改動的問題" — and on your own changes before handing them over.