TL;DR
The GAS (Gloriously Awesome System) framework structures work into phases and plans with explicit dependencies, verification steps, and summaries. Result: 51 completed plans averaging 1.6 hours each. Here’s how it works.
Introduction
The testkitchen projects started chaotic. Ideas everywhere. Half-finished features. No clear sense of progress.
Then I adopted GAS—a planning framework designed for AI-assisted development. Everything changed.
This isn’t about AI, though. The principles work regardless of how you code.
The Core Idea
Break Work Into Phases
A phase is a coherent unit of work:
- Has a single, clear deliverable
- Can be tested independently
- Takes 1-3 “plans” to complete
Break Phases Into Plans
A plan is one focused session:
- 45-120 minutes
- Single objective
- Explicit success criteria
The Document Structure
Every project has a .planning/ directory:
.planning/
├── PROJECT.md # What, why, requirements
├── ROADMAP.md # Milestones and phases
├── STATE.md # Current position
├── phases/
│ ├── 01-foundation/
│ │ ├── 01-01-PLAN.md
│ │ └── 01-01-SUMMARY.md
│ └── 02-core-engine/
│ ├── 02-01-PLAN.md
│ └── 02-01-SUMMARY.md
The PLAN Document
Every execution session starts with a plan:
## Objective
Implement hand comparison and winner determination.
## Dependencies
- Phase 01 complete (HandRank enum, EvaluatedHand struct)
## Success Criteria
- [ ] compare() function returns correct winner
- [ ] Tie detection works for identical ranks
- [ ] Kicker comparison handles all edge cases
## Verification
swift test --filter HandComparisonTestsWhy This Works
- Scope is clear - You know exactly what “done” means
- Dependencies are explicit - No surprises mid-session
- Verification is automated - Run one command to check
The SUMMARY Document
After each session, write what actually happened:
## What Was Done
- Implemented hand comparison (compare function)
- Added 15 test cases for edge cases
- Fixed kicker comparison bug discovered during testing
## Deviations from Plan
- Added split pot detection (not planned, but needed)
## Issues Discovered
- Ace-low straight not handling correctly (deferred to Phase 3)
## Duration
67 minutes
## Next Phase Readiness
- [x] All tests passing
- [x] Code reviewed
- [ ] Ace-low straight fix (deferred)Why This Works
- Honest retrospective - Plan vs. reality
- Deferred items tracked - No lost context
- Duration recorded - Velocity data
The Foundation-First Pattern
Projects that shipped fastest followed this architecture:
Phase 1: Foundation (setup, types, infrastructure)
Phase 2: Core Engine (business logic, no UI)
Phase 3: Primary Interface (CLI or main UI)
Phase 4: Secondary Interface (web or additional views)
Phase 5+: Features (polish, extensions)
Why This Order?
- Foundation - Establishes patterns, catches design issues early
- Core Engine - Pure logic, easy to test, no UI complexity
- Primary Interface - Validates the engine works
- Secondary Interface - Builds on working core
- Features - Polish on a solid base
Velocity Metrics
The Numbers
| Project | Plans | Avg Duration | Result |
|---|---|---|---|
| Poker | 8 | 60 min | v1.1 shipped |
| Eliza | 8 | 45 min | v1.0 shipped |
| QuestForge | 12 | 90 min | v1.2 shipped |
| MadLibs | 14 | 45 min | v1.1 shipped |
| GTD | 9 | 60 min | v1.0 shipped |
Totals: 51 plans, ~1.6 hours average
What Drives Speed
- Tight scope - 45-120 minutes per plan
- Explicit dependencies - No blocking surprises
- Verification commands - Instant feedback
- Summaries - Learn from each session
What Kills Velocity
1. Research During Execution
Problem: Discovering unknowns mid-session.
Solution: Flag research upfront:
type: research # vs. tdd or executeResearch sessions explore. Execution sessions deliver.
2. Scope Creep
Problem: “Just one more thing…”
Solution: Deferred items in SUMMARY:
## Deferred
- Animation polish (moved to v1.1)
- Settings screen (not MVP)Write it down. Move on.
3. Context Loss
Problem: Forgetting where you left off.
Solution: STATE.md:
## Current Position
- Phase: 3 of 4
- Plan: 1 of 2
- Status: In progress
- Last: 2026-01-12 — Completed hand evaluation testsThe STATE Document
The single source of truth for project position:
## Current Position
- Phase: 3 of 4 (game-ui)
- Plan: 2 of 3
- Status: Ready to execute
- Last activity: 2026-01-12 — Completed betting controls
## Progress
████████████░░░░ 75%
## Accumulated Decisions
- Using spring animation (0.3s, 0.7 damping)
- Cards dealt face-down, revealed on showdown
- AI thinking delay: 0.5-1.5 seconds
## Deferred Issues
- Ace-low straight (Phase 3, Plan 3)
- Sound effects (v1.1)Practical Implementation
Starting a New Project
- Create
PROJECT.mdwith requirements - Break into phases (foundation first)
- Create first
PLAN.md - Execute
- Write
SUMMARY.md - Update
STATE.md - Repeat
Resuming Work
- Read
STATE.md- Where am I? - Read last
SUMMARY.md- What happened? - Create next
PLAN.mdor continue current - Execute
Stalled Projects
- Document blockers in
STATE.md - Create research phase if unknowns exist
- Reduce scope to smallest deliverable
- Ship something, then iterate
The Checklist
Before Each Plan
- Dependencies satisfied
- Scope is 45-120 min
- Success criteria are specific
- Verification command ready
After Each Plan
- SUMMARY written immediately
- Deferred items logged
- STATE updated
- Next plan clear
Why This Works
GAS isn’t magic. It’s discipline:
- Write it down - Plans, summaries, state
- Keep it small - 45-120 minute chunks
- Be honest - Plan vs. reality in summaries
- Track velocity - What actually takes how long
The framework doesn’t do the work. It makes the work visible.
Conclusion
51 plans. 1.6 hours average. 5 projects shipped.
The secret isn’t working faster. It’s:
- Knowing exactly what “done” means
- Breaking work into testable pieces
- Learning from each session
GAS gave me that structure. The results speak for themselves.
This post concludes the “Building Apps in Public” series. See the overview for the full index.