// Use to decide when to invoke the Claude Code CLI and how. Claude specializes in deep reasoning — plans, hypercritical reviews, multi-file impact analysis, and pipe-fed log analysis. Includes invocation patterns and cross-check usage with Codex.
Use when an architectural decision has been made or is about to be made. Decides whether the decision belongs in docs/DESIGN.md, what level of detail to record, and what NOT to record. Operates as a judgment skill, not a fixed procedure — for the procedure see the update-design workflow.
Use when evaluating a library, framework, or external service for adoption. Walks evaluation axes (fit, maintenance, license, footprint, integration cost) and produces a recommendation with explicit trade-offs. Output goes under docs/research/.
Use when reviewing a diff, a PR, or a series of recent commits. Produces a severity-graded report covering correctness, security, performance, concurrency, maintainability, and Definition of Done compliance. Pairs well with pipe input and with Codex cross-checks.
Use when a bug is reported, a test is failing, or production is misbehaving. Provides observation patterns and diagnostic moves rather than a fixed sequence — every bug has its own shape. Pairs naturally with pipe-fed log analysis.
Use to decide when to invoke the Codex CLI and how. Codex specializes in tight iterate-loops, small refactors, lint cycles, and test additions. Includes invocation patterns and anti-patterns.
Use before writing any non-trivial code. Produces a written plan that names every file to touch, the order of work, the test strategy, the rollback path, and the open questions. Code is not written during this skill.
| name | claude-system |
| description | Use to decide when to invoke the Claude Code CLI and how. Claude specializes in deep reasoning — plans, hypercritical reviews, multi-file impact analysis, and pipe-fed log analysis. Includes invocation patterns and cross-check usage with Codex. |
plan skill, write to docs/plans/).team-review skill).Open Plan mode. Confirm "no code will be written". Apply the plan skill.
Output goes to docs/plans/<feature>.md.
Reviews must come from a session that didn't write the code. Otherwise the same reasoning that wrote the bug will fail to see it.
git diff main...HEAD | claude --verbose "Apply the team-review skill."
docker logs api --since 1h | claude "Group recurring errors and propose root causes."
kubectl get events --sort-by=.lastTimestamp | claude "What changed in the last 30 minutes?"
Hand Claude the full repo (1M-context Sonnet variants help) and ask:
"If I rename UserSession to Session, list every file that needs to
change and the order to change them in."
For consequential plans or reviews, pipe the same input to Codex and diff the outputs. Where they disagree is where the truth usually hides.