Post

Forgetting past decisions is exactly what a plan can't fix, because a plan is done once the change ships. A spec stays in the repo as the record of what was decided, so the next request gets checked against it instead of against memory.

Second: the files that teach Claude Code how my repo works. I got tired of explaining commit messages for the third time. CLAUDE.md = context Rules = policy Skills = know-how for a task Commands = scripts I'd otherwise write Hooks = what can NEVER be skipped

Specs without plans work only while each spec carries a checkable acceptance test. Without one, the agent fills the gap with plausible guesses and you find out in review.

You misunderstood... the plan is created for each spec & executed, but I don't keep plans once the work lands on main. The last step in merging the PR is "delete plan, then squash merge PR" so the plan is only kept until the work is complete. IOW, I don't create tons of specs then one big plan.

A spec is for a specific work effort (ie: implement/fix an issue), so there's no "go back & update". That would be like "go back and update last week's meeting agenda" - it already happened, so it's moot. You're thinking docs... those get updated to reflect the current state of site features.