____ ___ ____
/ ___|_ _/ ___|
| | _ | | | _
| |_| || | |_| |
\____|___\____|
A structured workflow system for Claude Code.
Gather decisions, implement in batches, govern quality. Two approval gates, zero decision fatigue. It's how I turn AI into reliable, governed output instead of vibe coding.
How it works
You tell Claude what you want. Claude does the rest — research, decisions, implementation, testing — and checks in with you at two gates before writing any code.
Init scaffolds project-type-specific Mermaid diagrams and flows directly into spec elicitation.
Each iteration is one loop — decide, build, verify:
/gig:milestone → spec: create milestone with stories, requirements, constraints
/gig:gather → decide: research, make decisions, build the plan
/gig:implement → build: execute batches with checkpoints
/gig:govern → verify: test, validate, track issues, archive
Repeat for the next iteration. That's the whole system.
Gather — decide what to build
You say what you want. Claude researches your codebase, makes every decision, and presents them in a batch:
| ID | Decision | Choice | Rationale (1-line) |
|-------|----------------------|----------------------------------------|-------------------------------------------------------|
| D-1.1 | Directory structure | Split templates into gig/ and project/ | Clean separation — state files vs user-facing output |
| D-1.2 | Initial templates | ARTICLE.md, README.md, RESEARCH.md | Three templates the user requested |
| D-1.3 | Copy destination | Project root, skip if exists | Respects user customization, not hidden in .gig/ |
| D-1.4 | Selection UX | Opt-in at init, user picks templates | Not every project needs an article or research doc |
| D-1.5 | ARTICLE.md migration | Move out of .gig/ state files | It was never a state file — clean break |
| D-1.6 | Upgrade behavior | upgrade.sh ignores project templates | Upgrade is for .gig/ state files, not project output |
Does this batch look good?
→ Approve — reply "approve" or "looks good" to lock these in.
→ Redline — reference by ID (e.g., "D-1.3: copy to docs/ instead").
→ Ask questions — about any decision before committing.
After you approve decisions, Claude builds the plan — small batches, one concern each:
Iteration 65 — Project Templates (v0.65.x)
| Batch | Version | Title | Status |
|-------|---------|------------------------------------------|---------|
| 65.1 | 0.65.1 | Restructure templates directory | pending |
| 65.2 | 0.65.2 | Create README.md and RESEARCH.md templates| pending |
| 65.3 | 0.65.3 | Update init skill for project templates | pending |
| 65.4 | 0.65.4 | Update tests | pending |
You approve again, then build.
Implement — build it batch by batch
Batches execute with auto-continue. Claude reports progress after each:
Batch 65.1 done — Restructure templates directory. Continuing...
Batch 65.2 done — Create README.md and RESEARCH.md templates. Continuing...
Batch 65.3 done — Update init skill for project templates. Continuing...
Batch 65.4 done — Update tests. Continuing...
All batches implemented. Run /gig:govern to validate.
You can interrupt anytime:
fix [thing] — insert unplanned work as the next batchpause — save state and stoprevise D-1.3 — change a decision mid-build
Independent batches run in parallel using Agent Teams with git worktrees.
Govern — verify before you ship
First, a quick manual verification step:
Quick Verify
The latest batch implemented: 65.4 — Update tests (all 4 batches complete)
Try these to confirm it works:
- ls templates/gig/ templates/project/ — should show split directory structure
- grep 'project templates' skills/init/SKILL.md — should match Step 1b
- ./test.sh — all 212 tests should pass
Reply "verified" or "skip" to continue with governance.
Then governance runs tests, checks acceptance criteria, audits every decision, and produces a report:
Acceptance Criteria
