spec-verify assumes docs/plans/ is gitignored but never tells users to gitignore it

[tfvchow]

Problem

spec-verify.md Step 3.11 item 5 (v7.6.0, 6c9136b) says:

Save plan to project root (gitignored, local reference)

This assumes docs/plans/ is gitignored. It is — in this repo (added in commit 6ae321b "fix: Changes for premium installation"). But for any user running /spec in their own project, docs/plans/ is a regular tracked directory unless they manually gitignore it.

What's documented (or not) — as of v7.6.0

Location	Mentions gitignoring plans?
.gitignore (this repo)	Yes — docs/plans listed (commit 6ae321b)
spec-plan.md	No — just says plans go to docs/plans/, silent on tracking
spec-verify.md	Assumes gitignored
Installer (claude_files.py)	Skips .gitignore files entirely — never sets up docs/plans in user projects
README	No mention

Impact

When docs/plans/ is git-tracked (the default for user projects):

• During planning, the plan file is created in the worktree and copied to the project root
• The worktree version gets updated throughout implementation (task checkboxes, status changes)
• On worktree sync, the outdated copy on the main branch conflicts with the newer version from the worktree
• This merge conflict happens on virtually every /spec run

The copy step is only needed when docs/plans/ is gitignored. For everyone else it creates unnecessary conflicts.

[SirHall]

It would be good to handle explicitly allowing committing of plans.
I find it useful for allowing the agent to refer to it later down the line when implementing bug fixes and it needs to know the initial intended behavior.

[maxritter]

Thanks @tfvchow for the detailed write-up and @SirHall for the feedback on keeping plans tracked — both points are spot on.

Fixed in the next release (v7.6.1). The plan copy step in both spec-verify and spec-bugfix-verify now checks git check-ignore first: if docs/plans/ is gitignored, it copies as before; if it's tracked, it skips the copy entirely and lets the squash merge bring the updated plan. No more merge conflicts on every /spec run.

This also means tracked plans work exactly as @SirHall described — they end up committed on main via the merge, available for future reference.

[github-actions]

🎉 This issue has been resolved in version 7.6.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀