williamthorsen · williamthorsen · Jun 15, 2026 · Jun 14, 2026 · Jun 14, 2026 · Jun 15, 2026
diff --git a/packages/agents/content/skills/_data/artifact-conventions.md b/packages/agents/content/skills/_data/artifact-conventions.md
@@ -246,7 +246,7 @@ This artifact uses the [universal artifact frontmatter](#universal-artifact-fron
 | ---------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------- |
 | `provenance.iteration` | no       | Refinement iteration counter. Absent on first authoring; set to `2` on first refinement, incremented on subsequent refinements. |
 
-Plan-specific `provenance.skill` values include `design-and-plan`, `plan-orchestrable-steps`, `plan-mode`, and `unknown` (when the authoring skill cannot be determined). `refinedBy` is the skill that last processed the plan (typically `refine-plan`).
+Plan-specific `provenance.skill` values include `design-and-plan`, `plan`, `plan-mode`, `plan-orchestrable-steps`, and `unknown` (when the authoring skill cannot be determined). `refinedBy` is the skill that last processed the plan (typically `refine-plan`).
 
 ## Devlog frontmatter
 

diff --git a/packages/agents/content/skills/_partials/plan-template.md b/packages/agents/content/skills/_partials/plan-template.md
@@ -0,0 +1,68 @@
+**Detail threshold:** Include enough detail that a competent engineer, reading only the plan and ticket, would make the same architectural decisions you would. Omit details they'd arrive at independently.
+
+```markdown
+# Implementation plan: {Title}
+
+## Context
+
+{Brief context linking this plan to the ticket}
+
+## Approach
+
+{High-level strategy, 2-3 sentences}
+
+## Tasks
+
+### Task 1: {Name}
+
+**Files:**
+
+- Create: `path/to/new-file.ts`
+- Modify: `path/to/existing.ts`
+- Test: `path/to/test.ts`
+
+**What:** {What this task accomplishes and why}
+
+**Key decisions:**
+
+- {Design choice the coder needs to know}
+
+**Acceptance criteria:**
+
+- {How to know this task is done}
+
+### Task 2: {Name}
+
+...
+
+## Risks
+
+{Known risks, unknowns, or areas where the coder may need to adapt}
+
+## Verification
+
+{How to verify the whole plan is complete — quality gates, integration checks}
+```
+
+`## Dependencies` (external dependencies or blockers) is the one optional section: Insert it between `## Risks` and `## Verification` only when the plan has external blockers, and omit it otherwise.
+
+**Per-task test criterion:** When a task creates or modifies testable behavior, its acceptance criteria must include a test criterion (e.g., "New/modified behavior is covered by tests"). Omit it only when the change falls entirely within the carve-outs defined in the `testing-conventions` skill.
+
+**Per-task documentation criterion:** When a task adds, removes, or renames user-facing surface (CLI flags, commands, API endpoints, configuration keys, environment variables), its acceptance criteria must include updating documentation, help text, and usage examples — including removal of references to anything that no longer exists.
+
+#### What belongs in the plan
+
+- Task decomposition with ordering and dependencies
+- File-level decisions (create, modify, test)
+- Key decisions that embody design choices
+- Acceptance criteria per task
+- Risks and unknowns
+
+Code belongs in the plan only when it captures a decision that isn't obvious from prose — for example, an interface that constrains how components interact, or an algorithm whose shape isn't implied by the description.
+
+#### What does NOT belong in the plan
+
+- Commit messages
+- Shell commands (test runners, build commands)
+- TDD step-by-step ceremony
+- Implementation code for straightforward logic
diff --git a/packages/agents/content/skills/design-and-plan/SKILL.md b/packages/agents/content/skills/design-and-plan/SKILL.md
@@ -129,72 +129,9 @@ Do NOT start this phase until the ticket from Phase 4 has been explicitly approv
 
 Produce a plan that gives a competent coder everything they need — and enough context to adapt when the codebase doesn't match expectations.
 
-**Detail threshold:** Include enough detail that a competent engineer, reading only the plan and ticket, would make the same architectural decisions you would. Omit details they'd arrive at independently.
+> Phase 5 produces the same implementation plan as the standalone `plan` skill, drawn from one shared template. When a ticket is already good and only the plan is needed, run `plan` directly to skip the design phase.
 
-```markdown
-# Implementation plan: {Title}
-
-## Context
-
-{Brief context linking this plan to the ticket}
-
-## Approach
-
-{High-level strategy, 2-3 sentences}
-
-## Tasks
-
-### Task 1: {Name}
-
-**Files:**
-
-- Create: `path/to/new-file.ts`
-- Modify: `path/to/existing.ts`
-- Test: `path/to/test.ts`
-
-**What:** {What this task accomplishes and why}
-
-**Key decisions:**
-
-- {Design choice the coder needs to know}
-
-**Acceptance criteria:**
-
-- {How to know this task is done}
-
-Apply the same test criterion convention here: When a task creates or modifies testable behavior, include a test criterion in its acceptance criteria. This ensures the test requirement propagates from the ticket through to the plan's per-task level, where the coder and reviewers consume it.
-
-Apply the same documentation criterion convention here: When a task adds, removes, or renames user-facing surface (CLI flags, commands, API endpoints, configuration keys, environment variables), include a criterion for updating documentation, help text, and usage examples — including removal of references to anything that no longer exists.
-
-### Task 2: {Name}
-
-...
-
-## Risks
-
-{Known risks, unknowns, or areas where the coder may need to adapt}
-
-## Verification
-
-{How to verify the whole plan is complete — quality gates, integration checks}
-```
-
-#### What belongs in the plan
-
-- Task decomposition with ordering and dependencies
-- File-level decisions (create, modify, test)
-- Key decisions that embody design choices
-- Acceptance criteria per task
-- Risks and unknowns
-
-Code belongs in the plan only when it captures a decision that isn't obvious from prose — for example, an interface that constrains how components interact, or an algorithm whose shape isn't implied by the description.
-
-#### What does NOT belong in the plan
-
-- Commit messages
-- Shell commands (test runners, build commands)
-- TDD step-by-step ceremony
-- Implementation code for straightforward logic
+<!-- include: ../_partials/plan-template.md / -->
 
 Present the plan to the user. Revise until approved.
 

diff --git a/packages/agents/content/skills/orchestrate/SKILL.md b/packages/agents/content/skills/orchestrate/SKILL.md
@@ -160,7 +160,7 @@ Prefix the status line with a colored emoji for visual distinction:
 
    **a. Parse provenance header:** Check whether the plan content starts with YAML frontmatter (`---` delimiters) containing a `provenance` block. Extract `skill`, `refinedBy`, `timestamp`, `baseSha`, `isInteractive`, and `iteration` fields. If no provenance block exists, set `{planTrust}` to `"low"` and skip remaining evaluation.
 
-   **b. Evaluate source credibility:** The plan is credible if `provenance.skill` is one of: `design-and-plan`, `writing-plans`, `plan-orchestrable-steps`. If credible, proceed to sub-step c. If not credible but `provenance.refinedBy` is `refine-plan`, mark the plan as "refinement-elevated" and proceed to sub-step c (the trust tier will be capped at `"medium"` in sub-step d). If neither credible nor refinement-elevated, set `{planTrust}` to `"low"` and skip remaining evaluation.
+   **b. Evaluate source credibility:** The plan is credible if `provenance.skill` is one of: `design-and-plan`, `plan`, `plan-orchestrable-steps`, `writing-plans`. If credible, proceed to sub-step c. If not credible but `provenance.refinedBy` is `refine-plan`, mark the plan as "refinement-elevated" and proceed to sub-step c (the trust tier will be capped at `"medium"` in sub-step d). If neither credible nor refinement-elevated, set `{planTrust}` to `"low"` and skip remaining evaluation.
 
    **c. Evaluate codebase freshness:** Run `git rev-parse --short origin/main` to obtain `{current-main-sha}`. If the command fails, classify freshness as `"unknown"`.
 

diff --git a/packages/agents/content/skills/plan/SKILL.md b/packages/agents/content/skills/plan/SKILL.md
@@ -1,60 +1,37 @@
 ---
 name: plan
-description: Create a structured plan document for analysis or implementation
+description: Create an implementation plan from a ticket or task description
 user-invocable: true
 ---
 
 # Plan
 
-Create a structured plan document for analysis, design, or implementation work.
+Create an implementation plan from a ticket or task. `plan` is the standalone plan-phase entry point: Given a good ticket, it produces the same implementation plan that `design-and-plan` produces with its design phase skipped. For interactive design exploration and ticket refinement before planning, use `design-and-plan`, which runs this same plan phase after its design phase.
 
 ## Arguments
 
-- Task or problem description (required): What to plan for
+- Task source (required): Issue URL, shorthand reference (`#99`, `issue 99`), file path, or description of what to build
 - `--role=<role>` (optional): Agent role for run artifact naming (default: `agent`)
 
-## Output format
-
-The plan begins with YAML frontmatter conforming to the canonical schema; see the canonical example in [artifact-conventions.md](../_data/artifact-conventions.md#universal-artifact-frontmatter) and the [plan provenance](../_data/artifact-conventions.md#plan-provenance) extension; field-resolution steps live in the [Frontmatter resolution](#frontmatter-resolution) section below. `provenance.model` is omitted — plans authored via this skill are co-authored interactively, not solely AI-generated.
-
-The body following the frontmatter has this structure:
-
-```markdown
-# Plan: {Descriptive title}
-
-**Date**: {YYYY-MM-DD HH:MM UTC}
-**Scope**: {Brief scope statement}
-
-## Problem
-
-{What needs to be solved}
-
-## Approach
+## Resolve the task source
 
-{High-level strategy}
+Resolve the task source using the [ticket source resolution](../_data/ticket-source-resolution.md) table, then read the resolved ticket or description and plan against it. `plan` does not run the staleness check or interactive design Q&A; that ceremony belongs to `design-and-plan`. When the source is a free-form description rather than a ticket, plan directly from the description.
 
-## Steps
+When the resolved source is a local artifact, read its `provenance.skill`: `design-and-plan` means an interactive design phase ran; another skill means the ticket was authored without one. Remote issues and free-form descriptions carry no provenance.
 
-1. {Step description}
-2. {Step description}
-
-## Risks
-
-{Known risks or unknowns}
+## Output format
 
-## Dependencies
+The plan begins with YAML frontmatter conforming to the canonical schema; see the canonical example in [artifact-conventions.md](../_data/artifact-conventions.md#universal-artifact-frontmatter) and the [plan provenance](../_data/artifact-conventions.md#plan-provenance) extension; field-resolution steps live in the [Frontmatter resolution](#frontmatter-resolution) section below. `provenance.model` is omitted: The plan is produced in an interactive, user-invoked session (the user supplies and vets the source ticket and approves the next step).
 
-{External dependencies or blockers}
-```
+The body following the frontmatter uses the shared implementation-plan template, the same one `design-and-plan` Phase 5 inlines, so both skills emit an identical plan:
 
-Sections are optional — use only what's appropriate for the task.
+<!-- include: ../_partials/plan-template.md / -->
 
 ## Guidance
 
 - Focus on clarity and actionability
 - Include concrete steps, not vague goals
 - Call out risks and unknowns explicitly
-- Keep the plan concise — detail belongs in implementation, not planning
 - When comparing approaches, rank options per [design priorities](../_data/design-priorities.md)
 
 ## Saving
@@ -94,4 +71,12 @@ Example: `20260223-143000Z_migrate-auth-to-oauth2_plan.md`
 
 ## Completion
 
-Report the file path when done. That's all the user needs to know.
+Report the file path when done.
+
+```
+Plan saved: {plan_path}
+```
+
+<HARD-GATE>
+Read [next-steps-after-plan](../_data/next-steps-after-plan.md) and follow its options, output format, and recommendation rules exactly. Do not improvise the options. For recommendation context, supply the source's design provenance from the resolve step — `plan` adds no interactive design phase of its own. Include both `{plan_path}` and `{ticket_source}` in each skill-invoking option line; omit the ticket path when the source was a free-form description rather than a ticket.
+</HARD-GATE>