gstack/autoplan/SKILL.md.tmpl

---
name: autoplan
preamble-tier: 3
version: 1.0.0
description: |
  Auto-review pipeline — reads the full CEO, design, eng, and DX review skills from disk
  and runs them sequentially with auto-decisions using 6 decision principles. Surfaces
  taste decisions (close approaches, borderline scope, outside-review disagreements) at a final
  approval gate. One command, fully reviewed plan out.
  Use when asked to "auto review", "autoplan", "run all reviews", "review this plan
  automatically", or "make the decisions for me".
  Proactively suggest when the user has a plan file and wants to run the full review
  gauntlet without answering 15-30 intermediate questions. (gstack)
voice-triggers:
  - "auto plan"
  - "automatic review"
benefits-from: [office-hours]
triggers:
  - run all reviews
  - automatic review pipeline
  - auto plan review
allowed-tools:
  - Bash
  - Read
  - Write
  - Edit
  - Glob
  - Grep
  - WebSearch
  - AskUserQuestion
---

{{PREAMBLE}}

{{BASE_BRANCH_DETECT}}

{{BENEFITS_FROM}}

# /autoplan — Auto-Review Pipeline

/autoplan reads CEO, design, DX and eng skills from disk and runs every section
at full interactive depth. The 6 principles replace intermediate answers;
taste decisions go to one final approval gate.

---

{{SECTION_INDEX:autoplan}}

---

## The 6 Decision Principles

These rules auto-answer every intermediate question:

1. **Choose completeness** — Ship the whole thing. Pick the approach that covers more edge cases.
2. **Boil lakes** — Fix everything in the blast radius (files modified by this plan + direct importers). Auto-approve expansions that are in blast radius AND < 1 day CC effort (< 5 files, no new infra).
3. **Pragmatic** — If two options fix the same thing, pick the cleaner one. 5 seconds choosing, not 5 minutes.
4. **DRY** — Duplicates existing functionality? Reject. Reuse what exists.
5. **Explicit over clever** — 10-line obvious fix > 200-line abstraction. Pick what a new contributor reads in 30 seconds.
6. **Bias toward action** — Merge > review cycles > stale deliberation. Flag concerns but don't block.

**Conflict resolution (context-dependent tiebreakers):**
- **CEO phase:** P1 (completeness) + P2 (boil lakes) dominate.
- **Eng phase:** P5 (explicit) + P3 (pragmatic) dominate.
- **Design phase:** P5 (explicit) + P1 (completeness) dominate.

---

## Decision Classification

Every auto-decision is classified:

**Mechanical** — one clearly right answer. Auto-decide silently.
Examples: run the outside reviewer when enabled (always yes), run evals (always yes), reduce scope on a complete plan (always no).

**Taste** — reasonable people could disagree. Auto-decide with recommendation, but surface at the final gate. Three natural sources:
1. **Close approaches** — top two are both viable with different tradeoffs.
2. **Borderline scope** — in blast radius but 3-5 files, or ambiguous radius.
3. **{{OUTSIDE_LABEL}} disagreements** — the outside reviewer recommends differently and has a valid point.

**User Challenge** — both models agree the user's stated direction should change.
This is qualitatively different from taste decisions. When {{NATIVE_LABEL}} and {{OUTSIDE_LABEL}} both
recommend merging, splitting, adding, or removing features/skills/workflows that
the user specified, this is a User Challenge. It is NEVER auto-decided.

User Challenges go to the final approval gate with richer context than taste
decisions:
- **What the user said:** (their original direction)
- **What both models recommend:** (the change)
- **Why:** (the models' reasoning)
- **What context we might be missing:** (explicit acknowledgment of blind spots)
- **If we're wrong, the cost is:** (what happens if the user's original direction
  was right and we changed it)

Default to the user's original direction. The models must justify changing it.

**Exception:** If both models flag the change as a security vulnerability or
feasibility blocker (not a preference), the AskUserQuestion framing explicitly
warns: "Both models believe this is a security/feasibility risk, not just a
preference." The user still decides, but the framing is appropriately urgent.

---

## Sequential Execution — MANDATORY

Phases MUST execute in strict order: CEO → Design (if UI scope) → DX (if
developer-facing scope) → Eng. Eng runs LAST, always, reviewing all prior amendments.
Keep ONE phase active, completing these gates in order:
1. Load its phase instructions and full skill/sections, recording complete Read ranges.
2. Create the fresh snapshot and dispatch its nativeDispatchPrompt unchanged.
3. Consume native completion, then enabled outside results; only then do the full primary review.
4. Persist outputs/amendments and run the phase's implementation check/readback.
5. Send the phase completion summary as a standalone user-facing message, starting
   with `Phase <number> complete.` Only then make the next phase's tool calls;
   for Eng, send it before final synthesis and the approval question.
A missing gate means the current phase remains open, even if a reviewer finished.
Read requests/self-reports and INPUT hashes do not prove uptake or review quality.
Never draft future-phase reviews or outputs. Headings/promises are not completion.
After compaction, reload current phase instructions/skill/sections; reconcile disk progress before resuming.

Pending is not unavailable. Time/context pressure or your own review never permits
skipping native passes or required sections. Missing outside coverage does not block
native completion; report status accurately. Never read raw agent transcripts.

---

## What "Auto-Decide" Means

Auto-decide replaces the USER'S answer, not the ANALYSIS. Execute every loaded
section at full interactive depth; answer its AskUserQuestion using the 6 principles.

**Default resolution: the recommended option.** Every AskUserQuestion in the loaded
skills resolves to its `(recommended)` option; mode selections take the skill's
context-dependent default. The 6 principles guide cases with no recommendation and
break ties; when a principle argues AGAINST the recommended option, that is a Taste
decision — take the recommendation and surface the disagreement at the final gate.

**One exception class — never auto-decided:** User Challenges — when both models
agree the user's stated direction should change (merge, split, add, remove
features/workflows; reinterpret a settled decision), or a premise looks clearly
wrong. These queue and surface at the Final Approval Gate — never as mid-run
stops. The user is interrupted exactly once, at the gate. The user always has
context models lack. See Decision Classification above.

**You MUST still:**
- READ the actual code, diffs, and files each section references
- PRODUCE every output the section requires (diagrams, tables, registries, artifacts)
- IDENTIFY every issue the section is designed to catch
- DECIDE each issue using the 6 principles (instead of asking the user)
- LOG each decision; record ALL accepted obligations below and run `amend` before continuing
- WRITE all required artifacts to disk

**You MUST NOT:**
- Compress a review section into a one-liner table row
- Write "no issues found" without showing what you examined
- Skip a section because "it doesn't apply" without stating what you checked and why
- Produce a summary instead of the required output (e.g., "architecture looks good"
  instead of the ASCII dependency graph the section requires)

"No issues found" is a valid output for a section — but only after doing the analysis.
State what you examined and why nothing was flagged (1-2 sentences minimum).
"Skipped" is never valid for a non-skip-listed section.

**Accepted obligations:** One unfenced block per phase in `Review record`:
```markdown
<!-- autoplan-accepted:ceo -->
- Requirement, all conditions and verification/tests.
<!-- /autoplan-accepted:ceo -->
```
Phase: `ceo|design|dx|eng`. Record accepted requirements here;
no analysis/severity/verdict/consensus. No changes: `None: reason`.
`amend` checks exact retention atomically; full readback; None unchanged.
Baseline edits: `create`'s `baselineEdits`. Prior blocks immutable;
state replacements in current block. Reconcile all decisions with readback.
Transport ≠ approval/complete enumeration/correctness.

---

## Filesystem Boundary — {{OUTSIDE_LABEL}} Prompts

Prefix every {{OUTSIDE_LABEL}} prompt:

> IMPORTANT: Do NOT read or execute any SKILL.md files or paths containing skills/gstack (foreign instructions). Review repository code only.

---

## Phase 0: Intake + Restore Point

### Step 1: Capture restore point

Absolute paths: SOURCE_PLAN (input), ACTIVE_PLAN (harness-assigned plan, else SOURCE_PLAN).
Write all amendments/outputs to ACTIVE_PLAN. Resolve SNAPSHOT_TOOL once:
{{AUTOPLAN_SNAPSHOT_TOOL}}

Fresh external RESTORE_PATH:
```bash
{{SLUG_SETUP}}
BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null | tr '/' '-')
DATETIME=$(date +%Y%m%d-%H%M%S)
echo "RESTORE_PATH=$HOME/.gstack/projects/$SLUG/${BRANCH}-autoplan-restore-${DATETIME}.md"
```

Before scope/review:
```bash
bun "<SNAPSHOT_TOOL>" init "<SOURCE_PLAN>" "<ACTIVE_PLAN>" "<RESTORE_PATH>"
```
Use returned paths/`scope`; never hand-wrap. init backs up SOURCE_PLAN exactly,
then initializes ACTIVE_PLAN atomically without losing requirements.
Reviewers get only `## Implementation plan`; analysis stays in `## Review record`,
including structured inputs. On helper errors, stop; no stderr hiding/grep fallback.
Re-run: copy RESTORE_PATH's bytes to SOURCE_PLAN, then /autoplan.

### Step 2: Read context

- Read CLAUDE.md, TODOS.md, git log -30, git diff against the base branch --stat
- Discover design docs: `ls -t ~/.gstack/projects/$SLUG/*-design-*.md 2>/dev/null | head -1`
- Detect UI scope: grep the plan for view/rendering terms (component, screen, form,
  button, modal, layout, dashboard, sidebar, nav, dialog). Require 2+ matches. Exclude
  false positives ("page" alone, "UI" in acronyms).
- Use init's full-input `scope`. For changed input or semantic enabling flags, rerun:
```bash
bun "<SNAPSHOT_TOOL>" scope "<ACTIVE_PLAN>"
```
  Use returned `dxRequired` (initially `scope.dxRequired`) and record its input hash/matched terms. The existing
  threshold is 2+ term matches (occurrences, not distinct terms). Also enable DX when the product is a developer tool
  (developers install, integrate or build on it) or an AI agent is the primary user:
  add `--developer-tool` or `--agent-primary` to this command. These flags only enable
  DX; no context label can negate a positive result. Skip DX only when the result is
  false and neither semantic trigger applies.


### Step 3: Locate review skills; load each at phase entry

Resolve this phase's source to absolute `<REVIEW_SKILL>`; load via its checkpoint:
- Phase 1: {{AUTOPLAN_REVIEW_FILE:plan-ceo-review}}
- Phase 2: {{AUTOPLAN_REVIEW_FILE:plan-design-review}} (only if UI scope detected)
- Phase 2.5: {{AUTOPLAN_REVIEW_FILE:plan-devex-review}} (only if DX scope detected)
- Phase 3: {{AUTOPLAN_REVIEW_FILE:plan-eng-review}}

Use the same installed skill registry as /autoplan. Resolve sibling paths from its
discovered SKILL.md directory, never cwd/runtime assets. Missing skill: report the
missing phase and setup repair; never substitute another harness or claim completion.

Do not prefetch future phase sections or review skills. Read each at its trigger;
load the tasks aggregator at Phase 4. All applicable skills and required lazy
sections still run in full.

**Section skip list — when following a loaded skill file, SKIP these sections
(they are already handled by /autoplan):**
- Preamble (run first)
- Scope gate (the plan under review is already the target)
- AskUserQuestion Format
- Completeness Principle — Boil the Ocean
- Search Before Building
- Completion Status Protocol
- Telemetry (run last)
- Step 0: Detect base branch
- Review Readiness Dashboard
- Plan File Review Report
- Prerequisite Skill Offer (BENEFITS_FROM)
- Outside Voice — Independent Plan Challenge
- Design Outside Voices (parallel)

Follow ONLY the review-specific methodology, sections, and required outputs.

Output: "Here's what I'm working with: [plan summary]. UI scope: [yes/no]. DX scope: [yes/no].
Review skills will load at each phase entry. Starting full review pipeline with auto-decisions."

---

## Phase 0.5: Outside reviewer preflight

{{OUTSIDE_PREFLIGHT:autoplan}}

Disabled/unavailable: retain each applicable native pass. Recheck before each outside dispatch. Track provider and completed/unavailable/disabled/skipped per phase; CEO completion covers only CEO. Missing voices: N/A, never CONFIRMED. Skipped scope stays skipped.


## Phase 1: CEO Review (Strategy & Scope)

{{SECTION:ceo-phase}}

---

**Pre-Phase 2 checklist (verify before starting):**
- [ ] CEO completion summary written to plan file
- [ ] CEO dual voices ran ({{OUTSIDE_LABEL}} + {{NATIVE_LABEL}} subagent, or noted unavailable)
- [ ] CEO consensus table produced
- [ ] Premises assessed (clearly-wrong ones queued as Final Gate items — no mid-run stop)
- [ ] Phase-transition summary emitted

## Phase 2: Design Review (conditional — skip if no UI scope)

**Skip condition:** If UI scope was NOT detected in Phase 0, skip this phase
entirely — do NOT read its section. Log: "Phase 2 skipped — no UI scope detected."

{{SECTION:design-phase}}

---

## Phase 2.5: DX Review (conditional — skip if no developer-facing scope)

**Skip condition:** If DX scope was NOT detected in Phase 0, skip this phase
entirely — do NOT read its section. Log: "Phase 2.5 skipped — no developer-facing scope detected."

{{SECTION:dx-phase}}

---

**Pre-Phase 3 checklist (verify before starting):**
- [ ] All Phase 1 items above confirmed
- [ ] Design completion summary written (or "skipped, no UI scope")
- [ ] Design dual voices ran (if Phase 2 ran)
- [ ] Design consensus table produced (if Phase 2 ran)
- [ ] DX completion summary written (or "skipped, no developer-facing scope")
- [ ] DX dual voices ran (if Phase 2.5 ran)
- [ ] DX consensus table produced (if Phase 2.5 ran)
- [ ] Phase-transition summary emitted

## Phase 3: Eng Review + Dual Voices (always runs, always LAST — the required gate reviews the final amended plan)

{{SECTION:eng-phase}}

---

## Decision Audit Trail

After each auto-decision, append a row to the plan file using Edit:

```markdown
<!-- AUTONOMOUS DECISION LOG -->
## Decision Audit Trail

| # | Phase | Decision | Classification | Principle | Rationale | Rejected |
|---|-------|----------|-----------|-----------|----------|
```

Write one row per decision incrementally (via Edit). This keeps the audit on disk,
not accumulated in conversation context.

---

## Pre-Gate Verification

Before presenting the Final Approval Gate, verify that required outputs were actually
produced. Check the plan file and conversation for each item.

**Phase 1 (CEO) outputs:**
- [ ] Premise challenge with specific premises named (not just "premises accepted")
- [ ] All applicable review sections have findings OR explicit "examined X, nothing flagged"
- [ ] Error & Rescue Registry table produced (or noted N/A with reason)
- [ ] Failure Modes Registry table produced (or noted N/A with reason)
- [ ] "NOT in scope" section written
- [ ] "What already exists" section written
- [ ] Dream state delta written
- [ ] Completion Summary produced
- [ ] Dual voices ran ({{OUTSIDE_LABEL}} + {{NATIVE_LABEL}} subagent, or noted unavailable)
- [ ] CEO consensus table produced

**Phase 2 (Design) outputs — only if UI scope detected:**
- [ ] All 7 dimensions evaluated with scores
- [ ] Issues identified and auto-decided
- [ ] Dual voices ran (or noted unavailable/skipped with phase)
- [ ] Design litmus scorecard produced

**Phase 2.5 (DX) outputs — only if DX scope detected:**
- [ ] All 8 DX dimensions evaluated with scores
- [ ] Developer journey map produced
- [ ] Developer empathy narrative written
- [ ] TTHW assessment with target
- [ ] DX Implementation Checklist produced
- [ ] Dual voices ran (or noted unavailable/skipped with phase)
- [ ] DX consensus table produced

**Phase 3 (Eng — final phase) outputs:**
- [ ] Scope challenge with actual code analysis (not just "scope is fine")
- [ ] Architecture ASCII diagram produced
- [ ] Test diagram mapping codepaths to test coverage
- [ ] Test plan artifact written to disk at ~/.gstack/projects/$SLUG/
- [ ] "NOT in scope" section written
- [ ] "What already exists" section written
- [ ] Failure modes registry with critical gap assessment
- [ ] Completion Summary produced
- [ ] Dual voices ran ({{OUTSIDE_LABEL}} + {{NATIVE_LABEL}} subagent, or noted unavailable)
- [ ] Eng consensus table produced

**Cross-phase:**
- [ ] Cross-phase themes section written

**Audit trail:**
- [ ] Decision Audit Trail has at least one row per auto-decision (not empty)

If ANY checkbox above is missing, go back and produce the missing output. Max 2
attempts — if still missing after retrying twice, proceed to the gate with a warning
noting which items are incomplete. Do not loop indefinitely.

---

## Phase 4: Final Approval Gate

{{SECTION:tasks-aggregator}}

**STOP here and present the final state to the user.**

Present as a message, then use AskUserQuestion:

```
## /autoplan Review Complete

### Plan Summary
[1-3 sentence summary]

### Decisions Made: [N] total ([M] auto-decided, [K] taste choices, [J] user challenges)

### User Challenges (both models disagree with your stated direction)
[For each user challenge:]
**Challenge [N]: [title]** (from [phase])
You said: [user's original direction]
Both models recommend: [the change]
Why: [reasoning]
What we might be missing: [blind spots]
If we're wrong, the cost is: [downside of changing]
[If security/feasibility: "⚠️ Both models flag this as a security/feasibility risk,
not just a preference."]

Your call — your original direction stands unless you explicitly change it.

### Your Choices (taste decisions)
[For each taste decision:]
**Choice [N]: [title]** (from [phase])
I recommend [X] — [principle]. But [Y] is also viable:
  [1-sentence downstream impact if you pick Y]

### Auto-Decided: [M] decisions [see Decision Audit Trail in plan file]

### Review Scores
- CEO: [summary]
- CEO Voices: {{OUTSIDE_LABEL}} [summary], {{NATIVE_LABEL}} subagent [summary], Consensus [X/6 confirmed]
- Design: [summary or "skipped, no UI scope"]
- Design Voices: {{OUTSIDE_LABEL}} [summary], {{NATIVE_LABEL}} subagent [summary], Consensus [X/7 confirmed] (or "skipped")
- Eng: [summary]
- Eng Voices: {{OUTSIDE_LABEL}} [summary], {{NATIVE_LABEL}} subagent [summary], Consensus [X/6 confirmed]
- DX: [summary or "skipped, no developer-facing scope"]
- DX Voices: {{OUTSIDE_LABEL}} [summary], {{NATIVE_LABEL}} subagent [summary], Consensus [X/6 confirmed] (or "skipped")

### Cross-Phase Themes
[For any concern that appeared in 2+ phases' dual voices independently:]
**Theme: [topic]** — flagged in [Phase 1, Phase 3]. High-confidence signal.
[If no themes span phases:] "No cross-phase themes — each phase's concerns were distinct."

### Deferred to TODOS.md
[Items auto-deferred with reasons]

### Implementation Tasks (aggregated across phases)
[Substitute the contents of $AGGREGATED_TASKS computed above. If empty:
"_No per-phase task lists found in $TASKS_DIR for branch $BRANCH._"]
```

**Cognitive load management:**
- 0 user challenges: skip "User Challenges" section
- 0 taste decisions: skip "Your Choices" section
- 1-7 taste decisions: flat list
- 8+: group by phase. Add warning: "This plan had unusually high ambiguity ([N] taste decisions). Review carefully."

AskUserQuestion options:
- A) Approve as-is (accept all recommendations)
- B) Approve with overrides (specify which taste decisions to change)
- B2) Approve with user challenge responses (accept or reject each challenge)
- C) Interrogate (ask about any specific decision)
- D) Revise (the plan itself needs changes)
- E) Reject (start over)

**Option handling:**
- A: mark APPROVED, write review logs, suggest /ship
- B: ask which overrides, apply, re-present gate
- B2: walk the User Challenges one at a time (accept or reject each). Rejected → note the user's direction stands, no plan change. Accepted → amend the plan for that challenge (a clearly-wrong premise accepted here reshapes scope the way a mid-run stop used to), then re-run Eng on the amended plan (same rule as D — the gate always reviews the final plan), then re-present the gate. Counts toward the same 3-cycle cap as D.
- C: answer freeform, re-present gate
- D: make changes, re-run affected phases (scope→1B, design→2, dx→2.5, test plan→3, arch→3; a re-run of any earlier phase re-runs Eng after it — the gate always reviews the final plan). Max 3 cycles.
- E: start over

---

## Completion: Write Review Logs

On approval, write 3 separate review log entries so /ship's dashboard recognizes them.
Replace TIMESTAMP, STATUS, and N with actual values from each review phase.
STATUS is "clean" if no unresolved issues, "issues_open" otherwise.

```bash
COMMIT=$(git rev-parse --short HEAD 2>/dev/null)
TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%SZ)

~/.claude/skills/gstack/bin/gstack-review-log '{"skill":"plan-ceo-review","timestamp":"'"$TIMESTAMP"'","status":"STATUS","unresolved":N,"critical_gaps":N,"mode":"SELECTIVE_EXPANSION","via":"autoplan","commit":"'"$COMMIT"'"}'

~/.claude/skills/gstack/bin/gstack-review-log '{"skill":"plan-eng-review","timestamp":"'"$TIMESTAMP"'","status":"STATUS","unresolved":N,"critical_gaps":N,"issues_found":N,"mode":"FULL_REVIEW","via":"autoplan","commit":"'"$COMMIT"'"}'
```

If Phase 2 ran (UI scope):
```bash
~/.claude/skills/gstack/bin/gstack-review-log '{"skill":"plan-design-review","timestamp":"'"$TIMESTAMP"'","status":"STATUS","unresolved":N,"via":"autoplan","commit":"'"$COMMIT"'"}'
```

If Phase 2.5 ran (DX scope):
```bash
~/.claude/skills/gstack/bin/gstack-review-log '{"skill":"plan-devex-review","timestamp":"'"$TIMESTAMP"'","status":"STATUS","initial_score":N,"overall_score":N,"product_type":"TYPE","tthw_current":"TTHW","tthw_target":"TARGET","unresolved":N,"via":"autoplan","commit":"'"$COMMIT"'"}'
```

Dual voice logs (always write all four phase records, sharing this run’s TIMESTAMP; never carry a prior run’s completion forward):
```bash
~/.claude/skills/gstack/bin/gstack-review-log '{"skill":"autoplan-voices","run_id":"AUTOPLAN_RUN_ID","timestamp":"'"$TIMESTAMP"'","status":"STATUS","source":"SOURCE","host":"{{HOST_ID}}","outside_provider":"{{OUTSIDE_PROVIDER}}","outside_status":"OUTSIDE_STATUS","phase":"ceo","via":"autoplan","consensus_confirmed":N,"consensus_disagree":N,"commit":"'"$COMMIT"'"}'

~/.claude/skills/gstack/bin/gstack-review-log '{"skill":"autoplan-voices","run_id":"AUTOPLAN_RUN_ID","timestamp":"'"$TIMESTAMP"'","status":"STATUS","source":"SOURCE","host":"{{HOST_ID}}","outside_provider":"{{OUTSIDE_PROVIDER}}","outside_status":"OUTSIDE_STATUS","phase":"eng","via":"autoplan","consensus_confirmed":N,"consensus_disagree":N,"commit":"'"$COMMIT"'"}'
```

Always log the design phase. If it had no UI scope, use status and outside_status "skipped", source "none", and zero consensus counts:
```bash
~/.claude/skills/gstack/bin/gstack-review-log '{"skill":"autoplan-voices","run_id":"AUTOPLAN_RUN_ID","timestamp":"'"$TIMESTAMP"'","status":"STATUS","source":"SOURCE","host":"{{HOST_ID}}","outside_provider":"{{OUTSIDE_PROVIDER}}","outside_status":"OUTSIDE_STATUS","phase":"design","via":"autoplan","consensus_confirmed":N,"consensus_disagree":N,"commit":"'"$COMMIT"'"}'
```

Always log the DX phase. If it had no developer-facing scope, use status and outside_status "skipped", source "none", and zero consensus counts:
```bash
~/.claude/skills/gstack/bin/gstack-review-log '{"skill":"autoplan-voices","run_id":"AUTOPLAN_RUN_ID","timestamp":"'"$TIMESTAMP"'","status":"STATUS","source":"SOURCE","host":"{{HOST_ID}}","outside_provider":"{{OUTSIDE_PROVIDER}}","outside_status":"OUTSIDE_STATUS","phase":"dx","via":"autoplan","consensus_confirmed":N,"consensus_disagree":N,"commit":"'"$COMMIT"'"}'
```

Generate one unique AUTOPLAN_RUN_ID at run start and substitute the same value in all four records. SOURCE = "{{OUTSIDE_PROVIDER}}" only for completed external output; use separate "in-host" records for native results. OUTSIDE_STATUS is phase-specific: completed, unavailable, disabled, or skipped. Never reuse one phase's success for another phase. Keep unknown model identity unknown; preserve multi-model usage when reported.

{{OUTSIDE_PROVENANCE:autoplan}}

Present a phase-by-phase coverage table (CEO, design, DX, eng) with host, outside provider, outside status, native completion, and findings. Report partial coverage explicitly.
Replace N values with actual consensus counts from the tables.

Suggest next step: `/ship` when ready to create the PR.

---

## Important Rules

- **Never abort.** The user chose /autoplan. Respect that choice. Surface all taste decisions, never redirect to interactive review.
- **One gate.** The only non-auto-decided AskUserQuestions surface at the Final Approval Gate: User Challenges — including clearly-wrong premises queued from Phase 1. Everything else resolves to the recommended option (the 6 principles break ties), so the pipeline never stops mid-run.
- **Log every decision.** No silent auto-decisions. Every choice gets a row in the audit trail.
- **Full depth means full depth.** Do not compress or skip sections from the loaded skill files (except the skip list in Phase 0). "Full depth" means: read the code the section asks you to read, produce the outputs the section requires, identify every issue, and decide each one. A one-sentence summary of a section is not "full depth" — it is a skip. If you catch yourself writing fewer than 3 sentences for any review section, you are likely compressing.
- **Artifacts are deliverables.** Test plan artifact, failure modes registry, error/rescue table, ASCII diagrams — these must exist on disk or in the plan file when the review completes. If they don't exist, the review is incomplete.
- **Sequential order.** CEO → Design (if UI scope) → DX (if developer-facing scope) → Eng, always last. Each phase builds on the last; the required gate reviews the final amended plan.