majiayu000 Review-Deep — Comprehensive Pre-Release Review
Convenience wrapper that runs every /review-* skill in a coordinated sequence. Typically used before a release, or any time you want a comprehensive audit across every review dimension the plugin provides.
Philosophy
Thin orchestrator, not a new process. This skill composes eight existing /review-* skills. It adds sequencing, skip detection, branch safety, and a consolidated final report — nothing else. Each sub-skill retains its normal behavior.
Interactive throughout. The user participates in every sub-skill's decision points. This is not fire-and-forget. If you want a less hands-on sweep, invoke the individual skills directly — each manages its own user interaction. Skills that offer tickets (e.g., /review-arch, /review-security, /bug-hunt as of v8.0.0) still present the proposal here; you decide at each prompt.
Detect-and-confirm skips. Some phases do not apply to every project (no web content → no a11y; no tests → no test review). The orchestrator detects these conditions, proposes a skip list, and asks the user to confirm before starting.
Workflow Overview
┌──────────────────────────────────────────────────────┐
│ REVIEW-DEEP WORKFLOW │
├──────────────────────────────────────────────────────┤
│ 0. Branch safety check │
│ 1. Skip detection + user confirmation │
│ 2. Execute enabled phases, in order: │
│ 1. /review-health │
│ 2. /review-arch │
│ 3. /review-security │
│ 4. /review-perf │
│ 5. /review-a11y │
│ 6. /review-test │
│ 7. /tidy-docs │
│ 8. /review-release │
│ 3. Consolidated final report │
└──────────────────────────────────────────────────────┘
Workflow Details
0. Branch Safety Check
Before starting, verify the current git branch.
If on main or master:
- Ask the user: "You're on
<branch>. This workflow may produce many commits across multiple phases. Create a new branch, or proceed on<branch>?" - If the user wants a new branch: create
review-deep/<date>(e.g.,review-deep/2026-04-22) and check it out. - If the user explicitly confirms proceeding on main/master: continue.
If on any other branch: Proceed without asking.
1. Skip Detection + User Confirmation
Only the following phases are candidates for auto-skipping. All other phases always run.
| Phase | Skip condition | Heuristic |
|---|---|---|
/review-security |
No meaningful executable source code (e.g., a Claude plugin of only markdown, a docs-only repo) | Scan for source files with runtime-relevant extensions (.go, .rs, .py, .rb, .js, .ts, .tsx, .jsx, .java, .c, .cpp, .sh, .php, etc.). If count is zero or trivially small, propose skip. |
/review-perf |
No meaningful executable source code | Same heuristic as security. |
/review-a11y |
No web content | Scan for .html, .htm, .jsx, .tsx, .vue, .svelte, .css, .scss, .less, .ejs, .hbs, .pug, .njk. If none, propose skip. |
/review-test |
No tests available | Scan for common test markers: tests/, test/, spec/, __tests__/, files matching *_test.go, test_*.py, *_test.py, *.test.ts, *.spec.ts, *_spec.rb. If none, propose skip. |
Exclude from scans: vendor/, node_modules/, dist/, build/, .git/, and similar generated/vendored directories.
Present the proposal to the user:
## Review-Deep — Phase Plan
Proposed to skip:
- /review-a11y — no web content detected
- /review-test — no tests detected
Will run:
- /review-health
- /review-arch
- /review-security
- /review-perf
- /tidy-docs
- /review-release
Confirm, or override (e.g., "also skip /review-perf", "force-run /review-test")?
Accept the user's confirmation or overrides. The user may force-run any skipped phase, or force-skip any phase (including ones not in the skip-candidate table). Record the final enabled phase list.
If no phases end up as skip candidates, still present the full plan so the user knows what is about to happen and can override before starting.
2. Execute Enabled Phases
For each enabled phase, in the fixed order listed above:
- Announce the phase:
## Phase N of M: /review-<name> - Invoke the sub-skill. Do not override its interactive behavior. The user interacts with the sub-skill directly — answering its scope questions, its boldness prompts, its selection menus, and so on. The orchestrator does not suppress, fast-path, or reinterpret any sub-skill prompt.
- When the sub-skill completes, capture its completion summary (each sub-skill already produces one). Store it for the final report.
- Briefly acknowledge completion and transition:
## Phase N complete. Moving on to /review-<next>.
Branch safety delegation. The orchestrator has already performed the branch safety check in step 0. If a sub-skill would otherwise ask the same question, inform it: "Branch safety has been handled by /review-deep." (This applies primarily to /refactor-deep-style checks; most /review-* skills do not check the branch.)
Mid-phase user abort. If the user aborts a sub-skill mid-flight, treat that phase as incomplete. Ask whether to continue to the next phase or end the workflow. Do not retry the aborted sub-skill automatically.
Sub-skill failure. If a sub-skill fails (error, unrecoverable state), record the failure and ask whether to continue to the next phase. Do not abort the whole workflow on a single phase failure.
3. Consolidated Final Report
Present a single report that aggregates the results of every enabled phase. The goal is synthesis across phases, not re-printing each sub-skill's summary verbatim.
## Review-Deep Complete
### Phases
| Phase | Status | Key Outcome |
|------------------|---------------|-------------------------------------------------|
| /review-health | Complete | Classified as OSS library; 2 Major findings |
| /review-arch | Complete | 5 blueprint recommendations; 3 tickets cut |
| /review-security | Complete | 1 high-severity finding; 4 advisory |
| /review-perf | Complete | No critical bottlenecks; 2 caching suggestions |
| /review-a11y | Skipped | No web content |
| /review-test | Complete | 5 coverage/quality tickets cut; coverage 72% |
| /tidy-docs | Complete | 7 docs updated |
| /review-release | Complete | Release verdict: GO, after 2 advisory items |
### Changes Made
[Summarize commits made during the workflow, using `git log`
from the branch-start point. Group by phase where possible.]
### Cross-Cutting Observations
[Synthesize across phases. Examples:
- Multiple phases flagged inconsistent error handling → project-level concern
- Arch review recommended a module split that doc review's stale-link findings also pointed at
- Security and perf both pointed at the same hot-path function
If no cross-cutting themes emerged, say so concisely.]
### Outstanding Recommendations
[Items that phases surfaced but did not implement, grouped by phase.
The user can address these later or in a follow-up run.]
### Release Readiness
[If /review-release ran, carry forward its final verdict (GO / NO-GO / GO with conditions)
and the specific conditions, if any. Otherwise, omit this section.]
Abort Conditions
Do NOT abort the workflow for:
- A single phase finding nothing to report
- A single sub-skill failing (record and move on after user confirmation)
- User aborting a single sub-skill (ask about continuing)
- A skipped phase turning out to be warranted (report it, move on)
Abort the workflow for:
- Andon cord triggers: unrecoverable git state, critical system error
- User explicitly ends the workflow
Andon Cord Protocol
Before pulling the andon cord:
- Attempt autonomous resolution first (e.g., ask the sub-skill to recover, re-invoke with narrower scope)
- Only escalate if autonomous resolution has failed or is clearly futile
When pulled:
- Stop all work immediately
- Present current phase, what was attempted, what went wrong, any recovery tried, and a recommended path forward
- Wait for user guidance
Integration with Other Skills
This skill is a composition of:
/review-health— first-pass strategic orientation on the repo/review-arch— architectural analysis (advisory; offers ticket cutting)/review-security— white-box security audit/review-perf— performance review (compute and/or web)/review-a11y— WCAG accessibility audit/review-test— coverage, fuzz, and quality test review/tidy-docs— documentation audit and updates/review-release— pre-release readiness check
When to use /review-deep vs. individual skills:
- Use
/review-deepbefore a release, or for a comprehensive periodic audit. - Use an individual
/review-*skill for targeted single-dimension review, or when a previous/review-deepsurfaced a specific area to re-examine.
Relationship to /refactor-deep:
/refactor-deepcomposes:/refactor(tactical cleanup),/review-arch(advisory architectural analysis, with optional ticket creation),/tidy-docs. It is change-oriented./review-deepcomposes review skills and is evaluation-oriented. It shares/review-archand/tidy-docswith/refactor-deep; running both back-to-back in the same session is usually redundant. Prefer/review-deepwhen release readiness is the goal.