Staged Review Flow
Internal shared skill. Referencing workflows keep stage numbers, artifact destinations, and intentional divergences; this skill is the single source of truth for review and verification-report flow.
Prerequisite check: verify each declared dependency is available when this skill is loaded. If one is missing, stop and print npx skills add FuDesign2008/open-skills -g --skill '*' --yes; do not silently reduce the review.
Placeholder contracts
| Placeholder |
Meaning |
Referencing workflow supplies |
{next-stage} |
The stage entered after a passed review |
Number and name |
{artifact-sink} |
Where review records or the design summary are persisted |
Host-specific path or artifact |
{extra-dimensions} |
Additional host-only dimensions |
Required checks and their sink |
{batch-overcap-behavior} |
Action after the automatic three-round limit in batch contexts |
Host-specific behavior, or N/A |
Never hardcode a host workflow's stage numbers, OpenSpec paths, Jira state transitions, or batch policy.
Review contract
- Always load and run the complete
solution-review framework: all core dimensions and strategic dimensions at the depth determined by reversibility. For code-affecting solutions, the strategic dimensions that carry long-term cost (cost-vs-value, team cognitive fit) run at least at standard depth, regardless of reversibility classification.
- When the solution affects code — writing or modifying source files, including scripts and generated config code — also load and run
code-design-review Layer A/B/C according to its applicability rules.
- Apply
{extra-dimensions} after the shared reviews. These checks supplement, never replace, solution-review.
- Keep two axes separate in the report (labels MAY vary; meaning MUST NOT):
- Standards — design / quality / smell / security fitness (
solution-review strategic+core quality aspects and code-design-review when applicable).
- Spec — fit to the chosen solution, ticket, or OpenSpec delta / stated requirements.
Axes MAY run in parallel (e.g. separate subagents). MUST NOT merge both into one undifferentiated ranked list; a pass on one axis MUST NOT hide a fail on the other.
- Aggregate blocking criteria into a binary overall result:
- Pass: no blocking issues remain on either axis (and
{extra-dimensions}).
- Fail: at least one blocking issue remains on any axis.
- Write the review record and passed design summary to
{artifact-sink}.
Review loop and gates
- In automatic mode, on failure optimize the solution, record the optimization, and rerun the full review. The initial review plus at most two optimized re-reviews is a three-round limit.
- At the limit, pause for the user unless
{batch-overcap-behavior} specifies the host's batch handling.
- In manual mode, present the review report and wait for the user to approve, revise, or reselect the solution. Do not advance without an explicit user decision.
- A pass enters
{next-stage}. A fail remains in solution optimization or returns to solution selection as directed by the user.
Design summary
After a passed review, emit a structured design summary with goals, non-goals, decisions, risks and mitigations, and open questions. It is part of the review output, not a separate mandatory file, unless {artifact-sink} requires persistence.
Verification-report honesty
Every verification result must disclose its execution state:
- Executed: include the command or action and a concise output/result summary.
- Pending: name the precise manual action still required.
Do not report designed scenarios or inferred correctness as completed verification. Browser or other unavailable manual interactions remain pending with actionable instructions.
Compose with completion-evidence-discipline: an Executed / pass claim is valid only when backed by fresh evidence from the current turn per that skill's Iron Law. Load completion-evidence-discipline at verification time; do not paste its prose into hosts.
Integration guide
Referencing workflows must:
- Declare
staged-review-flow in frontmatter dependencies and perform their normal dependency gate (transitively requires completion-evidence-discipline).
- At the review stage, load this skill and map all placeholders using numbers and names where applicable.
- Keep only host orchestration: stage exit wording,
{extra-dimensions}, {artifact-sink}, and {batch-overcap-behavior}.
- Point their verification stage to this skill's honesty rule and
completion-evidence-discipline in at most one or two sentences.
Do not duplicate binary tables, blocking lists, three-round loop prose, design-summary templates, dual-axis definitions, or verification-honesty blocks in hosts.
1---2name: staged-review-flow3description: Shared review-stage flow for PDCA hosts: full decision review, code-design review for code-affecting solutions, Standards∥Spec dual-axis verdicts (no cross-axis merge rank), binary pass/fail, bounded auto optimization, design summary, and verification-report honesty composed with completion-evidence-discipline. Used by PDCA workflows. Triggers — 「阶段审查流程」「方案审查编排」「审查闭环」「验证报告诚实」「双轴审查」 / staged review flow, dual-axis review, verification honesty. Do NOT use as a standalone task workflow.4---56# Staged Review Flow78> Internal shared skill. Referencing workflows keep stage numbers, artifact destinations, and intentional divergences; this skill is the single source of truth for review and verification-report flow.9>10> **Prerequisite check:** verify each declared dependency is available when this skill is loaded. If one is missing, stop and print `npx skills add FuDesign2008/open-skills -g --skill '*' --yes`; do not silently reduce the review.1112## Placeholder contracts1314| Placeholder | Meaning | Referencing workflow supplies |15|---|---|---|16| `{next-stage}` | The stage entered after a passed review | Number and name |17| `{artifact-sink}` | Where review records or the design summary are persisted | Host-specific path or artifact |18| `{extra-dimensions}` | Additional host-only dimensions | Required checks and their sink |19| `{batch-overcap-behavior}` | Action after the automatic three-round limit in batch contexts | Host-specific behavior, or `N/A` |2021Never hardcode a host workflow's stage numbers, OpenSpec paths, Jira state transitions, or batch policy.2223## Review contract24251. Always load and run the complete `solution-review` framework: all core dimensions and strategic dimensions at the depth determined by reversibility. For code-affecting solutions, the strategic dimensions that carry long-term cost (cost-vs-value, team cognitive fit) run at least at standard depth, regardless of reversibility classification.262. When the solution affects code — writing or modifying source files, including scripts and generated config code — also load and run `code-design-review` Layer A/B/C according to its applicability rules.273. Apply `{extra-dimensions}` after the shared reviews. These checks supplement, never replace, `solution-review`.284. Keep **two axes** separate in the report (labels MAY vary; meaning MUST NOT):29 - **Standards** — design / quality / smell / security fitness (`solution-review` strategic+core quality aspects and `code-design-review` when applicable).30 - **Spec** — fit to the chosen solution, ticket, or OpenSpec delta / stated requirements.31 Axes MAY run in parallel (e.g. separate subagents). **MUST NOT** merge both into one undifferentiated ranked list; a pass on one axis MUST NOT hide a fail on the other.325. Aggregate blocking criteria into a binary overall result:33 - **Pass:** no blocking issues remain on **either** axis (and `{extra-dimensions}`).34 - **Fail:** at least one blocking issue remains on any axis.356. Write the review record and passed design summary to `{artifact-sink}`.3637## Review loop and gates3839- In automatic mode, on failure optimize the solution, record the optimization, and rerun the full review. The initial review plus at most two optimized re-reviews is a three-round limit.40- At the limit, pause for the user unless `{batch-overcap-behavior}` specifies the host's batch handling.41- In manual mode, present the review report and wait for the user to approve, revise, or reselect the solution. Do not advance without an explicit user decision.42- A pass enters `{next-stage}`. A fail remains in solution optimization or returns to solution selection as directed by the user.4344## Design summary4546After a passed review, emit a structured design summary with goals, non-goals, decisions, risks and mitigations, and open questions. It is part of the review output, not a separate mandatory file, unless `{artifact-sink}` requires persistence.4748## Verification-report honesty4950Every verification result must disclose its execution state:5152- **Executed:** include the command or action and a concise output/result summary.53- **Pending:** name the precise manual action still required.5455Do not report designed scenarios or inferred correctness as completed verification. Browser or other unavailable manual interactions remain pending with actionable instructions.5657**Compose with `completion-evidence-discipline`:** an **Executed** / pass claim is valid only when backed by fresh evidence from the **current turn** per that skill's Iron Law. Load `completion-evidence-discipline` at verification time; do not paste its prose into hosts.5859## Integration guide6061Referencing workflows must:62631. Declare `staged-review-flow` in frontmatter dependencies and perform their normal dependency gate (transitively requires `completion-evidence-discipline`).642. At the review stage, load this skill and map all placeholders using numbers and names where applicable.653. Keep only host orchestration: stage exit wording, `{extra-dimensions}`, `{artifact-sink}`, and `{batch-overcap-behavior}`.664. Point their verification stage to this skill's honesty rule **and** `completion-evidence-discipline` in at most one or two sentences.6768Do not duplicate binary tables, blocking lists, three-round loop prose, design-summary templates, dual-axis definitions, or verification-honesty blocks in hosts.
fudesign2008