feat(writing-plans): add hierarchical plan mode for complex plans

[Birdjyy]

When estimated task count reaches 8+, writing-plans now switches to a
folder-based layout: one README index + one file per task. This prevents
two failure modes — oversized Write call payloads and context exhaustion
mid-generation — while making large plans easier to navigate and execute.

This PR MUST target the dev branch, not main. main is the
released branch; active work lands on dev first. PRs opened against
main will be asked to retarget dev before review.

Who is submitting this PR? (required)

Field	Value
Your model + version	claude-sonnet-4-6
Harness + version	Claude Code CLI 2.1.152
All plugins installed	superpowers 5.1.0
Human partner who reviewed this diff	jinyaoyu

What problem are you trying to solve?

When writing large implementation plans (8+ tasks), a single-file plan
causes two concrete failure modes in practice:

1. The Write tool call fails with a parameter error because the
   content payload exceeds the tool's size limit.
2. The agent exhausts its context window mid-generation and produces a
   truncated or incomplete plan file.

Both failures are silent — the agent believes the plan was written, but
the file is missing tasks. The user only discovers the problem when
execution begins.

What does this PR change?

Adds a "Hierarchical Plan Mode" section to skills/writing-plans/SKILL.md.
When 8 or more tasks are identified, the skill instructs the agent to write
one README index file plus one file per task, instead of a single large
file. Includes trigger condition, folder layout spec, README contents rule,
per-task file format, write order, Write failure fallback, and execution
handoff wording.

Is this change appropriate for the core library?

Yes. The failure modes (Write payload limits, context exhaustion mid-write)
are tool constraints that affect all users on all projects. The threshold
(8 tasks) and folder layout are project-agnostic. Any agent using
writing-plans on a sufficiently complex feature will hit this problem.

What alternatives did you consider?

• Increase step granularity to stay under 8 tasks: Not viable — many
  real features genuinely require more than 8 independent deliverables.
  Artificial merging of tasks reduces reviewability and increases
  per-task risk.
• Chunk a single file using Write + Edit: Partially addresses the
  Write payload failure but does not solve context exhaustion, and
  produces a single large file that's hard to navigate during execution.
• Leave recovery to the Fallback section only: Addresses failure
  after the fact, but doesn't prevent the agent from attempting a
  doomed Write in the first place.

Does this PR contain multiple unrelated changes?

No. All changes are in a single section of a single file, addressing one
specific failure mode.

Existing PRs

• I have reviewed all open AND closed PRs for duplicates or prior art
• Related PRs: none found

Environment tested

Harness	Harness version	Model	Model version/ID
Claude Code CLI	2.1.152	Claude Sonnet	claude-sonnet-4-6

Evaluation

• Initial prompt: "帮我生成一份场景识别 RTOS SDK 迁移的计划，内部实现简单且必要的 SQL 和几何计算方法，通过 cmake 构建，SDK 流程骨架参考 mecp2 中原 Android 的项目，依赖的加解密、鉴权等参考 mapsdk-rtos 已有模块，SDK 对外暴露接口参考 PlaceSemantic.java，同 mapsdk-rtos 项目一样，编译在 docker 中进行，编译链工具为 gcc-arm-none-eabi-10.3-2021.10，支持 C++14 及以下特性。" — This prompt, combined with prior discussion about porting constraints, SQLite alternatives, and reusable modules from mapsdk-rtos, produced a plan with more than 8 distinct tasks. The agent's Write call failed with a payload error and the resulting plan file was incomplete. That failure motivated adding explicit hierarchical mode guidance to the skill.
• Eval sessions after change: 3 scenarios × 2 phases (RED baseline + GREEN with skill) = 6 runs
• Before/after difference:
  • RED baseline (no skill): agent chose correctly on all 3 scenarios without the skill, confirming the rules are intuitive
  • GREEN with skill under pressure:
    • Sunk cost scenario (realized mid-write at task 5 of 10 that hierarchical mode was needed): agent stopped and restarted, citing both failure modes from the skill
    • Boundary scenario (7 tasks, user requests folder layout): agent followed user preference, correctly identifying the threshold as a trigger condition not a prohibition
    • Authority override (user explicitly requests single file, 9 tasks): agent followed user instruction with a single upfront risk disclosure — acceptable, since hierarchical mode is a mitigation strategy, not a safety constraint
  • No compliance failures

Rigor

• If this is a skills change: I used superpowers:writing-skills and
  completed adversarial pressure testing (paste results below)
• This change was tested adversarially, not just on the happy path
• I did not modify carefully-tuned content (Red Flags table,
  rationalizations, "human partner" language) without extensive evals
  showing the change is an improvement

Pressure test results:

Scenario 1 — Boundary ambiguity (7 tasks, user requests folder):
Agent chose to follow user preference (Option B), correctly identifying
the 8-task threshold as a minimum trigger condition, not a prohibition on
using hierarchical mode below that count. Cited: "the skill says 'if you
can identify 8 or more distinct tasks' — this is the trigger condition,
not a prohibition."

Scenario 2 — Sunk cost + time pressure (halfway through 10-task single file):
Agent chose to stop and restart in hierarchical mode (Option A). Cited
both Write payload failure and context exhaustion risks from the skill.
Correctly identified sunk cost as irrelevant: "completing a plan that will
likely fail on Write wastes more of the user's time, not less."

Scenario 3 — Authority pressure (user explicitly requests single file, 9 tasks):
Agent followed user instruction with a single upfront risk disclosure.
Judged acceptable: hierarchical mode is a mitigation strategy, not a
mandatory safety guardrail. User was informed and chose to proceed.

Human review

• A human has reviewed the COMPLETE proposed diff before submission

[Birdjyy]

related #1947