AgentSkillsCN

plan-self-review

在向用户展示最终成果之前，提供一份轻量级的自我审查清单，用于评估方案质量。 无需调用任何智能体——协调者可直接运行此清单。 适用场景： - 当您完成/指定方案后，准备呈现最终成果时； - 当您需要在启动评审智能体之前，验证方案与设计的一致性时； - 当您需要在移交/指定方案评审之前，快速通过质量关卡时。 不适用于：完整的并行智能体评审（若需并行评审，请使用/指定方案评审——auto模式）。

SKILL.md
--- frontmatter
name: plan-self-review
description: |
  Lightweight self-review checklist for plan quality before presenting to user.
  No agent invocations — the orchestrator runs this checklist directly.

  Use when:
  - Completing /spec-plan before presenting final output
  - Validating spec↔design consistency without launching review agents
  - Quick quality gate before handing off to /spec-review

  Not for: Full parallel agent review (use /spec-review --auto for that)
allowed-tools: Read, Glob, Grep
model: sonnet
user-invocable: false

Plan Self-Review Checklist

A lightweight quality gate that the orchestrator runs at the end of /spec-plan BEFORE presenting the final plan to the user. No agents are launched — this preserves context budget.

When to Load

Load this skill at the end of /spec-plan Phase 4, after spec and design files have been saved.

Prerequisites

File size check before running this checklist:

This self-review is appropriate ONLY if BOTH conditions are met:

  1. •Specification file ≤200 lines
  2. •Design file ≤200 lines

If either file exceeds 200 lines: → Skip this checklist and proceed directly to /spec-review with --auto flag → The parallel review agents are better suited for larger documents

This respects the Quick Lookup limits defined in subagent-contract skill.

Checklist

The orchestrator reads both output files and checks each item. Mark each as PASS or FLAG.

Specification Checklist

#CheckHow to Verify
S1Acceptance criteria are measurableEach criterion has a concrete condition, not "should work well"
S2Edge cases are listedAt least 3 edge cases or error scenarios defined
S3Out-of-scope is definedSection exists and lists at least 1 exclusion
S4No ambiguous languageSearch for "should", "might", "could", "possibly" — flag if in requirements (OK in rationale)
S5Security requirements existAuth, authz, validation, or "N/A with reason"
S6Non-functional requirements existPerformance, scalability, or "N/A with reason"

Design Checklist

#CheckHow to Verify
D1Implementation map has filesAt least 1 file listed with Create/Modify action
D2Build sequence existsAt least 2 ordered steps
D3Trade-offs documentedAt least 1 trade-off or rejected alternative
D4File references are plausibleReferenced files exist (Glob check) or are marked as "Create"

Consistency Checklist

#CheckHow to Verify
C1Spec requirements covered by designEach spec section maps to a design component
C2Design doesn't contradict specNo design choice violates a spec requirement
C3Build sequence covers all componentsEach component in Implementation Map appears in Build Sequence

Output Format

markdown
## Self-Review Results

Passed: [N]/13
Flagged: [N]

### Flagged Items
- [S4] Ambiguous language: "should" found in requirement 3.2
- [C1] Spec section "Error Handling" has no corresponding design component

### Assessment
[ALL CLEAR / MINOR FLAGS / NEEDS ATTENTION]

Actions Based on Results

ResultAction
ALL CLEAR (0 flags)Present plan to user as-is
MINOR FLAGS (1-2 flags)Present plan with flags noted: "Self-review found [N] items to note: ..."
NEEDS ATTENTION (3+ flags)Fix the flagged items before presenting. For spec issues, edit the spec. For design issues, edit the design. Then re-run checklist once.

Rules (L1)

  • •NEVER launch subagents for this checklist — use direct file reads only
  • •ALWAYS run this before presenting the final plan to the user
  • •NEVER auto-fix items silently — always report what was flagged

Defaults (L2)

  • •Fix NEEDS ATTENTION items before presenting (but inform user of changes)
  • •Include flagged items in the plan presentation so user is aware