Autoplan

AutoPlan — Automated Full Review Pipeline

1. Purpose & Trigger Conditions

AutoPlan compresses the full planning review gauntlet into a single structured command. Instead of running CEO → Design → Engineering → DX reviews sequentially and answering 15–30 intermediate questions, AutoPlan auto-decides everything resolvable by principle and surfaces only taste decisions to the human.

Activate when the user says any of:

• "autoplan", "auto plan", "auto-plan"
• "run all reviews", "run the full review"
• "review this plan automatically"
• "make the decisions for me"
• "compress the planning workflow"
• "full review pipeline"
• "one-command review"

Proactively suggest AutoPlan when:

• A plan file (PLAN.md, plan.md, spec.md, SPEC.md) is detected in the repo root
• The user has just finished /spec or /office-hours and has a document ready to review
• The user asks "what next?" after writing a plan

---

2. Pre-Flight: Context Ingestion

Before running any sub-review, ingest all available context:

# Detect plan file
PLAN_FILE=$(ls PLAN.md plan.md SPEC.md spec.md PRD.md prd.md 2>/dev/null | head -1)
echo "PLAN_FILE: ${PLAN_FILE:-none}"

# Detect git context
BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
DIRTY=$(git status --porcelain 2>/dev/null | wc -l | tr -d ' ')
echo "BRANCH: $BRANCH | DIRTY_FILES: $DIRTY"

# Detect project type signals
HAS_UI=$(find . -name "*.tsx" -o -name "*.jsx" -o -name "*.vue" -o -name "*.svelte" 2>/dev/null | head -1)
HAS_API=$(find . -name "routes.ts" -o -name "routes.js" -o -name "router.py" -o -name "*.proto" 2>/dev/null | head -1)
HAS_CLI=$(grep -r "argparse\|click\|cobra\|clap\|commander" . --include="*.py" --include="*.go" --include="*.rs" --include="*.ts" -l 2>/dev/null | head -1)
HAS_ARCH=$(find . -name "*.arxml" -o -name "*.dbc" -o -name "*.ldf" -o -name "system_design*" 2>/dev/null | head -1)
HAS_EMBEDDED=$(find . -name "*.c" -o -name "*.cpp" -o -name "*.h" 2>/dev/null | head -1)

echo "HAS_UI: ${HAS_UI:-none}"
echo "HAS_API: ${HAS_API:-none}"
echo "HAS_CLI: ${HAS_CLI:-none}"
echo "HAS_ARCH: ${HAS_ARCH:-none}"
echo "HAS_EMBEDDED: ${HAS_EMBEDDED:-none}"

Read the plan file fully before proceeding. If no plan file is found, ask the user to paste the plan inline or point to a file path.

---

3. Review Type Detection

Use the following signals to determine which sub-reviews apply. At minimum, CEO review and Engineering review always run. Others are conditional.

| Review | Trigger Condition | |----------------|------------------------------------------------------------------------------------| | CEO Review | Always runs — scope, value, risk, prioritization | | Design Review | HAS_UI is non-empty, OR plan mentions "UI", "screen", "layout", "component", "design system", "visual" | | Eng Review | Always runs — architecture, data model, interfaces, scalability, safety/security | | DX Review | HAS_API or HAS_CLI is non-empty, OR plan mentions "API", "CLI", "SDK", "developer", "integration", "endpoint" | | Embedded/Auto | HAS_EMBEDDED or HAS_ARCH is non-empty, OR plan mentions "ECU", "AUTOSAR", "CAN", "LIN", "embedded", "RTOS", "ISO 26262", "21434" |

Print which reviews will run before starting:

🔍 AutoPlan will run: [CEO] [Eng] [Design?] [DX?] [Embedded?]
   Based on detected signals: HAS_UI= HAS_API= HAS_CLI=
   Plan file: 
   Starting pipeline...

---

4. The Six Auto-Decision Principles

AutoPlan makes autonomous decisions using these six principles. Reference them when recording auto-decisions in the output.

1. Scope Minimization — When two approaches differ in scope, prefer the smaller one unless the larger is justified by a stated user goal.
2. Reversibility Preference — Prefer decisions that are easy to reverse or rollback over irreversible architectural commitments.
3. Proven Over Novel — Prefer established patterns, libraries, and protocols over novel/experimental ones unless novelty is the explicit goal.
4. Explicit Over Implicit — Prefer explicit contracts (typed APIs, schemas, defined interfaces) over implicit or convention-based ones.
5. Safety First — Any decision touching safety-critical or security-sensitive surfaces automatically applies the most conservative option.
6. User Goal Alignment — When in doubt, re-read the stated user goal at the top of the plan and choose the option that most directly serves it.

Auto-decided items are tagged: [AUTO: Principle N] Items needing human taste judgment are tagged: [TASTE GATE]

---

5. Pipeline Execution Order

Execute sub-reviews in this exact sequence. Each review reads the plan, applies its lens, and emits findings into a shared accumulator.

5.1 Phase 1 — CEO Review

Lens: Strategic value, market timing, prioritization, risk/reward, resource fit.

Auto-decide:

• Whether to defer features marked "nice to have" with no stated deadline → [AUTO: Principle 1] defer them
• Whether to accept scope that contradicts the stated user goal → [AUTO: Principle 6] flag as out-of-scope
• Standard prioritization of P0 (launch blocker) vs P1 (fast follow) vs P2 (future) features

Surface as [TASTE GATE]:

• Trade-offs where business value is genuinely close (e.g., "build vs buy" with similar cost profiles)
• Strategic bets that depend on market timing the AI cannot evaluate
• Any scope item where the user's appetite for risk is the deciding factor

CEO Review Output Format:

### CEO Review
**Strategic Fit:** 
**Scope Decision:** 
**Risk Rating:** Low / Medium / High — 
**Auto-Decisions:**
  - [AUTO: P1] 
**Taste Gates:**
  - [TASTE GATE] 

---

5.2 Phase 2 — Design Review

Skip if: Design signals are absent (see Section 3).

Lens: UX coherence, visual hierarchy, accessibility, consistency with design system, component reuse.

Auto-decide:

• Standard accessibility requirements (WCAG 2.1 AA minimum) → [AUTO: Principle 5]
• Consistency with existing design system tokens if detectable in codebase
• Responsive breakpoints following industry norms (mobile-first unless plan states otherwise)
• Animation/motion: default to prefers-reduced-motion safe → [AUTO: Principle 5]

Surface as [TASTE GATE]:

• Aesthetic direction when two valid design approaches exist (e.g., minimal vs expressive)
• Brand-specific decisions (colors, typeface, illustration style) not derivable from codebase
• Information architecture choices that depend on user mental models the AI cannot validate
• Any component that could go either "custom build" or "use existing library" with meaningful trade-offs

Design Review Output Format:

### Design Review
**UX Verdict:** 
**Accessibility:** 
**Design System Fit:** 
**Auto-Decisions:**
  - [AUTO: P3] Use existing component library for  — no custom build needed
**Taste Gates:**
  - [TASTE GATE] 

---

5.3 Phase 3 — Engineering Review

Always runs.

Lens: Architecture, data model, API contracts, scalability, testability, functional safety, cybersecurity, coding standard compliance.

Auto-decide using the six principles:

• Database normalization level (default: 3NF unless plan requires denormalization for performance) → [AUTO: Principle 3]
• Error handling strategy (explicit typed errors over generic exceptions) → [AUTO: Principle 4]
• Auth mechanism (prefer established OAuth2/OIDC over custom schemes) → [AUTO: Principle 3]
• Encryption at rest and in transit (always on for any user data or safety-critical data) → [AUTO: Principle 5]
• Interface contracts (typed schemas, Protobuf/OpenAPI over untyped JSON blobs) → [AUTO: Principle 4]
• Test coverage floor: minimum 80% unit coverage for business logic → [AUTO: Principle 5]
• MISRA/CERT compliance when embedded C/C++ is present → [AUTO: Principle 5]
• ISO 26262 ASIL determination when safety-critical automotive context is detected → [AUTO: Principle 5]
• Prefer stateless services unless statefulness is explicitly required → [AUTO: Principle 1]
• Prefer idempotent APIs → [AUTO: Principle 2]

Surface as [TASTE GATE]:

• Architecture topology decisions where two valid patterns exist and the trade-off is genuine (e.g., monolith vs microservices at this scale)
• Data model decisions where normalization vs. performance is a real trade-off requiring business context
• Vendor/dependency lock-in trade-offs (e.g., AWS-native vs cloud-agnostic)
• Any decision where the "right" answer depends on team skill set or organizational capability

Automotive/Embedded-specific (when HAS_EMBEDDED or HAS_ARCH):

• Assign ASIL level from plan context (A/B/C/D); default to ASIL-B if unclear → [AUTO: Principle 5]
• Apply MISRA C:2012 rules to all generated C/C++ → [AUTO: Principle 5]
• Flag any heap allocation in safety-critical paths → [AUTO: Principle 5]
• Apply ISO/SAE 21434 threat analysis hooks if cybersecurity context detected → [AUTO: Principle 5]

Engineering Review Output Format:

### Engineering Review
**Architecture Verdict:** 
**Data Model:** 
**Security Posture:** 
**Safety (if applicable):** ASIL- / 
**Auto-Decisions:**
  - [AUTO: P4] Typed API contracts via OpenAPI spec — no untyped JSON
  - [AUTO: P5] TLS 1.3 enforced for all service communication
**Taste Gates:**
  - [TASTE GATE] 
**Open Issues (blocking):**
  - 

---

5.4 Phase 4 — DX Review

Skip if: No API, CLI, or SDK signals detected (see Section 3).

Lens: Developer experience, API ergonomics, CLI usability, SDK onboarding, documentation completeness, error message quality.

Auto-decide:

• REST naming conventions (noun-based resource paths, HTTP verbs correct) → [AUTO: Principle 4]
• Versioning strategy (URL versioning /v1/ as default unless plan specifies header versioning) → [AUTO: Principle 3]
• Error response shape (RFC 7807 Problem Details as default) → [AUTO: Principle 3]
• CLI help text and --help flag required for all commands → [AUTO: Principle 4]
• Exit codes follow POSIX convention → [AUTO: Principle 3]
• SDK typed clients preferred over raw HTTP examples in docs → [AUTO: Principle 4]

Surface as [TASTE GATE]:

• API style trade-offs (REST vs GraphQL vs gRPC) when the plan hasn't committed
• Pagination strategy (cursor vs offset) when both are valid for the data shape
• CLI command naming that depends on team conventions not visible in codebase

DX Review Output Format:

### DX Review
**API Ergonomics:** 
**CLI Usability:** 
**Documentation Gaps:** 
**Auto-Decisions:**
  - [AUTO: P3] RFC 7807 error envelope for all 4xx/5xx responses
**Taste Gates:**
  - [TASTE GATE] 

---

6. Conflict Resolution

When sub-reviews produce contradictory findings, resolve conflicts using this hierarchy:

1. Safety always wins. If Engineering flags a safety or security concern, it overrides Design or DX convenience.
2. CEO scope decisions constrain all other reviews. If CEO cuts a feature, Design and Eng reviews for that feature are voided.
3. Eng and DX conflicts: Prefer the more explicit/typed/reversible option per Principles 2 and 4.
4. Design and DX conflicts: Prefer the developer-facing contract (DX) over visual presentation when they contradict on data shape; prefer Design when the conflict is purely presentational.
5. Unresolvable conflicts become [TASTE GATE] items surfaced at the approval gate.

When a conflict is resolved automatically, log it:

⚠️  CONFLICT RESOLVED: Design preferred custom date picker; Eng flagged a11y risk.
    Resolution [AUTO: P5]: Use platform-native date input — accessibility takes priority.

---

7. Output Format — Consolidated Plan

After all sub-reviews complete, emit a single consolidated output in this structure:

═══════════════════════════════════════════════════════
  AUTOPLAN REVIEW — 
  Ran:   |  Date: 
═══════════════════════════════════════════════════════

## Executive Summary

## Scope (Final)
**In Scope:**
  - 
**Out of Scope (deferred):**
  -  [AUTO: P1 — deferred, no stated deadline]
**Blocked (needs resolution before start):**
  - 

## Auto-Decisions Log
All decisions made automatically by principle. No human input needed.

| # | Decision | Principle | Rationale |
|---|----------|-----------|-----------|
| 1 |  | P3 |  |
| 2 |  | P5 |  |
...

## ⚡ Taste Gates — Human Approval Required
These are the ONLY items requiring your judgment. Everything else has been decided.

### TASTE GATE 1: 
**Context:** 
**Option A:**  — *Recommended if *
**Option B:**  — *Recommended if *
**Impact if wrong:** 

### TASTE GATE 2: 
...

## Review Findings (Detail)

## Conflicts Resolved

## Definition of Done
See Section 10 below — pre-populated with items derived from this plan.

---

8. Fast Path vs Thorough Path

Fast Path (autoplan --fast or user says "quick review")

• CEO + Eng only, always
• Design and DX skipped even if signals are present
• Auto-decide all taste gates using the recommended option
• Output is a single short verdict block (no detailed sub-review sections)
• Use when: the user wants a sanity check before a quick experiment, not a production ship

Fast Path output:

⚡ AUTOPLAN FAST
Verdict: 
Key risks: 
Auto-decided taste gates: 
Next: 

Thorough Path (default)

• All applicable reviews run
• All taste gates surfaced
• Full consolidated output as per Section 7
• Use when: plan is headed toward production, team sign-off needed, or the plan is complex

---

9. Integration with Upstream Skills

From /spec or /office-hours

If the user just completed a /spec or /office-hours session, AutoPlan can ingest the output directly:

• Read SPEC.md or the last written plan file automatically
• Skip the "paste your plan" prompt
• Reference spec decisions already made to avoid re-litigating them in reviews

Handing off downstream

After AutoPlan completes:

• If taste gates are approved → suggest next action: "Ready to implement. Run /ship when code is done or start with ``."
• If taste gates are rejected/modified → update the consolidated plan inline with the user's choices and re-emit the Definition of Done
• If blockers exist → do not suggest implementation; surface the blockers as the only next step

---

10. Definition of Done Checklist

AutoPlan generates a pre-populated DoD from the plan and review findings. Template:

## Definition of Done — 
Generated by AutoPlan on 

### Scope
- [ ] All In-Scope items from the plan are implemented
- [ ] All Out-of-Scope items are documented as deferred (not built)

### Engineering
- [ ] All [AUTO] architectural decisions are implemented as specified
- [ ] Taste Gate decisions are reflected in the implementation
- [ ] Unit test coverage ≥ 80% on business logic
- [ ] Integration tests cover all critical user paths
- [ ] No MISRA/CERT violations (if embedded) — static analysis clean
- [ ] ASIL- requirements met and documented (if automotive)
- [ ] Security: TLS enforced, auth validated, secrets not hardcoded
- [ ] All API contracts match the OpenAPI/schema spec

### Design (if applicable)
- [ ] WCAG 2.1 AA passes (run axe or Lighthouse)
- [ ] Responsive layout validated at mobile / tablet / desktop breakpoints
- [ ] Reduced-motion mode verified
- [ ] Design system tokens used (no hardcoded colors/spacing)

### DX (if applicable)
- [ ] API versioning implemented (`/v1/` prefix or agreed scheme)
- [ ] Error responses follow RFC 7807 shape
- [ ] All CLI commands have `--help` text and correct exit codes
- [ ] SDK/client examples updated to reflect final API shape

### Taste Gate Resolutions
- [ ] Taste Gate 1:  — resolved as 
- [ ] Taste Gate 2:  — resolved as 

### Review & Sign-off
- [ ] AutoPlan consolidated output reviewed by team lead
- [ ] No blocking issues remain open
- [ ] Plan file updated with all Auto-Decisions and Taste Gate resolutions
- [ ] Change committed: `git add  && git

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [CODE-SAURABH](https://github.com/CODE-SAURABH)
- **Source:** [CODE-SAURABH/OpenSkills](https://github.com/CODE-SAURABH/OpenSkills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.