refactor(skills): merge acceptance into plan with narrative structure

Acceptance criteria now live inside plan.md. The plan template leads
with Solution Overview, Why This Approach, and How It Will Work before
slices and acceptance. Removes standalone acceptance.md from scaffold.

Author: backnotprop

apps/skills/plannotator-setup-goal/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: plannotator-setup-goal
-description: Create reviewed Codex goal setup packages for long-running /goal work. Use when the user wants to turn an idea, plan, backlog, project mission, or vague objective into durable goal files under a project goals slug folder, with Plannotator review gates for brief, plan, acceptance, verification, blockers, and the final /goal prompt.
+description: Create reviewed Codex goal setup packages for long-running /goal work. Use when the user wants to turn an idea, backlog, project mission, or vague objective into durable goal files under a project goals slug folder, with Plannotator review gates for brief, narrative plan with acceptance criteria, verification, blockers, and the final /goal prompt.
 ---
 
 # Plannotator Setup Goal
@@ -23,7 +23,6 @@ Create a durable goal package in the current project at `goals/<slug>/` so Codex
 5. Draft and refine the critical documents in this order:
    - `brief.md`
    - `plan.md`
-   - `acceptance.md`
    - `verification.md`
    - `blockers.md`
    - `goal-prompt.md`
@@ -40,9 +39,7 @@ Create a durable goal package in the current project at `goals/<slug>/` so Codex
 
 `brief.md` must state the mission, context, constraints, non-goals, ask-before rules, and concise done condition.
 
-`plan.md` must split the work into concrete slices with sequencing, dependencies, risks, and phase boundaries. For large missions, prefer several sequential goals over one endless goal.
-
-`acceptance.md` must be an auditable checklist. Every important requirement needs observable evidence. Include commands, files, screenshots, PR state, or manual checks as applicable.
+`plan.md` is the central reviewed planning artifact. It must read like a clear solution narrative, not just a technical checklist. Include what is being built, why this approach is appropriate, how the solution will work, the main implementation slices, risks, phase boundaries, and acceptance criteria. Every important acceptance item needs observable evidence. For large missions, prefer several sequential goals over one endless goal.
 
 `verification.md` must list exact verification commands and manual checks. Include expected pass conditions and where evidence should be recorded.
 
@@ -68,7 +65,7 @@ Include:
 - outcome
 - relevant files
 - constraints and non-goals
-- acceptance evidence
+- plan acceptance criteria and evidence
 - verification commands
 - ask-before rules
 - instruction to use `goals/<slug>/` as the durable plan and append evidence to `progress.jsonl`
@@ -84,8 +81,8 @@ Avoid:
 
 Before finalizing, verify:
 - The goal has one clear finish line.
-- The plan can be executed in slices.
-- Acceptance can be audited from real artifacts.
+- The plan explains what, why, and how before listing work slices.
+- The plan acceptance criteria can be audited from real artifacts.
 - Verification commands are concrete.
 - Risky actions have ask-before rules.
 - The final `/goal` prompt tells Codex where the goal files live.

apps/skills/plannotator-setup-goal/scripts/scaffold_goal.py

@@ -55,6 +55,18 @@ def brief(title: str, objective: str) -> str:
 def plan(title: str) -> str:
     return f"""# Plan: {title}
 
+## Solution Overview
+
+TODO: Describe what is being built in plain language. Explain the shape of the solution before diving into tasks.
+
+## Why This Approach
+
+TODO: Explain why this direction is appropriate for the project, user goal, constraints, and risk level.
+
+## How It Will Work
+
+TODO: Describe the main moving parts, data flow, user flow, files, APIs, or systems involved. Keep this narrative enough that a reviewer can understand the intended solution.
+
 ## Slices
 
 | Slice | Purpose | Main files or systems | Done when | Risks |
@@ -73,13 +85,8 @@ def plan(title: str) -> str:
 ## Steering Notes
 
 - TODO: Capture taste calls, product preferences, or review checkpoints the user should steer during execution.
-"""
-
-
-def acceptance(title: str) -> str:
-    return f"""# Acceptance: {title}
 
-## Checklist
+## Acceptance Criteria
 
 - [ ] TODO: Requirement with concrete observable evidence.
 - [ ] TODO: Requirement with concrete observable evidence.
@@ -149,8 +156,7 @@ def goal_prompt(slug: str, title: str, objective: str) -> str:
 
 Use `goals/{slug}/` as the durable source of truth:
 - Read `brief.md` for the mission, context, constraints, non-goals, and ask-before rules.
-- Follow `plan.md` slice by slice.
-- Treat `acceptance.md` as the completion checklist.
+- Follow `plan.md` for the solution overview, implementation slices, risks, and acceptance criteria.
 - Run the checks in `verification.md` and record evidence.
 - Append concrete progress and proof to `progress.jsonl`.
 - Pause and ask the user for anything listed in `blockers.md` or any similarly risky unresolved decision.
@@ -192,7 +198,6 @@ def main() -> int:
     files = {
         "brief.md": brief(args.title, args.objective),
         "plan.md": plan(args.title),
-        "acceptance.md": acceptance(args.title),
         "verification.md": verification(args.title),
         "blockers.md": blockers(args.title),
         "goal-prompt.md": goal_prompt(slug, args.title, args.objective),