jig

Use when you have an approved design or requirements for a multi-step task, before touching code. Turns designs into implementation plans with bite-sized TDD-oriented tasks, exact file paths, and verification steps. Save to docs/plans/.

Use when starting development work on a bug, feature, improvement, or task. Guides engineers through the full development pipeline: discover, brainstorm, plan, execute, review, ship. Invoked by "let's work on", "I need to build", "fix this bug", "start a new task", or /kickoff.

Use when exploring ideas, comparing approaches, or refining an unclear problem — at any point in the workflow. A discovery-time tool, not a pipeline stage. Invokable directly via /brainstorm or offered by kickoff during DISCOVER. Produces understanding, not artifacts.

Use when you have an implementation plan and want to execute it. Analyzes the plan's task graph, determines the best execution strategy (parallel via team-dev or serial via sdd), and orchestrates the full build with quality gates. The single entry point for plan execution — you don't need to choose between team-dev and sdd yourself.

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes. Enforces root cause investigation through four phases: investigation, pattern analysis, hypothesis testing, and implementation. Prevents guess-and-check thrashing.

Use when creating new skills, specialists, agents, or packs for the Jig framework. Guides the user through an interview to determine what to build, scaffolds the artifact with valid frontmatter, checks for overlap with existing artifacts, and verifies it loads correctly. Triggered by "create a skill", "add a specialist", "extend the framework", or /extend.

Use when setting up Jig in a project for the first time. Auto-detects the project environment, conducts a back-and-forth interview, and generates jig.config.md, team directory structure, and CLAUDE.md declaration. Triggered by "set up jig", "initialize jig", or /init.

Execute implementation plans in parallel using agent teams with quality gates. Spawns implementer teammates in split panes, orchestrated by a team lead who enforces spec compliance and code quality reviews.

Use when capturing product requirements for features, improvements, or bugs before brainstorming or implementation. Triggered by "create a PRD", "capture requirements", "document requirements", "write a PRD", or /prd.

Use when reviewing PR comments, responding to code review feedback, or addressing reviewer suggestions on the current branch. Triggered by "respond to PR comments", "address review feedback", or /pr-respond.

Use when reviewing code before PRs or as quality gate during parallel execution. Dispatches parallel specialist review agents via the swarm architecture. Invoked by code-review agent, team-dev quality gate, or /review.

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work. Guides completion of development work by verifying tests, presenting structured options (merge, PR, keep, discard), executing the choice, and cleaning up worktrees.

Use when creating or removing git worktrees for isolated parallel development. Handles provisioning of gitignored artifacts, env files, and post-create setup via jig.config.md configuration.

Use when creating a ticket, filing an issue, or opening a task in your team's tracker. Triggered by "create a ticket", "file an issue", "new ticket", "open a ticket", or /jig:ticket. Reads ticket-system from jig.config.md and routes to the appropriate tracker pack.

Use when a PR has been merged after receiving review feedback and you want to extract lessons learned. Analyzes reviewer comments, identifies gaps in skills and specialists, and applies fixes. Triggered by "run a postmortem", "PR retro", "lessons learned from this PR", or /postmortem.

Use when creating a pull request. Analyzes branch changes, writes a clear PR description with friendly tone, and generates a structured test plan. Triggered by "create a PR", "open a pull request", or /pr-create.

Use when executing implementation plans with independent tasks in the current session. Dispatches a fresh subagent per task with two-stage review (spec compliance then code quality) after each. Serial execution for coupled tasks or when agent teams are unavailable.

Use when implementing any feature or bugfix, before writing implementation code. Enforces red-green-refactor cycle where every piece of production code is preceded by a failing test. Language-agnostic TDD discipline.

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs. Requires running verification commands and confirming output before making any success claims. Evidence before assertions, always.

Use when writing ANY user-facing text -- UI labels, button text, error messages, notifications, tooltips, placeholders, or application content.

Use when implementing logging in application code. Covers log level selection, structured logging, error tracking integration, and avoiding noise.

Use when writing tests, designing test strategy, or reviewing test coverage. Covers test pyramid, naming, mocking, and flaky test policy.