feat(brainstorming,writing-plans): propose parallel execution tracks by default

[freakathlete]

Summary

Adds a "Parallel Execution Plan" section to the brainstorming skill and a "Track Structure" section to the writing-plans skill. Any spec covering 2+ logically independent stories now proactively proposes how to split the work across parallel sessions, instead of producing a sequential spec by default.

Motivation

The current brainstorming flow produces sequential specs. For users running multiple Claude sessions concurrently, sequential specs leave throughput on the table — parallel-track analysis tends to surface only after the user explicitly asks "can we parallelize this?". This change moves that analysis into the default spec output as offense (ship faster), not defense (avoid conflicts).

What's in the brainstorming change

• New checklist step "Add Parallel Execution Plan section" between Present design and Write design doc.
• Updated the design "Cover:" list to include the parallel plan.
• New "Parallel Execution Plan" section defining the four required components:
  1. Track decomposition — break stories into tracks that touch disjoint files / surfaces. Backend modules, new files, additive blueprints, separate DB tables → safe parallel; shared template edits, shared modules, schema migrations everyone depends on → serial.
  2. Dependency graph — which tracks block which? Independent tracks said so explicitly.
  3. Merge plan — what stitches the tracks at the end; or a handoff stub.
  4. Session count estimate — "3 parallel sessions + 1 merge ≈ 2× faster than sequential."
• Inline "Parallel-safety / handoff status" subsection pattern for PRD sections that span multiple tracks (e.g. backend ships now, UI deferred to a later session).
• Explicit skip condition for genuinely single-story specs.

What's in the writing-plans change

• New "Track Structure (parallel execution)" section between Scope Check and File Structure.
• Plans organize tasks into tracks mirroring the spec's parallel plan. Tasks within a track run sequentially in one session; different tracks dispatch to parallel sessions.
• Per-track headers tag dependencies ((independent) or (depends on Track X's <thing>)).
• Last task of each parallel-safe track ends with a handoff stub naming exactly what shipped, so a parallel session can pick it up cleanly.
• No cross-track file edits rule: if two tracks both modify the same file, they aren't actually parallel — collapse or move the shared edit into the merge track.

Validation

Ran a RED/GREEN test with two parallel subagents on an identical 2-story feature request (Flask audit-logging backend + admin dashboard UI):

• RED (no skill, free-form spec): subagent produced a sequential spec with zero parallel-execution section.
• GREEN (skill content provided): subagent produced a complete Parallel Execution Plan with all four required components, correctly identifying the backend + UI + tests as Tracks A/B/C with a merge session.

Skill content materially changes the spec output.

Test plan

• Brainstorming RED/GREEN validation via parallel subagents
• Writing-plans content cross-referenced (track structure → handoff stub example)
• Reviewer sanity check — does the "offense not defense" framing land?
• Reviewer sanity check — is the four-component contract the right grain?