Generated Context Documents: The Part of GSD That Makes the Rest of It Work

Every AI coding workflow eventually confronts the same bootstrapping problem. You need the model to understand your project, so you write a CLAUDE.md or a .cursorrules file. You write it from memory, imprecisely, and update it when something breaks visibly, which means it lags behind the project state by some number of incidents.

GSD (Get Shit Done) handles this differently in its bootstrap phase. You describe your project in natural language, and a meta-prompt generates your context documents: the spec templates, the CLAUDE.md, and the context anchor. Rather than writing these by hand, you specify what your project is and let the model produce the structured scaffolding that subsequent model interactions will depend on.

The difference is structural. A manually written CLAUDE.md reflects what you remembered to write, organized as you thought to organize it, updated when problems became visible. A generated one reflects a deliberate project description, structured according to what the model finds useful, and regeneratable from scratch when the project changes significantly.

The Generated-Artifact Pattern Applied to Context

In software, the distinction between generated artifacts and maintained documents is well-understood. You don’t hand-edit the Go files produced from your protobuf schema; you change the .proto source and regenerate. You don’t manually update an OpenAPI client library when your API changes; you regenerate it from the updated spec. The generated file is downstream of a source of truth, and it stays consistent with that source because it was produced from it.

GSD applies this pattern to context documents. The project description you write in plain language is the source. The generated CLAUDE.md, spec templates, and context anchor are downstream artifacts. When the project changes significantly, you update the description and regenerate.

The same logic extends to the session-level context anchor. GSD’s recommended practice is to regenerate it via meta-prompt at the end of sessions where significant decisions were made. The model receives the current codebase state, the original spec, and a summary of what changed. It produces a new context anchor reflecting current state. The previous version is replaced, not patched.

Why Regeneration Beats Incremental Patching

Incrementally patching a living document has a characteristic failure mode: the patches accumulate into a document that reflects the history of amendments rather than the current state. Earlier sections become implicitly contradicted by later ones. Reading the document requires triangulating across the whole thing rather than trusting any statement in isolation.

This is what happens to migration-heavy databases, multi-year configuration files, and any document that grew through amendments rather than replacement. Regeneration solves it at the cost of requiring explicit triggers, which is a smaller cost than accumulated consistency debt.

In AI development workflows, there is an additional problem with stale incremental context: a CLAUDE.md that accurately described the project three months ago will actively mislead the model about current constraints. The model has no way to distinguish a current constraint from a superseded one. A regenerated document based on current project state does not have this problem, because it was produced from current state.

This is worth taking seriously given what Liu et al.’s 2023 “Lost in the Middle” research established about transformer attention: models attend reliably to content at the beginning and end of long contexts, with degraded recall for content that drifts toward the middle as a session grows. A context document re-injected at the start of each session stays in the high-attention position. A stale one that confidently states superseded constraints does more damage than an absent one.

The Bootstrap Meta-Prompt

The practical shape of GSD’s bootstrap phase runs like this:

1. Write a plain-language description of your project: what it does, the tech stack, the main architectural decisions already made, the constraints that should never be violated.
2. Feed that to a meta-prompt that asks the model to produce a CLAUDE.md draft, a context anchor template, spec templates for your main feature types, and an initial architecture overview.
3. Review the output. The model contributes structure; you correct the substance.

The model generating these documents from a natural language description does something that hand-writing them does not: it forces you to articulate your project in terms that are meaningful at inference time. The constraint that lives in your head as “we avoid ORMs because they obscure query plans” needs to be in the description before it ends up in the generated docs. Writing the description is where implicit constraints surface.

This is the same forcing function that SWE-bench results point to: agents working from explicit specifications substantially outperform those working from implicit context, even with equivalent codebase access. The information that matters was not latent in the model’s capability; it was in whether the specification made key constraints explicit. The bootstrap meta-prompt creates a structural incentive to do that at project setup, rather than waiting for ambiguity to cause a visible failure.

For anyone building Discord bots or small services with an AI assistant, the immediate practical version is simpler than the full GSD system. Write a paragraph describing what your bot does, what persists across restarts, what commands exist and what each does under failure conditions. Feed that to a prompt asking the model to produce a CLAUDE.md. Review it. You will find constraints you had not written down, and the process of correcting the generated output is faster than composing from scratch.

What the Model Generates, the Model Can Use

There is a less-discussed benefit to model-generated context documents. The model generates structures that models find useful, shaped by what affects inference quality rather than what is easiest for a human to articulate.

A human-written CLAUDE.md tends to contain the things that were painful enough to document and the constraints that came to mind during a focused writing session. A model-generated one, produced from a comprehensive project description, is more likely to include the structural information that shapes behavior at inference time: the framework in use, the expected error handling patterns, the naming conventions, the boundary between what this service owns and what it delegates.

This is a probabilistic claim, not a controlled result. But the underlying logic holds: a model asked to produce context for another model invocation has some embedded knowledge, from training on large corpora of code generation interactions, about what context is useful and how it should be structured. That knowledge is embedded in the output when the task is given explicitly.

Rahul Garg’s work on context anchoring at MartinFowler.com converges on similar recommendations through a different path, grounding the pattern in the longer history of Architecture Decision Records and design documentation. The convergence between that formalization and GSD’s approach, developed independently, is the same signal the HN thread on GSD produced: experienced practitioners across different tools and domains independently arrived at the same workarounds, which suggests they are responses to fixed constraints in the underlying models rather than personal preferences.

The Maintenance Trade-off

The substantive objection raised in the HN discussion is maintenance overhead. A system based on periodic regeneration requires discipline around triggering it at the right moments. If you forget to regenerate after a significant decision, the context anchor drifts from the codebase in exactly the same way a manually maintained document does.

GSD’s practical answer is to make regeneration cheap enough that the trigger threshold is low. A meta-prompt that produces a new context anchor from current state takes one exchange. The previous version is replaced in place. The asymmetry between the cost of unnecessary regeneration (one exchange) and the cost of missed regeneration (context drift and incorrect subsequent assumptions) argues for erring toward frequent regeneration.

The more serious version of the objection is about team legibility. If the bootstrap and regeneration process requires someone who understands how to write a good project description and how to evaluate a generated context document, then the workflow works well for that person and creates a key-person dependency for everyone else. GSD’s documentation does not fully address this; the templates reduce the skill requirement but do not eliminate it.

The bootstrap and regeneration pattern is probably the least discussed part of GSD relative to the spec format and meta-prompting layer. Those components are visible in the output: you see the structured spec, you see the plan before the code. The maintenance pattern operates in the background and determines whether the visible components stay accurate over time. Getting the spec format right matters; keeping the context current is what makes the spec format useful a month into the project.