Research the problem, make decisions, and build the implementation plan. Two approval gates, one command.
From gignpx claudepluginhub gregrossdev/gigThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Read .gig/STATE.md and display:
Version: {version} | Iteration: {iteration} | Status: {status}
If status is "GATHERED" or later, warn: "Gathering already complete for current iteration. Running /gig:gather will start a new round. Continue?"
Check if .gig/ exists in the current project root.
If NOT present:
Say: "No gig context found. Run /gig:init first." STOP.
If present:
.gig/STATE.md for current position..gig/DECISIONS.md for existing decisions..gig/ARCHITECTURE.md for structural context..gig/ROADMAP.md for milestone context..gig/ISSUES.md for open issues from prior iterations..gig/SPEC.md if it exists — this is the spec for the current milestone..gig/DESIGN.md if it exists — UI/UX design decisions and Figma prototype links..gig/DEBT.md if it exists — structural debt from prior iterations.If .gig/SPEC.md exists and has content beyond the template: Use it as the foundation for decisions. Every decision should trace to a requirement in the spec.
If .gig/SPEC.md does not exist or is empty: Print: "No spec found. Consider running /gig:spec first for complex features." Then proceed as normal.
If .gig/DESIGN.md exists and has content: Use it as design context for decisions. Reference Figma designs when making UI-related decisions. Link decisions to design screens where applicable.
If .gig/DESIGN.md does not exist: Proceed normally. Design is optional.
If .gig/DEBT.md exists and has entries: Note outstanding debt items. Surface them in Step 2 if relevant to the iteration goal.
Check .gig/ROADMAP.md for an Upcoming Iterations section with entries.
If user provided args: Check if the args match an entry name in the Upcoming Iterations table (case-insensitive). If matched, consume that entry (see "Consuming an Upcoming Iteration" below). If no match, use the args as a freeform goal and skip to "After intent is set".
If user did NOT provide args and the Upcoming Iterations table has entries: Take the first row of the table.
skip to choose something else."skip, ask: "What do you want to build or accomplish?"If no upcoming iterations and no user goal: Ask the user ONE open-ended question: "What do you want to build or accomplish?"
If the user already stated their goal (same message or prior context), skip and proceed.
When an iteration is selected from the Upcoming Iterations table:
.gig/ROADMAP.md.planned: | {N} | {Name} | v0.{N}.x | planned |If there are open issues from .gig/ISSUES.md (deferred from prior iterations), surface them:
"Open issues from prior iterations: {list}. Want to address any of these?"
If .gig/DEBT.md has OPEN or TRACKED entries and the iteration goal involves refactoring or structural work, surface relevant debt items:
"Outstanding technical debt: {list DEBT IDs and titles}. Want to include any of these in the refactor scope?"
Do NOT ask follow-up questions — Claude researches and decides in Steps 3-4.
Before launching deep research, assess whether this is a docs/config iteration:
Indicators (any match triggers lightweight mode):
If lightweight mode detected: Say: "Docs/config iteration — using lightweight research path."
If the user says "do full research": Override and run the standard path. If work turns out to involve code changes: Escalate to the full path mid-gather.
Before making ANY decisions, research thoroughly:
Launch 3 Explore agents in parallel (Agent tool, subagent_type "Explore"), one per profile:
.gig/ARCHITECTURE.md, package/config files, iteration goal..gig/ISSUES.md, iteration goal..gig/ROADMAP.md, .gig/BACKLOG.md, .gig/SPEC.md, iteration goal.All agents also receive working memory from .gig/STATE.md.
For projects with iteration history, launch all 3 agents. For new projects with minimal codebase, launch 2 minimum (Architecture + Discovery).
If the goal involves external libraries or APIs, add WebSearch calls in the same parallel block as the agents.
Synthesize findings from all agents before proceeding to Step 3a. Identify unknowns, ambiguities, and areas with multiple valid approaches.
Do NOT skip this step. Do NOT guess. Decision quality depends on thorough research. Exception: docs/config iterations use the lightweight path from Step 2b instead.
After research completes, append an architecture assessment to .gig/ARCHITECTURE.md under the ## Audit Log section:
### Iteration {N} — {date}
{2-3 line assessment of structural health based on research findings: patterns observed, consistency with ARCHITECTURE.md, any concerns or drift}
This builds a running record of architectural observations across iterations.
After research and before presenting decisions, generate Mermaid diagrams to model the system:
.gig/design/ directory if it doesn't exist. If existing .mmd files are present, read them — these are living diagrams that evolve across iterations. Update and extend them based on research findings rather than replacing them..gig/design/architecture.mmd) — system components and relationships.gig/design/data-flow.mmd) — how data moves through the system.gig/design/sequence.mmd) — key interaction sequences.gig/design/er.mmd) — data models and relationships.gig/DESIGN.md exists, reference Figma prototypes in the diagrams where UI components interact with the system.These diagrams inform decisions in Step 4 and are referenced in the plan.
Ask yourself every question that needs answering. For each, make a decision. Organize into a single batch of 3-7 decisions.
Per decision:
D-{batch}.{num} (e.g., D-1.1, D-1.2).gig/design/{filename}".If more than 7 decisions are needed, split into multiple batches and present sequentially.
Update .gig/STATE.md:
GATHERING.Do NOT write to DECISIONS.md yet. Present decisions in chat only.
If a spec exists: Include **Spec:** v{X.Y} (read from the SPEC.md version header) when presenting the decision batch.
Present the following table in full. Do not abbreviate, inline, or collapse into prose.
| ID | REQ | Decision | Choice | Rationale (1-line) |
|---|
If no spec exists, omit the REQ column.
Then say:
Does this batch look good?
- Approve — reply "approve" or "looks good" to lock these in.
- Redline — reference by ID (e.g., "D-1.3: use X instead").
- Ask questions — about any decision before committing.
STOP. Do not create a plan. Do not write code. Wait for approval.
Once approved (with or without redlines), write all decisions to .gig/DECISIONS.md directly as ACTIVE entries:
## {TODAY'S DATE} — {Domain}: {Question}
**Decision:** {What was decided}
**Rationale:** {Why — reference research findings}
**Alternatives considered:** {What else was viable and why rejected}
**Status:** ACTIVE
**ID:** D-{batch}.{num}
**Spec:** v{X.Y}
For redlined decisions: write only the user's final choice as ACTIVE. Do not write the original proposal.
Update .gig/STATE.md:
Say: "Decisions locked. Building the plan..."
After decisions are locked, call EnterPlanMode to design the iteration plan. In plan mode, Claude explores the codebase and designs the batch breakdown — no writes to .gig/ files yet.
Look at .gig/ROADMAP.md iterations table and .gig/iterations/ directory.
1.The iteration version follows the batch versioning rule: MINOR = iteration number.
0.1.x0.2.x0.N.xDerive iteration name from the decisions context. Format: v0.{N}-{kebab-case}.
Using ACTIVE decisions as requirements, break work into batches. Each batch is a small, coherent unit:
For each batch:
### Batch {iteration}.{N} — {Title}
**Delegation:** {team | subagent | in-session}
**Decisions:** {Decision IDs this implements, e.g., D-1.1, D-2.3}
**Type:** {feature | refactor}
**Spec:** v{X.Y}
**Files:** {files to create or modify}
**Work:** {What to do}
**Test criteria:** {specific verification — command, file check, behavior}
**Acceptance:** {What "done" looks like}
Default type is feature. Set to refactor when the iteration goal is structural work or driven by DEBT.md items.
Delegation defaults:
team — Independent batches with no dependency between them. This is the default for implementation. When 2+ batches have no dependency chain, mark them all as team so they execute in parallel via worktrees.subagent — Research/exploration feeding other tasks.in-session — Sequential, needs shared context or depends on another batch.Hard rule: Every implementation batch MUST have test criteria.
Tag dependencies explicitly: "Depends on Batch X.Y".
Present the following plan in full with the batch table. Do not abbreviate or collapse into prose.
Then call ExitPlanMode for user approval.
Do not write any .gig/ files while in plan mode. Wait for approval.
Once the user approves the plan (exits plan mode):
Step 9 — Write the Plan
Write the iteration to .gig/PLAN.md, replacing the "Active Iteration" section:
## Active Iteration
### Iteration {N} — {Name} (v0.{N}.x)
> {One-paragraph goal derived from decisions}
**Decisions:** {list all ACTIVE decision IDs this iteration implements}
**Type:** {feature | refactor}
**Spec:** v{X.Y}
| Batch | Version | Title | Delegation | Status |
|-------|---------|-------|------------|--------|
| {N}.1 | `0.{N}.1` | {title} | {mode} | pending |
| {N}.2 | `0.{N}.2` | {title} | {mode} | pending |
| ... | ... | ... | ... | ... |
{Full batch details from Step 8}
**Iteration Acceptance Criteria:**
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] ...
**Completion triggers Iteration {N+1} -> version `0.{N+1}.0`**
Step 10 — Update State & Roadmap
Update .gig/STATE.md:
0.{N}.0GATHEREDUpdate .gig/ROADMAP.md iterations table:
| {N} | {Name} | v0.{N}.x | planned |