Monday, April 20, 2026

🚀 Engineering to Win: Mastering the Get Shit Done (GSD) Framework

 

In the world of AI-driven development, we’ve all experienced “vibecoding”—that honeymoon phase where you prompt an AI, and it magically builds a small app. But as the codebase grows, the “vibes” turn into a nightmare. 📉

Enter Context Rot: the gradual degradation of AI accuracy as the context window fills with chat history and messy code snippets. To scale beyond simple scripts, you need an industrial-strength layer. 🏗️

Introducing the Get Shit Done (GSD) framework—a specialized context engineering and meta-prompting layer designed to scale AI-driven development for complex, long-term projects.

🧠 Core Philosophy: The Fresh Context Strategy

GSD moves away from the “one long chat” model. Instead, it treats context as a managed resource.

  • Main Context (The Brain): Stays lean (30–40% capacity), managing high-level state, project orchestration, and the roadmap. 🛰️
  • Worker Contexts (The Muscle): For every task, GSD spawns a fresh AI instance with a clean 200,000-token window. This ensures the AI approaches the 50th task with the same surgical precision as the first. ⚡

🛠️ The GSD Workflow: The “Big Four” Gates

GSD enforces a Spec-Driven Development (SDD) lifecycle, ensuring every line of code is traceable to a requirement.

1. Discuss (/gsd:discuss-phase) 🗣️

Before a single line of code is written, the framework interviews the developer. It surfaces technical debt, architectural constraints, and UI/UX “gray areas.”

  • Outcome: A shared understanding captured in project-local “skills.”

2. Plan (/gsd:plan-phase) 📝

Parallel Research Agents investigate libraries and patterns.

  • Outcome: A highly structured, XML-formatted PLAN.md. This plan is “executable”—the AI follows it like a script, not a suggestion.

3. Execute (/gsd:execute-phase) ⚙️

GSD uses Wave Execution to handle dependencies.

  • Wave 1: Independent tasks run in parallel.
  • Wave 2: Dependent tasks trigger only after Wave 1 succeeds.
  • Atomic Commits: Every task results in a surgical git commit, making git bisect a breeze.

4. Verify (/gsd:verify-work) ✅

A final validation gate where the framework walks through the implementation goal-backward. It includes interactive UAT (User Acceptance Testing) and automated debugging.

🔧 Technical Components

  • Context Engineering: Surgically injects only relevant files into the worker context to prevent “hallucination drift.” 💉
  • State Management: Files like STATE.md and ROADMAP.md act as the project’s persistent brain. You can pause for weeks and resume exactly where you left off. 💾
  • Multi-Runtime: Optimized for Claude Code, but compatible with Gemini CLI, Roo Code (Cline), and Cursor. 💻

🏃‍♂️ GSD in Action: Common Scenarios

| Scenario | Primary Workflow & Commands 🛠️ |

1. New Feature Development

  • Initialization: Run /gsd:map-codebase to ensure the assistant understands the current state of the Ticket Management System (Angular/Spring Boot stack).
  • Requirement Scoping: Use /gsd:new-project or manually update REQUIREMENTS.md and ROADMAP.md to define the feature, acceptance criteria, and its position in the project timeline.
  • Phase Discussion: Run /gsd:discuss-phase [N] to resolve gray areas (e.g., UI layout for the new dashboard or specific API response formats).
  • Planning: Execute /gsd:plan-phase [N]. This spawns research agents to investigate the best implementation patterns and creates atomic PLAN.md files.
  • Execution: Run /gsd:execute-phase [N]. GSD will execute plans in parallel waves, creating atomic commits for each task.
  • Validation: Finalize with /gsd:verify-work [N] for a goal-backward QA walkthrough.

2. Change Request (CR)

  • Refinement: Update REQUIREMENTS.md with the modified scope.
  • Context Alignment: Run /gsd:discuss-phase [N] --force to re-evaluate the phase context based on the new requirements.
  • Re-planning: Execute /gsd:plan-phase [N]. GSD will detect schema drift or logic changes and update the task plans.
  • Targeted Execution: Run /gsd:execute-phase [N] to implement changes.
  • Regression Check: Use /gsd:verify-work [N] to ensure existing features remain intact.

3. Bugs & Defects

  • Investigation: Run /gsd:debug "[Bug Description]" to spawn debugging agents that trace the root cause across the stack.
  • Quick Fix: For isolated defects, use /gsd:quick "fix [bug ID] in [component]" to leverage the “Quick Mode” which skips long research phases but maintains atomic commits.
  • Verification: Run the specific verification steps generated in the debug plan to confirm the fix.

4. Security Enhancement

  • Threat Modeling: Run /gsd:discuss-phase [N] and explicitly mention security goals (e.g., “Implement JWT rotation” or “Sanitize SQL inputs”).
  • Secure Planning: Run /gsd:plan-phase [N]. GSD’s security enforcement anchors verification to threat models during this stage.
  • TDD Execution: Ensure workflow.tdd_mode: true is set in .gsdconfig. Run /gsd:execute-phase [N] to enforce a Red/Green/Refactor sequence for security logic.

5. Security Issues (Hotfixes)

  • Immediate Action: Execute /gsd:quick "hotfix: [vulnerability description]" --dangerously-skip-permissions.
  • Isolated Context: GSD creates a fresh 200k context for the fix to prevent “context rot” from interfering with the security patch.
  • Verification: Run /gsd:verify-work [N] immediately after execution to ensure the vulnerability is closed without side effects.

6. Performance Enhancement

  • Research Phase: Run /gsd:plan-phase [N] with a focus on “Research.” GSD will spawn parallel agents to investigate bottlenecks (e.g., MySQL query optimization or Angular change detection).
  • Optimization Plan: Review the {phase}-RESEARCH.md and approve the optimization plans.
  • Execution: Run /gsd:execute-phase [N] to apply performance patches.

7. Performance Issues

  • Diagnostic: Use /gsd:debug "High latency on [API endpoint]" to analyze resource consumption.
  • Repair: Execute the repair tasks identified by GSD’s node_repair workflow.
  • Baseline Check: Run /gsd:verify-work to compare performance against the required metrics in PROJECT.md.

8. UI/UX Refactoring

  • Visual Discussion: Run /gsd:discuss-phase [N] (or /gsd-ui-phase if available) to define interactions, empty states, and density for the Angular frontend.
  • Design-First Planning: Use Spec-Kit or Stitch patterns within the PLAN.md to ensure UI consistency.
  • Execution: Run /gsd:execute-phase [N] to refactor components.

9. Middleware/API Updates

  • Contract Alignment: Update API definitions in PROJECT.md or REQUIREMENTS.md.
  • TDD Planning: Run /gsd:plan-phase [N]. Ensure the planner applies type: tdd to API tasks.
  • Execution: Run /gsd:execute-phase [N]. The executor will enforce valid response formats and error handling as defined in the CONTEXT.md.

10. Technical Debt/Refactoring

  • Codebase Mapping: Run /gsd:map-codebase to refresh the assistant’s understanding of legacy patterns.
  • Refactor Planning: Create a dedicated phase in ROADMAP.md for refactoring.
  • Atomic Refactoring: Execute /gsd:execute-phase [N]. GSD’s atomic commits are critical here to allow for easy rollbacks if a refactor breaks a dependency.

11. DevOps & Infrastructure

  • Environment Scoping: Define infrastructure requirements (e.g., MySQL Docker config or Spring Boot profile settings) in PROJECT.md.
  • Infrastructure-as-Code (IaC): Run /gsd:plan-phase for the DevOps tasks.
  • Execution: Run /gsd:execute-phase to generate or update CI/CD pipelines, Dockerfiles, or deployment scripts.

🎯 When to Use GSD

GSD isn’t for a “Hello World” script. It’s for industrial-strength engineering:

  • Complex Full-Stack Apps: (e.g., Angular + Spring Boot) 🌐
  • Multi-Session Projects: Building over weeks or months. 📅
  • Zero-Debt Environments: Where traceability and clean git history are non-negotiable. 💎

📋 Summary of GSD Commands

CommandPrimary Use Case
  • | /gsd:new-project | Greenfield features and initial project setup. |✨
  • | /gsd:map-codebase | Synchronizing GSD with an existing codebase (Technical Debt/Refactoring). | 🗺️
  • | /gsd:discuss-phase | Clarifying UI, API, or Security decisions. | 🗺️
  • | /gsd:plan-phase | Research and create atomic plans. Researching and creating atomic implementation plans. | 📋
  • | /gsd:execute-phase | Parallel execution of tasks with fresh contexts and atomic commits. |🚀
  • | /gsd:verify-work | UAT and final requirement validation. | 🧪
  • | /gsd:quick | Hotfixes, small bugs, and ad-hoc changes. |
  • | /gsd:debug | Complex root-cause analysis and automated repair. |

Lets take a simple example where in we have a PRD.txt file with us and execute the above said command for th development scenario.
i.e.
New Feature Development

We have PRD.txt we will first execute scenario

New Feature Development

Simlarly try for other development aspect and do share your feedback.

Change Request (CR)
Bugs & Defects
Security Enhancement
Security Issues (Hotfixes)
Performance Enhancement
Performance Issues
UI/UX Refactoring
Middleware/API Updates
Technical Debt/Refactoring
DevOps & Infrastructure.

Source code:- https://github.com/shdhumale/siddhu-gsd-project.git

Ready to stop vibecoding and start engineering? It’s time to Get Shit Done. 💪

Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)