---
name: spec-review
description: SPEC 품질 리뷰 본체 — GPT/Antigravity 크로스 검증, 100-point gate, Race Review(수렴 종료), Codex 적대 리뷰, 사용자 체크포인트.
when_to_use: spec 완료 후 또는 /vibe.spec Phase 4에서 체인. 직접 호출 금지.
user-invocable: false
tier: core
---

# spec-review — SPEC Quality Review

Review and enhance SPEC with GPT/Antigravity cross-validation.

**Purpose:** Run this skill after `spec` to ensure accurate review execution. For large contexts, invoke in a new session.

---

## Usage

This skill is automatically called in Phase 4 of the `/vibe.spec` orchestrator. If direct invocation is needed:

```
Load skill `spec-review` with feature: "feature-name"
```

Or via natural language trigger: "스펙 리뷰", "review spec", "명세 리뷰".

**Prerequisites:**
- SPEC file exists: `.vibe/specs/{feature-name}.md` (single) or `.vibe/specs/{feature-name}/_index.md` (split)
- Feature file exists: `.vibe/features/{feature-name}.feature` (single) or `.vibe/features/{feature-name}/_index.feature` (split)

---

## Codex Plugin Integration

> **Codex plugin detection**: Auto-detected at workflow start with the command below.
>
> ```bash
> CODEX_AVAILABLE=$(node "{{VIBE_PATH}}/hooks/scripts/codex-detect.js" 2>/dev/null || echo "unavailable")
> ```
>
> If `available`, `/codex:adversarial-review` is automatically invoked. If `unavailable`, falls back to the existing GPT+Antigravity workflow.

---

> **⏱️ Timer**: Call `getCurrentTime` tool at the START. Record the result as `{start_time}`.

**`.last-feature` pointer update** (immediately after Timer):

```
Write ".vibe/.last-feature" ← feature-name (one line)
If the value is already the same, no-op.
```

## Workflow

```
/vibe.spec "feature" → SPEC created (Phase 3)
        ↓
Phase 4: spec-review skill (this) → Quality validation + GPT/Antigravity review
        ↓
    /vibe.run "feature"
```

**For large contexts**: After `/new`, re-enter `/vibe.spec "feature"` → Smart Resume will start from Phase 4.

---

## File Reading Policy (Mandatory)

- **Delegate SPEC reading to sub-agents** — Do NOT read all SPEC/Feature files in main session
- **Split structure (3+ phases)**: Use `Task(subagent_type="explorer-medium")` to read and summarize
- **Single file structure**: Main session may Read directly (small enough)
- **Never use Grep** for content analysis — Grep is for file location only
- **Agent spawn rule**: Include "Read target files FULLY with Read tool" in agent prompts

## Step 1: Load SPEC Files

Detect SPEC structure (single file or split folder) and read files:

**Single file structure:**
```
.vibe/specs/{feature-name}.md
.vibe/features/{feature-name}.feature
```

**Split folder structure:**
```
.vibe/specs/{feature-name}/_index.md      (+ phase files)
.vibe/specs/{feature-name}/phase-*.md     (phase-1-xxx.md, phase-2-xxx.md, ...)
.vibe/features/{feature-name}/_index.feature (+ phase files)
.vibe/features/{feature-name}/phase-*.feature
```

**Detection logic:**
1. Check if `.vibe/specs/{feature-name}/` directory exists → Split mode
2. Otherwise check `.vibe/specs/{feature-name}.md` → Single mode
3. If neither exists → Error

**Split mode file loading:**
1. Read `_index.md` for master SPEC overview
2. Glob `phase-*.md` files and read all phase SPECs
3. Read corresponding `_index.feature` and `phase-*.feature` files

**Output:**
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 SPEC REVIEW: {feature-name}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Loading files...
  Mode: {single|split}
  ✅ SPEC: .vibe/specs/{feature-name}.md (or _index.md + N phase files)
  ✅ Feature: .vibe/features/{feature-name}.feature (or _index.feature + N phase files)

Extracted info:
  - Feature: {feature description}
  - Stack: {tech stack}
  - Phases: {number of phases}
  - Scenarios: {number of scenarios}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

---

## Step 2: Quality Validation (100-Point Gate)

**🚨 MANDATORY: Score must reach 100 to proceed. Loop until perfect or stuck.**

### 2.1 Quality Checklist

| Category | Check Item | Weight |
|----------|------------|--------|
| **Completeness** | All user flows included in Task | 15% |
| **Completeness** | All ACs converted to Feature scenarios | 10% |
| **Completeness** | Error handling scenarios defined | 10% |
| **Specificity** | All numbers specified (timeout, limits, etc.) | 15% |
| **Specificity** | No ambiguous terms ("appropriate", "proper", etc.) | 10% |
| **Testability** | Each AC is verifiable | 10% |
| **Testability** | Feature scenarios have concrete Given/When/Then | 10% |
| **Security** | Auth/permission requirements specified | 10% |
| **Performance** | Response time/load requirements specified | 10% |

### 2.2 Quality Gate Loop (No Round Cap)

```python
iteration = 0
prev_score = -1

while True:
    iteration += 1
    score = calculate_quality_score(spec, feature)

    print(f"━━━ Quality Check [{iteration}] ━━━")
    print(f"Score: {score}/100")

    if score >= 100:
        print("✅ Quality Gate PASSED (100/100)")
        break

    # Auto-fixer hit a wall → ask the user (prevents runaway AND respects 100 target)
    if score == prev_score:
        missing_items = identify_missing_items(spec)
        print(f"⚠️ Auto-fixer limit reached: stuck at {score}/100")
        print(f"Remaining items require human input:")
        for item in missing_items:
            print(f"  ❌ {item}")

        if ultrawork_mode:
            # ultrawork: no user intervention, record TODO and proceed
            print("ℹ️ ultrawork mode — recording gaps to TODO and proceeding")
            record_todo(missing_items)
            break

        # Interactive: ask the user to fill in or explicitly approve
        user_input = ask_user(
            "Please either:\n"
            "  1. Provide values for the remaining items (I'll apply them)\n"
            "  2. Type 'proceed' to accept current score and continue\n"
            "  3. Type 'abort' to stop the workflow"
        )

        if user_input == "abort":
            raise WorkflowAborted("User aborted at Quality Gate")
        if user_input == "proceed":
            record_todo(missing_items)
            break
        # otherwise: apply user-provided values → re-evaluate
        apply_user_values(user_input)
        continue

    prev_score = score

    # Auto-fix missing items
    missing_items = identify_missing_items(spec)
    for item in missing_items:
        auto_fix(item)
        update_spec()
        update_feature()

    print(f"✅ Applied {len(missing_items)} fixes - Re-evaluating...")
```

**Termination conditions:**
- `score == 100` → pass (primary success)
- `score == prev_score` (auto-fixer stuck) → **ask the user**:
  - User provides values → re-evaluate (loop continues, may reach 100)
  - User says "proceed" → record gaps as TODO and continue to Step 3
  - User says "abort" → stop entire workflow
  - `ultrawork` mode → skip prompt, auto-record TODO and continue
- No iteration cap — the only way to exit without 100 is explicit user approval or ultrawork.

**Output format:**
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 QUALITY GATE [1]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Score: 87/100 ⚠️ BELOW 100

Missing items:
  ❌ Error handling scenarios (10%)
  ❌ Performance targets (5%)

Auto-fixing...
  ✅ Added network error handling scenario
  ✅ Added response time targets (<500ms)

Re-evaluating...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 QUALITY GATE [2]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Score: 96/100 ⚠️ BELOW 100

Missing items:
  ❌ Concurrent session policy (4%)

Auto-fixing...
  ✅ Added concurrent session policy

Re-evaluating...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 QUALITY GATE [3]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Score: 100/100 ✅ PASSED

✅ Quality Gate PASSED - proceeding to GPT/Antigravity review
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**Stuck case (auto-fixer limit reached):**
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 QUALITY GATE [4]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Score: 87/100 ⚠️ STUCK (same as previous iteration)

Auto-fixer hit a wall. These items need human input:
  ❌ Business rule: monthly subscription renewal grace period (days?)
  ❌ Target latency for search API (<?ms)
  ❌ Data retention policy for audit logs (how many days?)

How would you like to proceed?
  1. Provide the values directly (e.g., "grace period 7 days, search 500ms, audit logs 90 days")
     → Values will be applied and the score re-evaluated (100 may be reachable)
  2. "proceed" — Accept the current score, record remaining items as TODO, then continue to Step 3
  3. "abort" — Stop the workflow

(In ultrawork mode, this prompt is skipped — TODO is auto-recorded and execution continues)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

### 2.3 Auto-Fix Rules

| Missing Item | Auto-Fix Method |
|--------------|-----------------|
| Missing AC | Auto-generate AC based on Task |
| Numbers not specified | Apply project defaults (timeout 30s, etc.) |
| Missing error handling | Add common error scenarios |
| Missing performance targets | Apply industry standard criteria |
| Missing security | Add auth/data protection requirements |
| Ambiguous terms | Replace with specific values |

---

## Step 3: Race Review (GPT + Antigravity Cross-Validation) - Convergence-Based (No Round Cap)

**RULES FOR RACE REVIEW:**

1. **YOU MUST** use the Bash tool to call `llm-orchestrate.js` directly
2. **DO NOT** simulate or fake review results
3. Run rounds sequentially (each round uses updated SPEC)
4. **No hard round cap** — loop until P1=0 AND no new findings (convergence)

> Race Mode reviews SPEC with GPT and Antigravity in parallel, then cross-validates findings for higher confidence. The loop continues until quality converges naturally.

### Termination Rules

- **P1 = 0 AND no new findings this round** → converged, stop (primary success)
- **Round 1 with P1 = 0 AND no P2/P3** → perfect on first try, stop (early success)
- **Round N findings == Round N-1 findings** → **stuck**: LLMs keep flagging same issues that auto-applier can't resolve → **ask the user** (see 3.2.1)

### Stuck Handling (3.2.1)

When the same findings repeat across rounds, the auto-apply loop has hit a wall. This typically means:
- The fix requires human judgment (architectural trade-off, domain rule, etc.)
- The LLMs are producing a false positive that the auto-applier can't dismiss
- The suggested fix conflicts with an existing constraint

**Interactive mode** — prompt the user:

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠️ RACE REVIEW STUCK at Round {N}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Same findings repeated from Round {N-1}. Auto-applier cannot resolve:

| # | Issue | Severity | GPT | Antigravity | Reason it's stuck |
|---|-------|----------|-----|--------|-------------------|
| 1 | {issue title} | P1 | ✅ | ✅ | {e.g., "fix requires domain decision"} |
| 2 | {issue title} | P2 | ✅ | ❌ | {e.g., "conflicts with existing constraint"} |

How would you like to proceed?
  1. Provide a resolution directly (e.g., "issue 1: retry 5 times, issue 2: ignore")
     → Changes will be applied and the next round re-run
  2. "proceed" — Record current issues as TODO and continue to Step 4
  3. "abort" — Stop the workflow

(In ultrawork mode, this prompt is skipped — TODO is auto-recorded and execution continues)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**Pseudocode:**

```python
if current_findings == prev_findings:
    if ultrawork_mode:
        print("ℹ️ ultrawork mode — recording stuck issues to TODO and proceeding")
        record_todo(current_findings)
        break

    user_input = ask_user(
        "Race Review stuck. Please either:\n"
        "  1. Provide resolution for the listed issues\n"
        "  2. Type 'proceed' to record as TODO and continue to Step 4\n"
        "  3. Type 'abort' to stop the workflow"
    )

    if user_input == "abort":
        raise WorkflowAborted("User aborted at Race Review")
    if user_input == "proceed":
        record_todo(current_findings)
        break
    # otherwise: apply user-provided resolutions → next round
    apply_user_resolutions(user_input)
    continue  # re-run the round with updated SPEC
```

### Narrowing Scope (Noise Reduction)

To prevent LLM cosmetic noise from causing infinite loops while still reaching 100% quality:

| Round | Scope |
|-------|-------|
| 1 | Full scope (P1 + P2 + P3) |
| 2 | P1 + P2 only |
| 3+ | P1 only (until P1=0 or convergence) |

### 3.1 Review Loop (No Round Cap)

**Run GPT + Antigravity in PARALLEL via Bash tool for each round. Stop when termination rules trigger.**

**🚨 IMPORTANT: SPEC content is too large for CLI arguments. Use --input file method (no pipe needed).**

**Procedure for each round:**

**Step A: Save SPEC content + prompt as JSON to scratchpad temp file (using Write tool):**
- Write JSON to `[SCRATCHPAD]/spec-review-input.json` with content:
```json
{"prompt": "Review this SPEC for completeness, specificity, testability, security, and performance. Round [N] (scope: [SCOPE]). Find issues and improvements. Return JSON: {issues: [{id, title, description, severity, suggestion}]}. SPEC content: [SPEC_CONTENT]"}
```
- Where `[SPEC_CONTENT]` is the full SPEC text (properly JSON-escaped inside the prompt string)
- `[SCOPE]` is `P1+P2+P3` for round 1, `P1+P2` for round 2, `P1` for rounds 3+

**Step B: Script path:**
- `[LLM_SCRIPT]` = `{{VIBE_PATH}}/hooks/scripts/llm-orchestrate.js`

**Step C: Run GPT + Antigravity in PARALLEL (two separate Bash tool calls at once):**

```bash
# GPT review (Bash tool call 1)
node "[LLM_SCRIPT]" gpt orchestrate-json --input "[SCRATCHPAD]/spec-review-input.json"
```

```bash
# Antigravity review (Bash tool call 2 - run in parallel with GPT)
node "[LLM_SCRIPT]" antigravity orchestrate-json --input "[SCRATCHPAD]/spec-review-input.json"
```

**🚨 MANDATORY: Replace `[SCRATCHPAD]` with the actual scratchpad directory path.**
**🚨 Replace `[N]` with the current round number (1, 2, 3, ...).**
**🚨 Replace `[LLM_SCRIPT]` with the resolved absolute path from Step B.**
**🚨 Run GPT and Antigravity calls in PARALLEL (two separate Bash tool calls at once).**

- Round 1: Write SPEC → Run GPT + Antigravity in parallel (full scope) → Cross-validate → Apply fixes → Update SPEC file
- Round 2: Write updated SPEC → Run (P1+P2 scope) → Cross-validate → Apply fixes → Update SPEC file
- Round 3+: Write updated SPEC → Run (P1-only scope) → Cross-validate → Apply fixes → Continue until P1=0 AND no new findings (or convergence detected)

### 3.2 Cross-Validation Rules

| Agreement | Priority | Action |
|-----------|----------|--------|
| Both models agree (100%) | P1 | Auto-apply immediately |
| 1 model only (50%) | P2 | Auto-apply with note |

**After each round:**

1. Cross-validate findings (issues found by 2+ models → P1, single model → P2)
2. Merge feedback with confidence scores
3. Auto-apply P1/P2 improvements to SPEC and Feature files (use Edit tool)
4. Continue to next round with updated SPEC content

### 3.3 User Decision Checkpoint (After Convergence)

**🚨 MANDATORY: Run user judgment checkpoint when the review loop reaches convergence**

> Type 6 (Iterative-Reasoning) pattern: AI does not decide alone — judges together with the user

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔍 USER CHECKPOINT: Review Results
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Key changes found across {N} review rounds:

| # | Change | Source | Confidence |
|---|--------|--------|------------|
| 1 | {change1} | GPT+Antigravity | 100% |
| 2 | {change2} | GPT only | 50% |
| ... | ... | ... | ... |

Questions:
1. Are there any changes above you'd like to exclude?
2. Are there any additional requirements that should be specified?
3. Do you agree with the technical approach?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**Checkpoint action rules:**

| Situation | Action |
|-----------|--------|
| `ultrawork` mode | Skip checkpoint, auto-proceed |
| Normal mode | Must wait for user response |
| User requests changes | Apply changes, then re-run checkpoint |
| User approves | Proceed to Step 4 |

**Output format:**
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🏁 SPEC RACE REVIEW - Round 1 (scope: P1+P2+P3)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Model Results:
| Model  | Issues | Duration |
|--------|--------|----------|
| GPT    | 2      | 1823ms   |
| Antigravity | 2      | 2156ms   |

Cross-Validated Issues:
| Issue                    | GPT | Antigravity | Codex | Confidence |
|--------------------------|-----|--------|-------|------------|
| Missing retry logic      | ✅  | ✅     | ✅    | 100% → P1  |
| Missing rate limiting    | ✅  | ✅     | ✅    | 100% → P1  |
| Token refresh unclear    | ✅  | ❌     | ❌    | 50% → P2   |

Auto-applying...
  ✅ [P1] Added retry logic (3 attempts, exponential backoff)
  ✅ [P1] Added rate limiting (100 req/min)
  ✅ [P2] Added token refresh flow

✅ Round 1 complete - 3 improvements (2 P1, 1 P2)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🏁 SPEC RACE REVIEW - Round 2 (scope: P1+P2)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Cross-Validated Issues:
| Issue                       | GPT | Antigravity | Codex | Confidence |
|-----------------------------|-----|--------|-------|------------|
| Concurrent session unclear  | ✅  | ❌     | ❌    | 50% → P2   |

Auto-applying...
  ✅ [P2] Added concurrent session policy

✅ Round 2 complete - 1 improvement
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🏁 SPEC RACE REVIEW - Round 3 (scope: P1)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Cross-Validated Issues: None

✅ Converged: P1 = 0 AND no new findings
✅ Consensus Rate: 100%
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

> If new P1s appear at round 3, the loop continues to round 4, 5, ... until convergence.

### Step 3.1: Codex Adversarial Review (When Codex Plugin Is Active)

> **Activation condition**: Automatically runs when Codex plugin is installed. Skipped if not installed.
> Runs **simultaneously** with GPT+Antigravity Race Review for triple cross-validation.

Codex adversarial review **challenges the design decisions** in the SPEC:
- Validates whether an alternative architecture would be better
- Checks for over-engineering or under-engineering
- Identifies missing edge cases and non-functional requirements

**Execution (parallel with GPT+Antigravity Race):**

```
/codex:adversarial-review
```

**Result integration**: Add Codex column to the Race Review cross-validation table:

```markdown
| Issue | GPT | Antigravity | Codex | Confidence |
|-------|-----|--------|-------|------------|
| {issue} | ✅/❌ | ✅/❌ | ✅/❌ | {%} |
```

- 2 or more of 3 models agree → **High Confidence**
- Issue found only by Codex → **P2** (requires design perspective review)
- All 3 models agree → **P1** (fix immediately)

---

## Step 3.5: Review Debate Team (Agent Teams)

> **Team definition**: See `agents/teams/review-debate-team.md` (SPEC Review context)
> **Condition**: Agent Teams enabled + 2 or more P1/P2 issues found after review loop convergence

**Activation conditions:**

| Situation | Action |
|-----------|--------|
| 2 or more P1/P2 issues | Auto-activate |
| 1 or fewer P1/P2 issues | Skip → proceed to Step 4 |
| Agent Teams disabled | Skip → proceed to Step 4 |

**Result integration:**
- Apply team consensus results to SPEC (P1 applied immediately, P2 added as notes)
- Team member shutdown_request → clean up with TeamDelete
- Proceed to Step 4 (Final Summary)

---

## Step 4: Final Summary

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ SPEC REVIEW COMPLETE: {feature-name}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Quality Score: 100/100 ✅
Review Rounds: {N} (converged: P1=0, no new findings) ✅
Total Improvements: {M}
⏱️ Started: {start_time}
⏱️ Completed: {getCurrentTime result}

Updated files:
  📋 .vibe/specs/{feature-name}.md (or split folder)
  📋 .vibe/features/{feature-name}.feature (or split folder)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

---

## Step 5: SPEC Summary for User Review

**🚨 MANDATORY: Always output this summary before proceeding to `/vibe.run`.**

After all review rounds, present the finalized SPEC to the user in a readable format:

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 SPEC SUMMARY: {feature-name}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

## Feature Overview
{1-2 line summary of feature purpose from SPEC's <role> and <context>}

## Tech Stack
{Tech stack list extracted from <context>}

## Implementation Phases
| Phase | Name | Key Tasks |
|-------|------|-----------|
| 1 | {phase name} | {1-line summary of core task} |
| 2 | {phase name} | {1-line summary of core task} |
| ... | ... | ... |

## Key Scenarios ({N} total)
{Scenario name list from Feature file}
- Scenario: {name1}
- Scenario: {name2}
- ...

## Key Constraints
{3-5 key items from <constraints>}

## Acceptance Criteria
{Summary of key items from <acceptance>}

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
If anything above is incorrect, please request changes.
If no issues, proceed with /vibe.run "{feature-name}".
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**Important:**

- List ALL Phases, Scenarios, and Constraints from SPEC without omission
- Keep it concise for quick user review
- Wait for user confirmation after review (unless ultrawork mode)
- In ultrawork mode: output summary then auto-proceed to `/vibe.run`

### 5.1 Final User Checkpoint

**🚨 MANDATORY: Final user confirmation before proceeding to `/vibe.run`**

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ SPEC Review Complete - Final Confirmation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Please answer the following questions:

1. **Requirements accuracy**: Does the SPEC above accurately describe the originally intended feature?
2. **Scope appropriateness**: Is the implementation scope neither too large nor too small?
3. **Tech stack**: Do you agree with the chosen tech stack?
4. **Priority**: Is the Phase order and priority correct?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
💡 Type "ok" or "proceed" to approve / share any changes you'd like made
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**Why This Checkpoint Matters:**

> More AI doing more is not always better.
> The best results come when the user thinks and judges together with AI.
> This checkpoint induces the Type 6 (Iterative-Reasoning) pattern.

---

## Next Step

```
/vibe.run "{feature-name}"
```

---

## Error Handling

### SPEC Not Found
```
❌ ERROR: SPEC file not found

Expected (single): .vibe/specs/{feature-name}.md
Expected (split):  .vibe/specs/{feature-name}/_index.md

Please run /vibe.spec "{feature-name}" first to create the SPEC.
```

### Feature Not Found
```
❌ ERROR: Feature file not found

Expected (single): .vibe/features/{feature-name}.feature
Expected (split):  .vibe/features/{feature-name}/_index.feature

Please run /vibe.spec "{feature-name}" first to create the Feature file.
```

### GPT/Antigravity Call Failed
```
⚠️ WARNING: {GPT|Antigravity} call failed

Error: {error message}

Continuing with {other model} results only...
```

---

## Quick Mode

For faster iteration (1 round only): pass `--quick` flag when invoking the skill (or via `/vibe.spec "feature-name" --quick` orchestrator).

---

ARGUMENTS: $ARGUMENTS

**File Detection (execute before Step 1):**

```
Feature name: $ARGUMENTS

1. Check split folder: .vibe/specs/$ARGUMENTS/_index.md
   - If exists → Split mode (read all files in folder)
2. Check single file: .vibe/specs/$ARGUMENTS.md
   - If exists → Single mode
3. Neither exists → Show error with both expected paths
```
