Use a Three-File Dev-Docs Pattern to Outlast Context Resets
A single plan.md works well for simple tasks, but as a project grows you lose track of why decisions were made. Splitting your dev docs into three focused files means the context that matters most survives /compact and context resets.
The three-file structure:
[task]-plan.md # Strategic overview, phases, goals
[task]-context.md # Key decisions made, file references, gotchas
[task]-tasks.md # Checklist of remaining work items
Set up a /dev-docs slash command to generate all three automatically at the start of a new task:
# .claude/commands/dev-docs.md
Generate three dev-docs files for the current task:
1. $TASK-plan.md — high-level strategy and phases
2. $TASK-context.md — decisions made so far and key file paths
3. $TASK-tasks.md — remaining checklist items, one per line
Use the current task name as the $TASK prefix.
The separation earns its weight when things go wrong. After a context reset, Claude needs to re-orient fast. A single long plan.md blurs together intent, decisions, and todos. With three files, Claude can load just the tasks checklist to find the next action, or just the context file to understand a decision, without wading through everything else.
Update [task]-context.md every time you make a decision worth remembering. It becomes a lightweight decision log that survives as long as the files do.
Three focused files beat one bloated plan every time.
via Claude Code is a Beast – Tips from 6 Months of Hardcore Use
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.