菜单
Interview the user one question at a time to resolve a plan or design before any code is written. Use when the user wants to stress-test a plan, says 'grill me', 'grill this', 'poke holes', or hands over an ambiguous task where guessing would be costlier than asking. Adapted from mattpocock/skills.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
End-to-end ship loop, opusplan on the Claude side (Opus plans, Sonnet executes): plan in parallel with Codex (both draft, cross-review, you synthesize), then implement in ONE worktree with Codex (terra) doing the bulk and a Claude arm doing a disjoint slice alongside for speed, cross-review, one /review, finishing with a single green ready-for-review (non-draft) PR per repo. Use for 'ship this as a PR', 'build this end-to-end', or '/pr'.
Canonical review entrypoint: review a target diff with two independent reviewers — Codex and Claude (Opus) — in parallel, have each vet the other's findings, and synthesize one ranked, deduplicated verdict. Targets a provided branch/range/PR, or the current branch vs origin/main when given no args. Review-only (delegates fixing). Use for 'review this branch', 'review PR 1234', or '/review'.
Health overview skill — queries Sentry, Langfuse, Metabase, PostHog, and GitHub from the command line (curl + gh, credentials from the repo .env) to produce a consolidated health report for the last 12 hours.
Creates an isolated git worktree on a cb/-prefixed branch off fresh origin/main using plain `git worktree` (worktrees live under ~/.worktrees, .env is copied in, an optional zellij tab + dev server open), and prunes merged worktrees first. Use when the user wants a new worktree, to start isolated/parallel work on a feature or branch, or to spin up/clean up a scratch checkout, even if they don't say 'worktree' or 'wt'.
Runs the full ship loop in this repo: drafts a Conventional-Commits message, stages explicitly named files, creates a signed commit (git commit -S), opens a PR with summary/test-plan, then polls CI checks and review comments (CodeRabbit, reviewers) until they settle. Use whenever the user wants to commit, push, open a PR, or watch CI, even if they just say 'commit this', 'ship it', 'make a PR', or '/commit'.
Two modes. With issue number(s): turns each GitHub issue into a concrete, file-level implementation plan under `~/.claude/plans/` (planning only, no commits). With NO args: triages every open issue in the repo, clarifies scope with the user (pushing for the largest batch), then fans out a `Workflow` that drives as many issues as possible to signed DRAFT PRs. Use when the user gives an issue number, asks to review/scope/plan a GitHub issue ('look at issue 3765'), or asks to triage/clear/close out the whole issue backlog ('/issue', 'triage all issues', 'close as many issues as you can').
| name | grilling |
| description | Interview the user one question at a time to resolve a plan or design before any code is written. Use when the user wants to stress-test a plan, says 'grill me', 'grill this', 'poke holes', or hands over an ambiguous task where guessing would be costlier than asking. Adapted from mattpocock/skills. |
| argument-hint | [plan, design, or task to interrogate] |
The most expensive failure mode is misalignment: you build the wrong thing confidently because the task was underspecified and you guessed. Grilling spends a few cheap questions up front to kill that.
Interview the user relentlessly about the plan or design until you both reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one at a time.
/issue, /improve) would otherwise have to
guess at intent - grill first, then plan against the answers.Skip it for tasks with one obvious interpretation; per feedback_skip_ askquestion_when_obvious, if there's a clear default just state it and
proceed.