writing-plans: plans over-specify implementation, leaving no room for executor judgment

I searched existing issues and this has not been proposed before

What problem does this solve?

When using writing-plans to plan a multi-task implementation, the generated plan contained complete implementation code — full function bodies, 70-line test files, exact shell commands, and step-by-step TDD sequences per task. The executor (executing-plans / subagent-driven-development) had no decisions to make — it was copy-pasting code from the plan rather than engineering a solution.

This caused two concrete problems:

1. When implementation revealed a better approach mid-execution, the plan's code was wrong even though the intent was still valid. Adapting meant "violating" the plan.
2. Every task duplicated the TDD ceremony ("write failing test → verify failure → implement → verify pass → commit") that executing-plans and test-driven-development
   already enforce, bloating each task from ~20 lines to 80-100+.

Proposed solution

Shift writing-plans to produce interface contracts + acceptance criteria instead of implementation code. Each task would include:

And explicitly not include: function bodies, test code, shell commands, TDD step sequences, or commit messages.

Before (current): A task to create four StrEnum classes included 4 __init__.py files, a 70-line test file with full assertions, a complete implementation file, and TDD step instructions.

After (proposed): The same task:

Task 1: Benchmark domain enums

Why: All other domain models depend on these classification types.

Files: Create src/benchmark/domain/enums.py, test at tests/benchmark/domain/test_enums.py

Contract: Four StrEnum classes — UnitKind (8 members), QueryClass (7 members), EvidenceTier (3 members), ReviewStatus (4 members)

Acceptance: All are StrEnum subclasses; values are snake_case; EvidenceTier string ordering matches intended importance ranking

Constraints: No imports outside stdlib

The responsibility split becomes:

plan-document-reviewer-prompt.md would also need updates to validate against the new abstraction level.

What alternatives did you consider?

1. Keep current behavior but make it optional (e.g., a --detail-level flag). Rejected because the skill system doesn't have a clean mechanism for this, and the
   over-specification problem is structural — partial code in a plan is arguably worse than all-or-nothing.
2. Fix it locally in my own fork. I did this — revised the skill for my project and it works well. But the issue affects everyone using the skill, so upstreaming the
   change seems right.

Is this appropriate for core Superpowers?

Yes. This is about the abstraction boundary between planning and execution — it affects any project regardless of domain. The current behavior duplicates responsibility
that executing-plans and test-driven-development already own, which is a framework-level concern.

Context

• Model: Claude Opus 4.6
• Harness: Claude Code CLI
• Workflow: Used writing-plans to plan a benchmark pipeline (~10 tasks), then executed with executing-plans + subagent-driven-development. The over-specified plans
  caused friction during execution when implementation diverged from the plan's exact code.