Plan-skill divergence: `plan` and `design-and-plan` produce structurally different plans

[williamthorsen]

Problem

Two skills produce artifacts both called "plan," with structurally different shapes:

• plan (standalone): a loose, optional-section template (Problem / Approach / Steps / Risks / Dependencies). No surrounding workflow.
• design-and-plan, Phase 5: a prescriptive template (Context / Approach / Tasks with per-task Files / Key decisions / Acceptance criteria / Risks / Verification), generated inline.

The templates were authored independently and have drifted. A user cannot anticipate the shape of plan they will get without inspecting the skill source, and the same ticket yields different plans depending on the entry point rather than the work.

Context

The user relies on design-and-plan many times a day and does not trust plan to produce an equivalent artifact. The concrete need: when a ticket is already good, running plan <ticket> should produce the same implementation plan that design-and-plan produces with its design phase skipped. plan is the natural home for that "plan phase only" entry point.

Two findings shape the approach:

• plan is not a different-purpose skill. Nothing invokes it programmatically; its only special behavior is run-artifact saving via --role. It is already a general standalone plan-document author, so it can be refined in place (no rename, no broken calls).
• plan is second-class downstream. The orchestrator's credibility whitelist (orchestrate, trust evaluation) trusts plans only from design-and-plan, writing-plans, and plan-orchestrable-steps. A plan-authored plan is currently marked low-trust. Making plan a first-class plan-phase entry requires elevating it there.

A symmetric design skill (the design phase standalone) and a future recomposition of design-and-plan as design + plan are recognized as the clean end state but are deliberately deferred to a follow-up.

Proposed solution

Establish a single canonical implementation-plan template that both skills reference, and elevate plan to a first-class plan-phase author.

• One canonical template, inlined not duplicated. Extract the structured Phase 5 shape (Context / Approach / Tasks / Risks / Verification, with Dependencies optional) and its authoring guidance (detail threshold, what-belongs/what-doesn't, the test- and documentation-criterion conventions) into a shared partial that both skills inline at build time. Neither carries its own copy. This follows the established _partials include pattern (the same mechanism as the shared acceptance-criteria scaffold). The old loose Problem / Steps form is retired so the shape is singular and predictable.
• plan becomes the canonical plan-phase author. Its scope narrows from "analysis, design, or implementation" to producing an implementation plan from a ticket or task. It gains ticket-source resolution so plan <ticket> reads the ticket and plans against it, and it presents the standard next-steps block on completion, matching the other plan skills. It keeps its existing saving behavior and provenance.skill: plan.
• design-and-plan Phase 5 references the shared template instead of carrying its own copy, keeping its workflow ceremony (hard gates, dual-artifact save, provenance.skill: design-and-plan).
• First-class downstream. plan is added to the orchestrator's credible-source list, so a fresh plan-authored plan reaches the same high trust tier as design-and-plan, and to the documented valid provenance.skill values.
• Documented relationship. Both skills carry a short cross-reference making the relationship explicit: plan is the standalone plan phase; design-and-plan is interactive design plus the same plan phase; both emit the identical artifact.

Acceptance criteria

Must have

• A single canonical implementation-plan template exists as a shared partial; both plan and design-and-plan inline it rather than carrying their own copy.
• plan and design-and-plan produce implementation plans with the same structural shape; the old loose Problem / Steps form is removed.
• plan resolves a ticket source (URL, shorthand, file path, or description) so plan <ticket> produces a plan against that ticket.
• plan-authored plans are treated as a credible source by the orchestrator (fresh plans reach the high trust tier), and plan is listed among the valid provenance.skill values in the artifact conventions.
• Both skills document the relationship between them so users can choose between them with confidence.
• plan's description, arguments, and guidance are updated to reflect its plan-phase role, and references to the retired loose template are removed.
• Shared-template references resolve and existing repo checks (lint/build) pass.

Should have

• plan presents the standard next-steps-after-plan block on completion, matching design-and-plan, save-plan, and refine-plan.