fix(skills): name the diagnosis precondition in idd-plan's description (#276)

[kiki830621]

Refs #276 — Phase 1 of two. This PR does not close the issue.

The root cause

Three surfaces carry the idd-plan ↔ idd-diagnose ordering. Only one of them is readable at the moment an AI decides which skill to invoke:

Surface	States the ordering?	Read at decision time?
docs/workflows.md:49 — the P-plan-gated chain	yes	no — never auto-loaded
skills/idd-plan/SKILL.md:62 — the hard abort	yes	no — loads only after the skill is chosen
idd-plan frontmatter description	no	yes — the only input

So when a user's AI advised them to skip /idd-diagnose and run /idd-plan directly, that inference was correct on the information visible to it. The routing error was structural, not incidental.

The hard abort is unchanged — implementation stays authoritative (maintainer ruling, 2026-07-26). This PR fixes the machine-facing surface only.

Scope correction found while planning

The diagnosis predicted one file. Measuring all 17 skills against the house pattern (Use when: + 防止的失敗：) found five off it, so all five are corrected together per the shared-abstraction contract:

Skill	Was missing
idd-plan	precondition + remedy + failure mode ← root cause
idd-clarify	Use when + failure mode
idd-comment	Use when
idd-all-chain	failure mode
idd-report	failure mode

idd-plan and idd-clarify were also the only two skills carrying a bare single-line description instead of a description: | block — the format itself acted as an affordance for under-specification. Both now use the block form.

The new idd-plan wording gives the remedy, not just a warning ("run /idd-diagnose #N instead"), so the fix does not over-correct into teaching AIs to avoid the skill entirely.

Drift-guard

New suite scripts/tests/skill-description-contract/test.sh, auto-discovered by run-all-tests.sh:

• A1 frontmatter carries a non-empty description
• A2 it says Use when
• A3 it says 防止的失敗
• A4 skills on an explicit allowlist name the diagnosis precondition

Two limits are documented in the file's header rather than papered over:

1. It asserts presence, not quality — Use when: 需要時 would pass. Same self-declared stance as scripts/tests/docs-catalog-sync.
2. A4 is an allowlist, not a derivation. The obvious derivation ("any skill whose body tells the user to run /idd-diagnose first") was tried and rejected: it also matches skills/idd-close/SKILL.md, where the string sits in a meeting-deliverable fallback, not as a precondition of its own (close is gated on verify). A derived rule would force idd-close to advertise a precondition it does not have.

Test plan

• RED before the fix: 8 failing, exactly as predicted (idd-plan ×3, idd-clarify ×2, idd-comment ×1, idd-all-chain ×1, idd-report ×1)
• GREEN after: 56 pass / 0 fail (48 + 8 = 56 confirms no assertion drift)
• Anti-placebo: reverting only idd-plan/SKILL.md re-reds exactly 3, restoring returns 56/0
• Allowlist self-guard: a renamed or deleted allowlisted skill fails loudly instead of silently asserting nothing
• Full aggregator: 41 suites, 0 failed

Not in this PR

• Phase 2 — the wiki flowchart generated from docs/workflows.md, plus the README.md:52 pipeline diagram that depends on it. Bundling it would keep the mis-routing live while the generator gets designed; it also has three open decision points and writes to a second git repo.
• The idd-plan hard abort logic.
• The 12 already-compliant descriptions.
• Version bump / marketplace sync — those belong to the release flow.