What 3 Months Did to My Claude Code Workflow
2026-06-08 · Jazz Lien
In March I open-sourced the workflow system I use to build with Claude Code: CLAUDE.md templates, a PM handbook, decision-framework skills, knowledge files. Last week I re-read it and found it was teaching old habits on a tool that had moved on. Seventy-six days. That is how fast the floor shifts right now.
So I ran a staleness audit on my own repo. Here is what broke, and why each one matters more than it looks.
Skills should fire on their own — I was still telling Claude to read them
The repo shipped skill files with description frontmatter, which is the exact thing Claude Code uses to auto-trigger a skill when your request matches it. And then every doc told you to invoke them by hand: Read .claude/skills/should-i-build-this.md and evaluate.... The capability was already in the file, switched off by the documentation wrapped around it.
A reader who pasted my instructions got a worse experience than my own files would have handed them for free. The fix: say what you want — "is this worth building?" — and let the frontmatter match. The manual Read form is now just an override for when you want to force a specific skill.
One line of advice now breaks the build it was meant to help
My edge-runtime notes told you to put export const runtime = 'edge' on every Next.js route, "or the build fails silently." That was correct on next-on-pages. It is now wrong on OpenNext (@opennextjs/cloudflare), which Cloudflare recommends and which runs on the Node runtime — there, that same line makes the build fail.
The advice did not get vaguer over three months. It inverted. So the fix was not a tweak; it was restructuring the whole file around one question you answer before writing any route: which runtime? The two paths have opposite rules, and presenting one path's constraints as universal is how you brick someone else's project.
The free security check was security theater
The one runnable security command in the kit was git log -p | grep -i "api_key". It is slow on any real repo, and it misses the shapes secrets actually take: sk-..., AKIA..., JWTs, a committed .env diff. It returns clean and you feel covered. I replaced it with gitleaks / trufflehog.
This one stung, because it was the only security tool in the free tier — the thing most people would actually run before a deploy.
The tool grew the features my conventions were faking
This is the uncomfortable one. A chunk of what the system did by hand, Claude Code now ships natively: file-based Memory instead of a hand-passed HANDOVER baton, Hooks instead of shell aliases, subagents instead of a serial multi-project status sweep.
The honest move was not to defend the markdown. It was to add a section that maps each convention to its native counterpart and says: reach for the native primitive first. The conventions still earn their place — they carry the judgment the harness does not ship, like what to decide and what "done" actually looks like. But pretending they were the only way to get persistence in 2026 would have been a lie of omission.
The lesson under the lesson
The repo had a rule in its own handbook: treat any document untouched for seven days as unreliable until you re-check it. The repo itself had gone seventy-six days. It failed its own test.
A workflow system is software, and software rots. So it now carries a CHANGELOG and a "last verified against Claude Code, June 2026" line at the top — not because a date is impressive, but because it tells a reader whether to trust the rest of the page.
If you ship anything on top of an AI tool
A workflow, a prompt library, a "system" — the half-life is shorter than you want it to be. Write down when you last checked it. The audit took an afternoon. Pretending it did not need one would have quietly cost every person who cloned the repo.
The refreshed system is on GitHub, with the full diff in the CHANGELOG. If you want the setup that this builds on, start with the three files that turn Claude Code into your dev partner.