claude-plugins

A relentless one-question-at-a-time interview that sharpens a plan, decision, or idea until shared understanding is reached — not limited to software. Use when the user wants requirements or a decision clarified before acting, wants to stress-test their thinking, or asks to "grill me", "詰めて", "brainstorm this".

Executes an implementation plan or agreed work by orchestrating fresh subagents — one implementer per task, a reviewer between tasks — while the main model plans, briefs, and evaluates without writing code itself. Use when the user asks to "implement the plan", "start implementation", "実装して", or hands over a plan or spec to execute.

A feedback-loop-first discipline for diagnosing hard bugs and performance regressions. Use when the user reports something broken, throwing, failing, flaky, or slow, or asks to "diagnose", "debug this", "原因を調べて".

Builds a clearly-marked throwaway prototype to answer a design question before committing to an implementation. Use when the user wants to sanity-check whether logic or a state model feels right, explore what a UI should look like, or asks to "prototype this", "試作して".

Creates an Architecture Decision Record for a decision that is hard to reverse, surprising without context, and the result of a real trade-off. Use when such a decision has just been made, or the user asks to "record this decision", "ADRにして", or mentions decision records.

Reviews the diff since a fixed point along two axes run as parallel subagents — Spec (does the change match what was asked?) and Standards (repo conventions plus a code-smell baseline) — and reports them side by side. Use when the user asks to review a branch, work-in-progress changes, a diff, or "review since X".

Configures this repository for the engineering skills by writing .claude/engineering.local.md — where specs, plans, and ADRs are saved, if at all — and excluding it from git locally. Run once per repository before relying on doc-saving skills.

Test-first development anchored on pre-agreed seams — agree where tests will live before writing them, then run the red-green loop. Use when implementing features or bug fixes, when the user mentions "TDD", "red-green", "test first", or when deciding where tests belong.

Runs the relevant verification and reads its output before any claim that work is done, fixed, or passing. Use when about to report completion of a code change, bug fix, refactor, or task, or before committing and creating a PR.

Turns an agreed spec or conversation into an implementation plan of self-contained tasks ready for subagent delegation. Distinct from Claude Code's built-in plan mode. Use when the user asks to "make an implementation plan", "break this into tasks", "計画を立てて", or before multi-task implementation work.

Synthesizes the current conversation and codebase understanding into a spec document, without interviewing. Use when the user asks to "write a spec", "turn this into a spec", "specにして", or after an interview reaches shared understanding.

Creates a GitHub Pull Request using the gh CLI. Use when asked to "create a PR", "open a PR", "submit a PR", "make a pull request", or "send a PR". Supports draft and open statuses.

Resolves git merge and rebase conflicts by understanding the intent of both sides and integrating them correctly, then verifies the result. Use when asked to "resolve merge conflicts", "fix the conflicts", "merge main and resolve conflicts", "rebase onto main and fix conflicts", "解消して", or when a merge/rebase/pull stops with conflicts. Handles both merge and rebase conflict states.

Analyzes all changes in the working tree (staged, unstaged, and untracked), intelligently groups them into semantic commit units at hunk-level granularity, and commits them sequentially. Use when asked to "auto-commit", "group and commit", "split changes into commits", "organize my changes into commits", "batch commit", "smart commit", or "split my work into commits". Supports flags for commit message language and for skipping the grouping-plan approval step.

Validates plugin structure and metadata across the marketplace. Use when asked to "verify plugins", "validate plugin structure", "check plugins", or after making changes to plugin files.

Reviews staged file changes and automatically generates an appropriate commit message to commit them. Use when asked to "commit staged changes", "commit what's staged", "commit the staged files", or similar commit requests.