jig

Use when starting creative work — designing features, adding functionality,

Execute an implementation plan — analyzes task graph and picks parallel (team-dev) or serial (sdd) automatically.

Use when encountering any bug, test failure, or unexpected behavior, before

Use the `jig:eng-copywriting` skill to handle this request.

Use the `jig:eng-logging` skill to handle this request.

Use the `jig:eng-testing` skill to handle this request.

Use when creating new skills, specialists, agents, or packs for the Jig

Use when implementation is complete, all tests pass, and you need to decide

Use when setting up Jig in a project for the first time.

Use when starting development work on a bug, feature, improvement, or task.

Use when you have an approved design or requirements for a multi-step task,

Use when a PR has been merged after receiving review feedback and you want to

Use when creating a pull request. Analyzes branch changes, writes a clear

Use when reviewing PR comments, responding to code review feedback, or

Use when capturing product requirements for features, improvements, or bugs

Use when reviewing code before PRs or as quality gate during parallel execution.

Use when executing implementation plans with independent tasks in the current

Use when implementing any feature or bugfix, before writing implementation

Execute implementation plans in parallel using agent teams with quality gates.

Create a ticket in your team's tracker (Linear, GitHub Issues, Jira). Interviews, writes, files, and sets up the branch.

Use when about to claim work is complete, fixed, or passing, before committing

Create or remove git worktrees for isolated parallel development. Handles env files, dependency syncing, and project setup.

Use when committing code. Triggered by "commit the work", "commit this", or "commit with {name}". Reads jig.config.md for conventions, respects existing hooks, supports co-author resolution.

Use when reviewing code before opening a PR. Triggered by "review my code", "review my changes", or "run the review swarm". Dispatches the review swarm and produces a confidence-scored report.

Use when posting inline code review comments on a PR. Triggered by "post review comments", "leave feedback on PR", or "post inline comments". Pairs with code-review agent (analyze) then this agent (post).

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 starting creative work — designing features, adding functionality, modifying behavior, or exploring approaches. Guides collaborative design exploration through one-at-a-time questions, approach proposals, and incremental design approval. Hard gate: no code until design approved.

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 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 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.

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 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 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 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 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 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 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 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 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 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 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 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 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 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.

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.