chore(skills): express parallel implementation tracks in /planner output

🎯 Context

Work item: #25 — "improve /planner to detect parallel steps. Example: clients API and management API are steps that can be worked on in parallel."

The /planner skill today enforces strict numeric step ordering — "Step N depends only on step <N (already merged), never on a sibling." Plans that contain genuinely independent tracks end up hiding that parallelism behind sequential numbering, and the team can't see at a glance which step MRs could be picked up concurrently.

🧭 Approach

Replace the implicit "predecessor = step N-1" rule with an explicit per-step Depends on: field. Steps stay numbered (stable references for the Status table and MR titles); execution order follows the Depends on: DAG. Each multi-step plan gets a Mermaid graph TD block at the top of ## Implementation Steps — same dialect as docs/roadmap.md's cross-spec dependency graph.

When decomposition produces a fully-linear DAG, the planner asks the operator via AskUserQuestion whether parallel tracks were missed.

📦 Scope

• .claude/skills/planner/SKILL.md — DAG model in MR breakdown / Rules; new Dependency analysis subsection with a worked example; updated anti-patterns (sibling-coupled clarified, accidentally-linear added); review-pr args updated.
• docs/plans/TEMPLATE.md — Mermaid graph TD placeholder + Depends on: field on each step.
• docs/dev/agentic-development.md — one-line update to the linear-order echo.

📊 Benchmark results

Methodology: /skill-creator benchmark per docs/dev/conventions.md. Four eval cases × baseline (current main) vs this MR, scored with assertion-based grading.

Metric	Baseline (main)	This MR	Delta
Pass rate	33% (5 / 17 assertions)	100% (17 / 17)	+67 pp
Mean run time	83.6s	75.4s	-8.2s
Mean tokens	30,874	33,464	+2,591 (+8%)

Per-eval breakdown

Eval	Scenario	Baseline	This MR
0. fanout-parallel-tracks	Maven clients API + management API on a shared types module — independent endpoints	1 / 5	5 / 5
1. linearity-check-fires	Migration → model → handler — genuinely linear chain	1 / 5	5 / 5
2. diamond-join	Maven HEAD + npm HEAD endpoints + shared normalizer middleware — parallel siblings	1 / 4	4 / 4
3. single-step	validateToken nil-check bugfix — single-MR plan	2 / 3	3 / 3

Key qualitative findings

• Eval 0 (fanout): the baseline planner recognized the structural independence in its run-notes ("Steps 2 and 3 are structurally independent of each other but ordered to satisfy the no-sibling-dependencies rule") but had no expressive outlet for it. This MR's Depends on: field captures it directly.
• Eval 1 (linearity): the new linearity-check AskUserQuestion fired correctly, recorded the three options it would have offered, and selected "Genuinely sequential" — confirming the guardrail behaves as designed.
• Eval 2 (diamond): the baseline emitted a 4-step plan with an artificial integration-tests join step (because parallelism had no expressive outlet); this MR emitted a clean 3-step fan-out and correctly skipped the linearity check per the new "skip if siblings exist" rule.
• Eval 3 (single-step): Mermaid block is suppressed for one-step plans as the new rules require; the Depends on: — field marks the single step as the DAG root.

No baseline behaviour is regressed — every assertion the baseline passes, this MR also passes.

🧪 Verification

• Token cost rises (+8%) but wall-clock time drops (-8.2s): the more prescriptive SKILL.md (291 → 370 lines) reduces the agent's strategy-exploration cost — more input context, less output deliberation.
• The existing single-step plan docs/plans/2026-04-08-bootstrap-db-tooling.md stays template-valid under the updated TEMPLATE.md (single-step plans skip the Mermaid block).
• Benchmark workspace and eval fixtures live locally (not committed); the tables above are the canonical reproducibility artifact for this MR.