Skill chain assumes frozen codebase — parallel sessions cause spec/plan staleness

[csillag]

Problem

The brainstorming → writing-plans → execution skill chain implicitly assumes the codebase doesn't change between initial analysis and execution completion. This assumption breaks when users run multiple AI coding agent sessions in parallel against the same repository — a natural workflow where one session brainstorms while another implements and merges a different feature.

This affects all platforms that superpowers integrates with (Claude Code, OpenCode, Cursor, Codex, Gemini CLI), since the issue is in the skill chain's design, not in any platform-specific tooling.

The timeline

Point A: brainstorming skill analyzes codebase for context
         ↓ (clarifying questions, approach selection, design review)
         spec is written against code state at point A
         ↓
Point B: writing-plans skill reads code to generate implementation plan
         ↓ (user reviews plan)
Point C: execution begins (subagent-driven-development or executing-plans)
         subagents follow the plan step by step

What goes wrong when another session merges to main between A and C

1. Spec becomes stale — it describes a solution to a codebase that may no longer exist (files renamed, patterns changed, interfaces refactored by the other session)
2. Plan becomes stale — it contains exact file paths, line numbers, and code snippets that may no longer match the actual code
3. Execution subagents can't adapt — they follow the plan mechanically, often running on lower-capacity models. They aren't equipped to re-evaluate whether the plan still makes sense given changes they don't know about

Re-analysis at point B partially helps (writing-plans reads the actual code), but it's constrained by the spec — it implements what the spec says, not what might now be appropriate given new changes. And changes arriving between B and C are completely invisible to the execution phase.

Who this affects

Anyone running parallel sessions against the same repo. This doesn't require a team — a single developer running 3-4 sessions simultaneously (brainstorm in one, implement in another, review in a third) hits this naturally.

Proposed solution

Two parts: isolate at the start, and validate before merging.

1. Code isolation before analysis

The codebase should be frozen before point A — before the initial analysis that informs the spec. This way all analysis, spec writing, planning, and implementation happen against a consistent snapshot. No surprise changes can arrive from other sessions.

The technical implementation of this isolation will differ by platform:

• Claude Code already has git worktree support (isolation: "worktree"). The fix may be as simple as moving the existing worktree activation from point C (where subagent-driven-development currently suggests it) to before point A (when brainstorming begins).
• Other platforms (OpenCode, Cursor, Codex) lack programmatic worktree support today. They would need either native worktree tooling, or an alternative isolation mechanism (e.g., the skill chain could shell out to git worktree add directly, or use a different approach entirely).

2. Rebase + delta analysis before merging

After execution completes and before merging the work back:

1. Rebase onto current main (surfaces mechanical conflicts)
2. Run a delta analysis using a high-capacity model: diff what changed on main since the branch point, and evaluate whether those changes conflict with or invalidate the spec and implementation
3. If the delta analysis finds substantial conflicts, initiate a new round of brainstorming rather than trying to patch

This catches semantic drift that a clean rebase wouldn't flag — for example, another session refactored the module you were extending, and while git can merge the changes cleanly, the approach described in your spec is no longer appropriate.

Notes

• For Claude Code, the worktree-at-start approach is likely straightforward since the tooling already exists — it's a matter of invoking it earlier in the skill chain.
• For platforms without worktree support, this is a harder problem and may require platform-specific solutions. Even without full isolation, a lightweight staleness check ("have any files referenced in the plan changed since point A?") would catch the most common cases.
• The writing-plans skill already notes that it "should be run in a dedicated worktree (created by brainstorming skill)" — but the brainstorming skill doesn't actually create one. Closing this gap would be a good starting point.