A developer was building a music library app with Claude. Week one went beautifully. Features shipped fast, the architecture felt clean, and Claude was a genuine partner in the build. By week three, things had quietly fallen apart. Claude was deleting features it had built two sessions earlier, breaking integrations that had worked fine, and couldn’t explain why. The playlist module that took two hours to build? Gone. The tagging system they had explicitly discussed? Overwritten with something new that conflicted with the database schema.
The dev almost restarted from scratch. Then they ran a /COUNCIL session instead.
The twist nobody talks about
The root cause wasn’t Claude being dumb. It was the dev talking to Claude like a human with memory. Claude has none.
Every new chat window is a blank slate. No project history. No “remember when we built the playlist module.” No awareness of the decisions you made three sessions ago or why you made them. When you open a new chat and just say “continue building the app,” Claude is starting cold with whatever context you paste in that moment. As complexity grew without a proper brief, Claude started guessing and filling gaps on its own. It made decisions that seemed locally reasonable but were globally destructive. It didn’t know what it didn’t know. And neither did the dev, until the damage was already done.
This is one of the most common failure modes in multi-session AI development, and almost nobody talks about it because it feels embarrassing to admit. You think you’re working with a collaborator. You’re actually working with a very capable contractor who forgets everything between meetings and has to reconstruct the project from whatever scraps you hand them. The scraps you hand them matter more than the model you’re using.
How to stop the drift: build a project skill file
- 🗂️ Create a
PROJECT_SKILL.mdfile in your project root. One file, always in the same place. Treat it as the single source of truth for what this project is and what you’ve already decided. Not a running doc. Not a dump of everything. A tight brief. - 📋 Fill it with: project overview, current architecture, active priorities, and a hard “do not touch” list. Be specific. Don’t write “we have a playlist module.” Write “the playlist module lives in /src/playlist/, uses SQLite, handles add/remove/reorder, and the schema is frozen.” The more specific your constraints, the less Claude has to guess. Guessing is where drift starts.
- 🔄 Paste the whole file at the start of every new session before writing a single prompt. Every single time. Even if it feels redundant. This is the ritual that keeps context alive across sessions. Think of it as handing your contractor the project brief before every meeting instead of assuming they remember what you talked about last week.
- 🔍 When Claude goes sideways, run a council review: ask it to trace its own decisions back to root cause. Tell it what went wrong, show it the skill file, and ask it to explain the reasoning chain that led to the regression. This sounds slow but it’s faster than hunting for the bug yourself, and it surfaces the silent assumptions Claude was making the whole time.
Pro tips
- Keep the skill file under 300 words. Claude reads long context but doesn’t weight it evenly. A 2,000-word project file sounds thorough but constraints buried in the second half get a fraction of the attention compared to what’s up top. Ruthless brevity is a feature. If something is important enough to protect, it belongs in the first third.
- Explicit constraints beat implicit ones. “Don’t touch the auth module” outlasts “you know what we’ve built” every time. Implicit knowledge decays across sessions. Explicit rules don’t. Every hard constraint in your project should live in the skill file as a named rule, not as an assumption you carry in your head and expect Claude to share.
- The council technique (using Claude to audit its own behavior) is one of the most underrated moves in agentic work. It works because you’re not asking Claude to guess what went wrong. You’re asking it to reason through the failure with full context in front of it. When something breaks, run the council before you touch a line of code. You’ll save hours.
- Version your skill file. Every time you make a significant architectural decision or lock down a new constraint, add a date stamp and a one-line note explaining why. Future you will thank you when you need to remember why a rule exists three months from now.
The dev shared the full council report and project skill template (in both German and English) publicly via Google Drive. The report includes Claude’s full reasoning trace, the exact decisions that caused the regression, and the skill file structure they landed on after the fix. If you’re running any multi-session build project, this is worth 15 minutes of your time. The template alone will save you from the most common way agentic projects go quietly sideways. 🚀
Claude bypassing rules and f***ing things up – Or how I spoke to Claude too much like I speak to humans. Encountering memory issues and a skill / project prompt to make things better (to be proven)
by u/Soggy-Pay-8027 in PromptEngineering