Claude Code Development Kit

Use the following rubric to determine how many reviewers to spawn:

• Skip Review: If the change is trivial (comments, formatting, typos, or single-line fixes with no logic effect). Tell the user: "Change is trivial, skipping review."
• Single Reviewer: For changes under ~50 lines. Use the Single Reviewer template (covers both Bug Hunter and Rules Auditor checklists).
• Parallel Specialists (2 Reviewers): For changes with 50+ lines or spanning 2+ modules. Spawn a Bug Hunter (correctness + security) and a Rules Auditor (project rules + tests) in parallel.
• Architect (Optional 3rd Reviewer): Add an Architect if the change is design-significant, such as:
  • Spanning 2+ modules/components.
  • Introducing a new abstraction or API contract.
  • Unfinished refactors/migrations or file moves.
  • Evidence of scope creep.

When deploying, the skill resolves configuration (app IDs, regions, etc.) using the following fallback hierarchy. It uses the first source that exists:

1. Committed config: A tracked file in the repository (e.g., fly.toml, vercel.json, or a .deploy-target file). This is the preferred, worktree-safe method.
2. CLI-managed temp/state: Local state files created by provider CLIs (e.g., .vercel/project.json).
3. Heuristic: Derived from conventions like directory names, repository names, or environment variables.

If no configuration is resolved, the pipeline stops with an error message instructing the user to run a link command or create a configuration file.

The deployment skill follows a 'shadow-then-swap' flow to ensure safety:

1. Gates as Safety Nets: Pre-deploy test gates and shadow smoke-probes are designed to fail-stop before the swap occurs. If a gate fails, the live target remains untouched.
2. Shadow/Canary Deployment: This is optional. Use it if a bad deployment could reach users before you can verify it. If your host provides atomic instant rollbacks, this may be redundant.
3. Post-deploy Checks: These are for reporting only. Once code is live, post-deploy checks cannot automatically un-deploy it; they will issue warnings but will not trigger an auto-rollback.
4. Rollback Strategy: Always prefer re-pointing traffic to a previous release over rebuilding code. In the shadow-then-swap flow, if anything fails before the swap, the 'rollback' is simply to 'not swap'.

The deploy skill identifies deployable units by scanning for capability-marker files (files that signal a directory is independently deployable).

To use this, you must identify a marker file relevant to your stack (e.g., Dockerfile, vercel.json, fly.toml, wrangler.toml, or a package.json containing a deploy script) and ensure the skill scans for it.

If a marker is found at the repo root, the entire project is treated as one target. If markers are found in subdirectories, each subdirectory becomes an independent target, and the pipeline maps git diffs to the specific affected targets.

The review-work skill follows a four-step automated process executed by the invoking agent:

1. Capture the Diff (+ Tests): Capture the uncommitted code changes and run the appropriate test/build command for the project stack (e.g., npm test, pytest, cargo test, go test ./..., or the test_command defined in hooks/config/pipeline.json).
2. Triage: The invoking agent analyzes the diff by file path to identify impacted modules and risk surfaces.
3. Decide Reviewers: The agent selects reviewers based on a judgment rubric.
4. Spawn Reviewers: Reviewers are spawned in parallel (or via a single message) to perform the review.

Reviewers require two pieces of context to function effectively:

• The diff.
• The test results.

When using Context7, follow these best practices to ensure high-quality results:

• Pass the full question: Do not use single keywords; passing the entire user question improves relevance during both the resolution and querying steps.
• Be version-aware: If the user mentions a specific version, include that version information in the resolve-library-id step.
• Prefer official sources: If multiple matches are returned, always prioritize the official or primary package.
• Fallback strategy: Only use web search if Context7 has no coverage for the requested library.

The /prime command operates in two modes to optimize context usage:

Light Prime (Default)

Optimized for routine tasks. It loads:

1. Spec TOC: Line numbers from docs/ai-context/spec.md to allow targeted reads.
2. Spec opening: The framing/invariants section of the spec.
3. Structure Map: The ## Map section of docs/ai-context/project-structure.md.
4. Task-aware deepening: If a task is provided, it reads only the specific spec sections relevant to that task's domain.

Full Prime (--full)

Optimized for high-level design and architecture. It loads the entire contents of:

1. docs/ai-context/spec.md
2. docs/ai-context/project-structure.md
3. docs/ai-context/progress.md (if -p is set)
4. docs/ai-context/deployment-infrastructure.md (if --deploy is set)

The deploy skill includes shared-code dependency awareness. If a change is detected in shared or library code, the pipeline identifies all deployable units that import that code and includes them in the deployment list.

This ensures that because deployable units bundle shared code, they are redeployed to include the updated version. The discovery process involves:

1. Finding direct importers of the changed shared file.
2. Finding transitive importers (files that import the direct importers) via recursion.

If your repository contains distinct subsystems, you can scope the context loading to a specific module by providing the module name immediately after the command and flags.

If a module name is provided but does not match any entry in the project's Module Map, the command treats the token as part of the task text and defaults to a whole-project prime.

Example: If api is a defined module, /prime api add rate limiting will scope the context to the API module and set the task to add rate limiting.

Use root-level Markdown files to define the standards and instructions for different AI models:

• CLAUDE.md: Defines the primary development rules, coding standards, and project-specific instructions for Claude.
• GEMINI.md: Provides instructions specifically for using Gemini as a second-opinion or alternative model.