| name | kickoff |
| description | 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.
|
| tier | workflow |
| alwaysApply | false |
Jig Development Pipeline
PURPOSE: The pipeline orchestrator. Routes work through stages and checks gates at each transition. Kickoff does NOT execute stages itself — it invokes the downstream skill for each stage using the Skill tool.
ORCHESTRATOR RULE: At every stage transition, you MUST invoke the downstream skill using the Skill tool (e.g., Skill: jig:plan). Do NOT attempt to execute the stage inline by following kickoff's summary of what the stage does. The downstream skill has the full process — kickoff only knows enough to route and check gates.
CONFIGURATION: Reads jig.config.md for pipeline stages, work type overrides, ticket system, branching format, and concerns checklist.
When to Use
Invoke this skill when:
- Starting development work of any kind
- "I need to add/fix/build/improve..."
- "Let's work on [ticket]"
- "There's a bug in..."
- Beginning a new session with a development task
- You want the full pipeline, not just one stage
Do NOT use when you only need a single stage (e.g., just creating a PR → use pr-create directly).
Terminology
| Term | Meaning |
|---|
| SDD | Subagent-Driven Development (sdd) — sequential execution, one task at a time |
| Team-dev | team-dev — parallel execution with agent teams in split panes + two-stage quality gates |
The Pipeline
graph LR
classify["CLASSIFY<br/>work type"] --> discover["DISCOVER<br/>ticket + branch"]
discover -.->|tool| brainstorm["BRAINSTORM<br/>ideation (optional)"]
discover -.->|tool| debug["DEBUG<br/>root cause (bugs)"]
discover --> prd["PRD<br/>requirements (optional)"]
prd --> review_prd["REVIEW:prd<br/>tier all"]
review_prd --> plan["PLAN<br/>transpose + tasks"]
discover --> plan
plan --> review_plan["REVIEW:plan<br/>tier all"]
review_plan --> build["BUILD<br/>execute + test"]
build -.->|fast tier<br/>while building| review_code_fast["REVIEW:code<br/>tier fast-pass"]
build --> review_code["REVIEW:code<br/>tier all"]
review_code --> ship["SHIP<br/>PR + merge"]
ship --> learn["LEARN<br/>postmortem"]
review_plan -.->|plan wrong| plan
review_code -.->|scope changed| prd
build -.->|blocked| plan
Each stage has a gate. You don't move forward until the gate is satisfied.
BRAINSTORM and DEBUG are discovery-time tools, not stages — they hang off DISCOVER and are invoked on demand (by the user or offered by kickoff) when the work benefits from exploration or root-cause investigation. They produce understanding, not artifacts, and return control to the workflow when done.
REVIEW is a multi-stage gate engine: it runs after PRD (tier: all), after PLAN (tier: all), and during/after BUILD (tier: fast-pass per-task during, tier: all pre-ship). The same skill, three modes. See core/skills/review/SKILL.md.
The pipeline stages and work type overrides are configurable in jig.config.md. Read the config at the start of each session to determine which stages to run.
Step 1: Classify the Work
Before anything else, determine the work type. This controls pipeline depth.
graph TD
start{"What kind of work?"}
start -->|broken / incorrect| bug["BUG<br/>Discovery tool: debug<br/>Plan: 1-3 tasks<br/>Execute: sequential<br/>Learn: optional"]
start -->|making existing thing better| improvement["IMPROVEMENT<br/>Discovery tool: brainstorm (optional)<br/>Plan: standard<br/>Execute: SDD or team-dev<br/>Learn: optional"]
start -->|new capability| feature["FEATURE<br/>Discovery tool: brainstorm (recommended)<br/>PRD: recommended<br/>Plan: detailed<br/>Execute: team-dev<br/>Learn: yes"]
start -->|config / chore / refactor| task["TASK / CHORE<br/>Skip discovery tools<br/>Plan: minimal<br/>Execute: direct<br/>Learn: no"]
Check jig.config.md for stage overrides per work type. The config may skip or lighten stages beyond these defaults.
Ask the user if the type isn't obvious from context.
Step 2: DISCOVER
Gate: A ticket exists and the problem is understood.
Actions
-
Check for existing ticket:
- Branch name contains a ticket reference? Look it up.
- User mentioned a ticket? Fetch it.
- No ticket? Create one. Check
jig.config.md for ticket-system (Linear, Jira, GitHub Issues) and use the appropriate tool.
-
Understand the problem:
- Read the ticket description and acceptance criteria.
- For bugs: check error tracking, reproduce if possible.
- For features: confirm scope with the user if ambiguous.
-
Set up the branch:
Read branching format from jig.config.md:
git checkout -b {format from config}
Gate Check
Before proceeding, confirm:
Step 2b: REQUIREMENTS (optional)
Gate: PRD exists or user opted to skip.
For features and large improvements, prompt: "Want to capture requirements first with /prd?"
If yes: INVOKE jig:prd using the Skill tool. Do not write the PRD inline — the prd skill has the full process (tier selection, 12-section structure, acceptance checklist format). Wait for it to complete before proceeding.
For bugs, tasks, and small improvements: skip this step. Users can still invoke /prd manually if needed.
Gate Check
Discovery Tools (optional, on-demand)
During or after DISCOVER, the user may benefit from one of two discovery-time tools. Offer them when appropriate; never force them.
Brainstorm
Offer for: features with unclear scope, improvements where approach isn't obvious, any time the user signals "I'm not sure how to approach this."
Skip for: tasks with obvious scope, bugs where the fix is clear from the ticket.
If user accepts, INVOKE jig:brainstorm using the Skill tool. It returns control to kickoff when done — no auto-handoff to plan.
Debug
Offer for: bugs where the root cause isn't obvious from the ticket.
If user accepts, INVOKE jig:debug using the Skill tool. It returns control to kickoff when done.
Gate Check
These are tools, not stages. There's no gate — the user moves on when they're ready. Kickoff proceeds to the next stage (PRD or PLAN) when the user signals readiness.
Step 4: PLAN
Gate: A numbered plan exists with tasks, files, and verification steps.
INVOKE jig:plan using the Skill tool. The plan skill's Step 1 is TRANSPOSE — it distills the available source (PRD, ticket, conversation) into a layered contract, derives file structure, sequences by dependency, and decomposes into TDD bite-sized tasks. Kickoff does not transpose; it hands off.
If a PRD was created in Step 2b, mention it when invoking: "PRD is at {plans-directory}/YYYY-MM-DD-<topic>-prd.md." Otherwise plan will transpose from the ticket + conversation context.
Gate Check
Before proceeding, confirm:
Step 5: EXECUTE
Gate: All tasks implemented, tested, and committed.
INVOKE jig:build using the Skill tool. Pass the plan path: "Execute the plan at {plans-directory}/<resolved-filename>-plan.md" (resolve plans-directory and filename-format from jig.config.md). The build skill analyzes the task graph and auto-selects parallel (team-dev) or serial (sdd) execution. Do not choose the strategy yourself.
Gate Check
Before proceeding, confirm:
Step 6: REVIEW
Gate: Code passes self-audit and automated review.
INVOKE jig:review using the Skill tool. The review skill dispatches the specialist swarm (security, dead code, error handling, async safety, performance + team specialists), scores findings, and produces a unified report. Fix any Critical or Major issues before proceeding.
Gate Check
Before proceeding, confirm:
Step 7: SHIP
Gate: PR created and merged.
- Commit: Invoke the
jig:commit agent (Agent tool with subagent_type: "jig:commit")
- Create PR: INVOKE
jig:pr-create using the Skill tool. It runs the review swarm, analyzes commits, and creates the PR.
- Address feedback: INVOKE
jig:pr-respond using the Skill tool for any reviewer comments.
- Merge: After approval
Gate Check
Step 8: LEARN (features only, optional for others)
INVOKE jig:postmortem using the Skill tool. It analyzes reviewer comments for patterns, identifies gaps in skills, and updates skills or configs. This closes the feedback loop.
Stage Transitions
The pipeline enforces ordering. Here's the complete transition map:
CLASSIFY
└──> DISCOVER (always)
├╌╌╌> BRAINSTORM (optional tool, returns to DISCOVER)
├╌╌╌> DEBUG (optional tool, returns to DISCOVER)
│
├──> PRD (features, large improvements — optional)
│ └──> REVIEW:prd → PLAN
│
└──> PLAN (always — transposes whatever source is available)
└──> REVIEW:plan → BUILD
└──> REVIEW:code (fast, per-task during build)
└──> REVIEW:code (full, pre-ship)
└──> SHIP
└──> LEARN (features, complex improvements)
Looping Back
The pipeline isn't strictly linear. You may loop back when:
- Plan is wrong → Return to Plan, revise tasks
- Scope changed during execution → Return to Brainstorm, update design
- Review finds design issues → Return to Plan or Brainstorm depending on severity
- PR feedback requires significant changes → Return to Execute
When looping back, update the plan document to reflect changes.
Common Mistakes
| Mistake | Consequence | Fix |
|---|
| Skipping Discover | No ticket, no branch convention, no tracking | Always start with the ticket |
| Skipping Requirements for features | Vague scope, acceptance criteria discovered mid-implementation | Run /prd before brainstorming |
| Skipping Plan for "simple" features | Can't parallelize, ad-hoc execution | Even 2-task plans help |
| Skipping Review | AI-generated bugs ship to production | Self-audit is non-negotiable |
| Skipping Learn | Same review feedback on every PR | Run postmortem on complex features |
| Starting with code | "Add a button" without understanding the requirement | Discover first, always |
| Forcing brainstorm before plan | Workflow friction; brainstorm is an optional tool | Offer brainstorm during DISCOVER; never gate plan on it |
| Skipping the TRANSPOSE step | Plan misses contract items, tasks don't tie to acceptance criteria | Plan's Step 1 transposes — verify every contract item maps to a task |
Quick Reference
| Stage | Skill Tool Invocation | Output |
|---|
| Classify | (kickoff handles directly) | Work type determined |
| Discover | (kickoff handles directly) | Ticket + branch |
| Requirements | Skill: jig:prd | PRD with acceptance checklist |
| Brainstorm (tool) | Skill: jig:brainstorm | Understanding, no artifact |
| Debug (tool) | Skill: jig:debug | Root cause, no artifact |
| Plan | Skill: jig:plan | {plans-directory}/*-plan.md |
| Execute | Skill: jig:build | Implemented + tested code |
| Review | Skill: jig:review | Audited code |
| Ship | Skill: jig:pr-create | Merged PR |
| Learn | Skill: jig:postmortem | Updated skills |
