# Spec-Driven Context Resets for Coding Agents

Canonical URL: https://huecki.com/en/blog/spec-driven-context-resets-for-coding-agents/
Markdown URL: https://huecki.com/en/blog/spec-driven-context-resets-for-coding-agents.md
Language: English
Published: 2026-05-23
Updated: 2026-05-23
Author: Dominic Hückmann
Topic: AI-first Engineering
- Agent topics: Context Engineering, LLM-native Engineering
- Tags: AI Engineering, Coding Agents, Context Engineering, Spec-Driven Development, Developer Workflow
Content status: field-note

## Summary

Long agent chats rot. A better pattern is to move decisions into small spec files, clear context between layers, and let each coding-agent session read only the artifact it needs.

## Description

A practical workflow for using requirements, analysis, design, and task files to reset coding-agent context without losing the decisions that matter.

## Body

Long coding-agent chats have a smell.

At first, the agent is sharp. Then the conversation grows. Old assumptions linger. New decisions mix with abandoned plans. The model starts optimizing for the last few messages instead of the actual feature.

The usual fix is more context. That is often backwards.

A better move is to reset context on purpose, but keep the important decisions in files. The interesting pattern in [sddw](https://github.com/sermakarevich/sddw), a spec-driven workflow for Claude Code, is not merely “write specs before code.” It is this: every stage produces one durable artifact, then the next stage reads only the relevant artifacts inside a fresh, focused context window.

That turns context reset from a panic button into an engineering technique.

## The short version

Do not keep the whole feature alive in one giant chat.

Move the work through small files:

After each layer, stop. Review the file. Clear the chat. Start the next session with the current artifact and the project rules.

The point is scope control.

A coding agent does not need every paragraph of the previous discussion. It needs the current contract: what must be true, which files matter, and what evidence will prove the work.

## Why context resets help

Context windows are not neutral storage. They are messy working memory.

Old ideas compete with new instructions. Half-rejected options stay visible. The model may preserve details that should have died and forget decisions that should have survived.

Spec files give you a cleaner memory boundary.

This is why good teams write tickets, design docs, migration plans, and ADRs. Coding agents make the failure mode obvious: if state only lives in chat, it decays.

## The practical workflow

Use four files for any feature that feels too large for one clean agent pass.

```txt
.sddw/feature-name/
  requirements.md
  analysis.md
  design.md
  tasks/
    01-first-task.md
    02-second-task.md
```

Then run the work like this:

1. Ask the agent to produce `requirements.md` only. Include user stories, constraints, and acceptance criteria. Stop.
2. In a fresh context, ask it to inspect the codebase and write `analysis.md`. Stop.
3. In a fresh context, ask for `design.md`: the approach, touched modules, interfaces, risks, and verification plan. Stop.
4. In a fresh context, break the design into task files. Stop.
5. In a fresh context, implement exactly one task file. Run the verification listed in that task. Write back any lesson or blocker.

The stolen prompt:

```txt
Create requirements.md, analysis.md, design.md, and task files for this feature.
After each file, stop.
The next session should read only the current file, the project rules, and the minimum source files needed.
Each implementation task must include: goal, allowed files, constraints, verification commands, and done evidence.
```

That last line matters. Without verification, specs become prettier vibes.

## What this replaces

The reset is not about making the model forget. It is about choosing what survives.

## Where it fails

This workflow can fossilize bad thinking. If `requirements.md` misunderstands the feature, every later stage becomes confidently wrong. If `analysis.md` misses an important code path, the design will route around reality. If task files are too broad, you are back to the same overloaded context problem with extra markdown.

So keep the human review points short and sharp:

## The normal-person version

The same pattern works for a renovation, legal checklist, trip plan, hiring process, or messy research project:

```txt
requirements → current situation → plan → tasks → one task per fresh context
```

Stop asking AI to remember everything. Make it write the memory worth keeping, reset the rest, and continue from the smallest useful artifact.

That is the quiet power of spec-driven context resets: not more context, better boundaries.

## Source

- [sddw: Spec-Driven Development Workflow for Claude Code](https://github.com/sermakarevich/sddw)
- [Hacker News discussion: Spec-Driven Development Workflow for Claude Code](https://news.ycombinator.com/item?id=48231575)

## FAQ

### What is a spec-driven context reset?

It is a workflow where requirements, code analysis, design, and implementation tasks are written to files, then the chat context is cleared between stages so the next coding-agent session works from focused durable artifacts instead of a bloated conversation.

### When should I use this workflow?

Use it for medium-size features, refactors, migrations, and agent tasks where architectural decisions matter and the work spans more than one clean context window.

### When is it overkill?

It is usually too slow for tiny fixes, one-file copy edits, throwaway prototypes, or tasks where the cost of maintaining specs is higher than the risk of context drift.