Get Shit Done: The Meta-Prompting Layer Fighting Context Rot in AI Code Generation

Hook

After 12,000+ developers watched their AI coding assistants descend from coherent architecture to spaghetti code chaos mid-project, one repo asked: what if the problem isn’t the AI, but how we’re prompting it?

Context

AI coding assistants like Claude Code and Cursor have crossed the threshold from novelty to legitimately useful. Developers are shipping real features with them. But anyone who’s used these tools for more than a toy project has hit the same wall: around file 15 or conversation turn 30, the AI starts forgetting your architecture decisions. It rewrites authentication logic you established three days ago. It suggests patterns that contradict the ones it recommended an hour earlier. The industry calls this ‘context rot’ - the gradual degradation of output quality as the context window fills with noise.

Most solutions try to solve this with better models (more tokens! better retrieval!). Get Shit Done (GSD) takes a different approach: treating context management as a workflow discipline problem, not a model limitation problem. It’s a meta-prompting system that wraps your existing AI coding assistant with structured phases - research, discussion, planning, execution - maintaining state through markdown files and XML-formatted prompts. Instead of free-form ‘vibes-based’ prompting, you follow a spec-driven development process that explicitly captures requirements, decisions, and implementation preferences. It’s not trying to be a better AI tool. It’s trying to be a better way to use the AI tools you already have.

Technical Insight

GSD’s architecture is deceptively simple: it’s a set of structured prompts and slash commands that get installed into your AI assistant’s configuration directory. When you type /project-init, you’re not invoking a separate binary - you’re triggering a carefully crafted prompt that walks your AI through requirements gathering, storing the results in PROJECT.md and REQUIREMENTS.md. The real insight is how these prompts are structured to maintain coherence across sessions.

The system uses XML formatting to create clear boundaries in prompts, which helps models parse context more reliably. A typical GSD prompt looks like this:

<context>
  <project_requirements source="REQUIREMENTS.md">
    - Authentication using JWT tokens
    - PostgreSQL with Prisma ORM
    - RESTful API following JSON:API spec
  </project_requirements>
  <current_state source="STATE.md">
    - User model implemented
    - Auth middleware complete
    - Working on password reset flow
  </current_state>
  <implementation_preferences source="CONTEXT.md">
    - Prefer async/await over callbacks
    - Use Zod for validation schemas
    - Keep business logic in service layer
  </implementation_preferences>
</context>

<task>
  Implement password reset endpoint at POST /auth/reset-password
  Requirements: Send email, generate secure token, expire after 1 hour
</task>

This structured approach transforms the AI’s working memory from a chaotic pile of previous messages into indexed reference material. The model can ‘see’ that authentication decisions were made in REQUIREMENTS.md, not just infer them from conversation history.

The research phase is where GSD gets interesting for serious projects. Running /research spawns parallel AI agent instances - one investigating your codebase structure, another researching domain-specific patterns, another analyzing dependencies. Each agent writes findings to a shared research document. This parallelization matters because you’re not burning tokens asking the same AI to context-switch between “understand this Express codebase” and “research OAuth2 best practices.” You’re running focused investigations simultaneously.

The discussion phase (/discuss) is GSD’s most opinionated feature. Before planning implementation, it explicitly asks: How should errors be handled? What’s your preference for state management? Do you want optimistic updates or loading states? These preferences get captured in CONTEXT.md and injected into every subsequent prompt. This solves a subtle problem: AIs have default preferences (often toward over-engineering), and without explicit capture of your preferences, those defaults leak into implementation.

State management happens through STATE.md - a structured document tracking completed work, in-progress tasks, and blockers. After each coding session, you run /state-update to record what changed. The next session begins with this state injected into context. This isn’t groundbreaking technology - it’s project management discipline enforced through tooling. But that enforcement is what prevents context rot. Without it, you’re relying on the AI to remember what it did last Tuesday.

The execution phase (/execute) breaks planned tasks into subtasks and works through them sequentially, updating state after each. The key architectural decision here is that GSD doesn’t try to automate everything - it scaffolds the workflow but keeps the developer in the loop for decisions. You approve the plan before execution. You review changes before state updates. It’s collaborative automation, not hands-off automation.

Gotcha

GSD’s biggest limitation is that it’s not actually a tool - it’s structured prompts masquerading as tooling. You’re entirely dependent on the underlying AI assistant’s capabilities and quirks. If Claude Code decides to ignore your XML-structured context (which happens more than you’d like), GSD has no fallback. There’s no validation layer ensuring the AI actually read your REQUIREMENTS.md file before suggesting an implementation that contradicts it. You’re trusting the model to follow the meta-prompt’s structure.

The installation process reveals this dependency starkly. You either use the --dangerously-skip-permissions flag (bad idea for production work) or configure extensive permissions for the AI to read/write your markdown files, spawn parallel processes, and execute commands. This creates a security-versus-friction tradeoff that the documentation handwaves. For solo developers on personal projects, maybe fine. For teams with security requirements, this is a non-starter without significant hardening.

The marketing around GSD also raises questions about long-term viability. The project promotes a cryptocurrency token and positions itself aggressively against competitors with phrases like ‘enterprise theater.’ This might be authentic positioning or it might indicate the project’s focus will drift toward token economics rather than meta-prompting innovation. The aggressive star growth (12.7K in a relatively short time) suggests either genuine product-market fit or successful growth hacking - and distinguishing between those is hard until you see maintenance patterns six months out.

Verdict

Use GSD if: You’re already shipping real projects with Claude Code or similar AI assistants and you’ve personally experienced context rot derailing your workflow. You work solo or on small teams where security permission models can be loosely configured. You value structured workflows over tooling transparency, and you’re comfortable with the black-box nature of meta-prompting. The discipline of spec-driven development phases will actually improve your process, not just add ceremony.

Skip GSD if: You’re experimenting with AI coding tools for the first time - learn to prompt directly before adding meta-layers. You need to understand exactly how your tooling works (the XML prompt formatting is clever but opaque in practice). You work in environments requiring security audits or explicit permission models. The cryptocurrency token promotion makes you question where the project’s focus will be in six months. You prefer tools like Aider or Cursor Composer that integrate context management into the AI assistant itself rather than layering it on top. Or honestly, if you’re still writing most code yourself and using AI for occasional assistance - GSD’s overhead only pays off when AI is doing substantial generation work.