Ship a large, multi-phase feature after Requirements and design discussion are complete. Convert the approved Requirements, ADR, and design into an implementation plan and stacked PRs for phased delivery. Use when: (1) a large feature design is complete and the user says to implement, (2) the user invokes 'ship-feature' for phased delivery, (3) a design document requires multiple implementation phases. Use one focused PR instead for simple fixes and small, self-contained changes.
Requirements-first workflow for new feature design, design documents, and architecture changes. Use for collaborative or autonomous design: interview the user to confirm high-level requirements, preserve an immutable requirements snapshot, use reusable research subagents without blocking the conversation, record design decisions in an ADR, validate repository feasibility, and produce an implementable final design.
Add a path-scoped coding convention to .claude/conventions/. Trigger phrases include "add a rule for X", "we should always do Y", "let's enforce Z", "document our convention for W", "make agents aware that ...", "ban this pattern", or any request to make future agent edits respect a new project-wide invariant. NOT for one-off code comments, workflow how-tos, or domain explanations — those go elsewhere.
Perform code review. Use for: (1) '/code-review' to review the current branch changes, (2) '/code-review PR #123' to review a specific PR, (3) '/code-review staged' to review staged changes, (4) requests such as 'review this code' or 'please review'.
Create and discuss trustworthy UI visual variants from the product's real components. Use when comparing UI options, reviewing visual polish, reproducing a screenshot, choosing spacing/typography/radius/layout alternatives, or presenting responsive desktop/mobile states as rendered images before implementation.
Create a GitHub PR from the current branch. Proactively use when: (1) '/create-pr', (2) requests such as 'create a PR', 'open a PR', 'submit a PR', (3) opening an already prepared branch as a PR. Focus only on PR creation; do not run code review or spec review.
Use when writing multiline Markdown bodies for GitHub PR descriptions, issue comments, review comments, or discussion comments with the `gh` CLI. Use for: (1) long PR descriptions, (2) issue comments, (3) review bodies, (4) cases where raw `\n` appears or escaping breaks.
Guide for adding dependencies to Python projects. Uses the uv package manager, and version specifier rules differ by project type (apps/libs).