config: Reduce workflow instruction duplication

.agents/skills/sce-change-to-plan/SKILL.md

@@ -6,13 +6,17 @@ description: >
 
 # SCE Change to Plan
 
-## Purpose
-
-Own this workflow from input parsing through its terminal user-visible response.
-Execute the phases below directly and in order. Phase statuses are internal state,
-not inter-SCE workflow handoffs. Do not invoke another SCE skill, sibling SCE
-package, or SCE workflow command. Follow the canonical workflow's steps, gates,
-and stops exactly as written: never invent, skip, reorder, or merge a step.
+## Execution contract
+
+Own this workflow from input through its terminal user-visible response.
+Follow its steps, gates, and stops in order; do not add, skip, reorder, or merge them.
+Keep internal phase results private and continue immediately until a defined wait or stop.
+Resume user waits in this same skill and session.
+Render user-visible output only from the named workflow layouts or phase reports.
+Do not expose raw internal state or add text around a rendered layout or report.
+Non-SCE helpers may assist, but must return to the active step without changing
+phase order, gates, waits, writes, validation, stops, or terminal output.
+Do not invoke another SCE skill, package, or workflow command.
 
 ## Phase references
 
@@ -33,26 +37,6 @@ Read a step's reference before taking any action for that step, not after. Read
 only the reference for the step you have reached: a run that stops at the
 bootstrap gate never authors a plan, which is why they are separate files.
 
-## User-visible output
-
-Use `references/output.md` for every gate and terminal response. Render no raw
-internal state. The reference contains only human-visible Markdown layouts.
-User-visible output is limited to those layouts: never invent a layout, and never
-wrap one in an added preamble, commentary, summary, or extra section.
-
-## Composite control flow
-
-Keep phase results as internal state and continue immediately whenever the
-canonical workflow says to continue. Stop only at a user wait or terminal branch.
-Any workflow-defined user wait resumes this same skill in the same session.
-Never expose an internal phase result
-as the workflow's final response.
-
-Relevant non-SCE skills may be used as helper capabilities during the active step.
-They are not workflow handoffs: when a helper returns, control returns to the active
-step. Helper use must preserve the canonical phase order, gates, waits, writes,
-validation, stops, and terminal user-visible output.
-
 ## Input
 
 `invocation input` is the change request, in free-form prose.

.agents/skills/sce-change-to-plan/references/context-load.md

@@ -61,15 +61,15 @@ sentence.
 
 ## 1.5 Return the brief
 
-Set exactly one internal state:
+Return one internal result with one of these statuses:
 
 - `loaded`
 - `bootstrap_required`
 
 Report facts the workflow can act on. A brief that only lists file paths has
 moved no knowledge.
 
-Record only the internal state. Do not add explanatory prose before or after it.
+Return only the internal result. Do not add explanatory prose before or after it.
 
 Step 2 consumes a `loaded` brief verbatim and treats its `key_facts` as recorded
 current state, its `gaps` as areas with no durable context, and its `drift` as

.agents/skills/sce-change-to-plan/references/output.md

@@ -48,7 +48,7 @@ candidate plan paths and explain that naming one candidate resolves it.
 
 This plan is a draft. State a correction and it will be updated.
 
-Next up:
+Next step:
 
 {next-task-id} — {next-task-title}
 
@@ -66,22 +66,22 @@ This is chat output, not a file. Nothing here is written to the plan.
 
 ## Layout
 
-```
+```markdown
 # Plan: {plan.name}
 
 Path: {plan.path}
 
-## Summary:
+## Summary
 {plan summary}
 
-## Tasks:
+## Tasks
 1. {task.id} — {task.title}
 2. {task.id} — {task.title}
 
-## Assumptions:
+## Assumptions
 - {assumption}
 
-## Open questions:
+## Open questions
 - {open question}
 ```
 
@@ -93,13 +93,13 @@ not carry.
 - `Plan:` — `plan.name`. Append ` (updated)` when `plan.action` is `updated`.
   Render nothing extra when it is `created`.
 - `Path:` — `plan.path`, exactly as returned, so it stays runnable.
-- `Summary:` — `summary`, as prose. This is the only place the reader learns
+- `Summary` — `summary`, as prose. This is the only place the reader learns
   what the plan actually does, so never omit it and never replace it with a
   restatement of the task titles.
-- `Tasks:` — one numbered line per entry in `tasks`, in plan order. Append
+- `Tasks` — one numbered line per entry in `tasks`, in plan order. Append
   ` (done)` to any task whose `status` is `done`.
-- `Assumptions:` — one line per entry in `assumptions`.
-- `Open questions:` — one line per entry in `open_questions`.
+- `Assumptions` — one line per entry in `assumptions`.
+- `Open questions` — one line per entry in `open_questions`.
 
 ## Empty sections
 
@@ -108,15 +108,15 @@ explicit `None.` confirms nothing is pending.
 
 When `assumptions` is empty:
 
-```
-## Assumptions:
+```markdown
+## Assumptions
 - None.
 ```
 
 When `open_questions` is absent:
 
-```
-## Open questions:
+```markdown
+## Open questions
 - None.
 ```
 
@@ -132,21 +132,21 @@ When `open_questions` is absent:
 
 ## Example
 
-```
+```markdown
 # Plan: red-sce-banner
 
 Path: context/plans/red-sce-banner.md
 
-## Summary:
-Renders the ASCII-art SCE banner at the top of `sce` help in red instead of the current gradient. Colour-disabled output is unchanged, and no other help surface is affected.
+## Summary
+Renders the ASCII-art SCE banner at the top of `sce` help in red instead of the current gradient. Color-disabled output is unchanged, and no other help surface is affected.
 
-## Tasks:
+## Tasks
 1. T01 — Render the SCE banner in red
 
-## Assumptions:
+## Assumptions
 - "SCE letters" refers to the ASCII-art banner in top-level help.
 - Red is uniform terminal red when colors are enabled; plain ASCII remains unchanged otherwise.
 
-## Open questions:
+## Open questions
 - None.
 ```

.agents/skills/sce-change-to-plan/references/plan-authoring.md

@@ -5,18 +5,18 @@ Run this phase for step 2 of the workflow, and again for each revision in step 4
 Input: the change request, and the complete `loaded` brief from the context load
 phase. Pass the brief verbatim; do not restate, summarize, or reinterpret it.
 
-This phase exclusively owns:
+This phase owns the planning process:
 
-- Resolving whether the request targets a new or an existing plan.
-- The clarification gate.
-- Normalizing the change summary, acceptance criteria, constraints, and non-goals.
-- Slicing the task stack into one-task/one-atomic-commit units.
-- Writing `context/plans/{plan_name}.md`.
+- Resolve whether the request targets a new or an existing plan.
+- Challenge the change and run the clarification gate.
+- Derive plan-specific content from the request and loaded context.
+- Decide task boundaries, dependencies, and ordering.
+- Write or revise exactly one `context/plans/{plan_name}.md`.
 
-Do not duplicate any of it elsewhere in the workflow.
-
-Use the document format in `references/plan-template.md`. Read it before writing
-the plan file.
+`references/plan-template.md` is the sole owner of the persisted plan schema.
+Read its `Acceptance criteria rules`, `Task rules` and `No validation task` rules,
+and `Updating an existing plan` rules before authoring or revising. Apply those
+rules rather than restating them here.
 
 The workflow renders this phase's result as the summary defined in
 `references/output.md`.
@@ -27,7 +27,7 @@ responsibility.
 
 The context brief is the durable memory this plan starts from. Treat its
 `key_facts` as recorded current state, its `gaps` as areas with no durable
-context, and its `drift` as context the code has already outrun.
+context, and its `drift` as recorded context that no longer matches the code.
 
 When no brief is supplied, load the context named by the change request before
 authoring, and follow the selection discipline in *Inspect relevant context*.
@@ -48,8 +48,9 @@ undecidable.
 Determine whether the request targets a new plan or an existing plan in
 `context/plans/`.
 
-When it targets an existing plan, read that plan before authoring. Preserve its
-completed tasks, their recorded evidence, its structure, and its terminology.
+When it targets an existing plan, read that plan before authoring. Apply the
+`Updating an existing plan` rules in `references/plan-template.md` when writing;
+this step only resolves which plan is being revised.
 
 When multiple existing plans match and none can be selected safely, return
 `blocked` with the matching candidates.
@@ -151,33 +152,16 @@ Do not explore the entire repository by default.
 
 ## 2.5 Author the acceptance criteria
 
-State how the finished plan is proven, before slicing tasks.
-
-Each criterion describes observable behavior of the finished system and names the
-check that proves it. Record repository-wide checks once under `Full validation`,
-and the durable context the change must be reflected in under `Context sync`.
-
-`/validate` runs this section after the last task completes. It is the only place
-a plan says how it is validated.
+Derive the plan-specific success outcomes and checks before slicing tasks, then
+apply the `Acceptance criteria rules` and exact section shape in
+`references/plan-template.md`. The template owns their generic validation
+semantics and placement.
 
 ## 2.6 Author the task stack
 
-Slice the work into sequential tasks `T01..T0N` using the task format and the
-atomic slicing contract in `references/plan-template.md`.
-
-Every executable task must be completable and landable as one coherent commit.
-Split any task that would require multiple independent commits. Convert broad
-wrappers such as `polish` or `finalize` into specific outcomes with concrete
-acceptance checks.
-
-Order tasks so each one's declared dependencies precede it.
-
-The last task is an ordinary implementation task. Do not author a trailing
-validation-and-cleanup task, or any task whose only purpose is running the full
-check suite, verifying durable context, or removing scaffolding.
-
-Confirm every acceptance criterion is satisfied by at least one task. When one is
-not, the task stack is incomplete.
+Slice and order the plan-specific work after the acceptance criteria, applying the
+`Task rules` and `No validation task` rules in `references/plan-template.md`.
+Do not restate those generic task rules here.
 
 A finished stack always leaves at least one incomplete task, so the workflow can
 always hand off to `/next-task`. When the request resolves to a plan but produces
@@ -187,50 +171,32 @@ by completed tasks, set internal status `blocked` with category
 
 ## 2.7 Write the plan
 
-Write `context/plans/{plan_name}.md` using `references/plan-template.md`.
-
-When updating an existing plan, keep completed tasks and their evidence intact,
-and append or renumber new tasks without disturbing recorded history.
+Write `context/plans/{plan_name}.md` by applying `references/plan-template.md`
+exactly. For revisions, apply its `Updating an existing plan` rules.
 
 ## 2.8 Return the result
 
-Set exactly one internal state:
+Return one internal result with one of these statuses:
 
 - `plan_ready`
 - `needs_clarification`
 - `blocked`
 
-Record only the internal state. Do not add explanatory prose before or after it.
+Return only the internal result. Do not add explanatory prose before or after it.
 
 A `plan_ready` result always names the next task in `next_task`, and carries the
 `total_tasks` count and any open questions the summary needs. Step 3 renders those
 without recomputing them.
 
 ## Plan authoring tone
 
-Every question and open question this phase writes is read by the user. Write
-them the way a senior engineer talks in review: direct, specific, and unbothered
-by the possibility of being unwelcome.
-
-- Ask about the thing that actually worries you, not a safer neighbouring thing.
-  A question you would not bother asking a colleague is not worth the user's
-  attention either.
-- State a doubt as a doubt. "I do not think this is worth the two tasks it
-  costs, because X" is useful. "It may be worth considering whether this aligns
-  with broader goals" is noise.
-- Name the alternative you have in mind. A challenge with no proposal behind it
-  is just friction.
-- Do not open with praise, do not close with reassurance, and do not apologize
-  for asking. Do not pad a doubt with hedges to make it land more gently.
-- Be persistent, not repetitive. Ask once, plainly, and let it stand; do not
-  restate the same doubt in three shapes to give it more weight.
-- Being disagreeable is not the goal. Being easy to agree with is the failure
-  mode. A plan the user waves through without reading has cost them nothing and
-  bought them nothing.
-
-When the user overrules a doubt, record it and move on. Do not relitigate a
-decision the user has made, and do not smuggle the objection back in as a
-constraint, a non-goal, or a task.
+Write user-facing questions and open questions directly and specifically.
+
+- Ask only about material concerns that can change scope, success criteria, or task ordering.
+- State the concern and the concrete evidence for it.
+- Name a smaller or safer alternative when one is known.
+- Do not invent concerns, add praise or reassurance, or repeat the same concern in several forms.
+- When the user overrules a concern, record the decision and continue. Do not reintroduce it as a constraint, non-goal, or task.
 
 ## Plan authoring boundaries
 
@@ -249,8 +215,7 @@ Do not:
 - Run task execution.
 - Synchronize context.
 - Run final validation.
-- Author a validation, cleanup, or context-verification task. `/validate` owns
-  that phase.
+- Write a plan that violates `references/plan-template.md`.
 - Set internal status `plan_ready` for a plan with no incomplete task.
 - Create a Git commit.
 - Author more than one plan.

.agents/skills/sce-change-to-plan/references/plan-template.md

@@ -129,6 +129,7 @@ invent one: `None.` is the expected answer for a well-specified change.}
 
 ## Task rules
 
+- Number tasks sequentially as `T01..T0N`.
 - Every task is a checkbox line so progress stays machine-readable:
   `- [ ] T01: {title} (status:todo)`.
 - Author each executable task as one atomic commit unit by default.
@@ -145,9 +146,9 @@ invent one: `None.` is the expected answer for a well-specified change.}
 
 - The last task in the stack is an ordinary implementation task. Do not author a
   trailing "validation and cleanup" task.
-- Final validation, cleanup, and success-criteria verification are run by
-  `/validate` from the `Acceptance criteria` section after the last task
-  completes.
+- Final validation and success-criteria verification are run by `/validate`
+  from the `Acceptance criteria` section after the last task completes. Validation
+  reports cleanup or repair work that is still required; it does not perform that work.
 - Do not author a task whose only purpose is running the full check suite,
   verifying durable context, or removing scaffolding.
 - A task may still create or update durable context when that context is part of