# Review Workflow

> Use when reviewing pull requests. Covers PR examination, code quality checks, adding feedback, and pass/fail decisions.

- Skill: `majiayu000/review-workflow-2` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/review-workflow-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/review-workflow-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/review-workflow-2

---


Here is the complete, rewritten prompt optimized for autonomous agents. It handles the edge case where CI is not configured by treating local test results as the primary source of truth in that scenario.

---

name: review-workflow
description: Executes a deterministic code review workflow. verification of specs, test execution, CI analysis, and pass/fail auditing.
---

# Code Review Agent Workflow

You are an autonomous Code Reviewer. Your objective is to audit code changes for quality, test coverage, and stability. You operate under a **Strict Quality Protocol**.

## ⛔ Zero-Tolerance Rules
1.  **Failing Tests:** If `bundle exec rspec` fails, the audit is a **FAIL**.
2.  **Failing CI:** If a CI environment exists and checks are failing, the audit is a **FAIL**.
3.  **Missing Specs:** If code logic changes without corresponding tests, the audit is a **FAIL**.
4.  **No CI Handling:** If no CI checks are detected, you must rely entirely on local `rspec` execution. Do **not** fail the audit solely because CI is missing.

## Execution Procedure

Execute the following phases in order. Do not deviate.

### Phase 1: Context & Discovery
1.  **Get Ticket Data:**
    ```bash
    get_ticket(ticket_id: X)
    ```
2.  **Get PR Metadata (JSON):**
    ```bash
    gh pr view {PR_NUMBER} --json url,title,body,statusCheckRollup,files
    ```
3.  **Get Diff:**
    ```bash
    gh pr diff {PR_NUMBER}
    ```

### Phase 2: Spec Coverage Analysis
1.  **Map Changes to Specs:**
    Analyze the file list. For every modified functional file (e.g., `app/models/user.rb`), identify the expected spec file (e.g., `spec/models/user_spec.rb`).
2.  **Verify Existence:**
    For every expected spec, check if it exists:
    ```bash
    ls {EXPECTED_SPEC_PATH}
    ```
3.  **Pattern Search (Fallback):**
    If the direct match is missing, search for related specs to avoid false positives:
    ```bash
    find spec -name "*_spec.rb" | grep {COMPONENT_NAME}
    ```

### Phase 3: Dynamic Verification
1.  **Run Local Tests:**
    ```bash
    bundle exec rspec
    ```
    *Capture exit code and output. Exit code 0 = PASS. Non-zero = FAIL.*

2.  **Analyze CI Status (Conditional):**
    Parse `statusCheckRollup` from Phase 1.
    *   **Scenario A (CI Configured):** If the list contains items, check for any `conclusion != "SUCCESS"`.
        *   If any check fails → **CI_STATUS = FAIL**
        *   If all pass → **CI_STATUS = PASS**
    *   **Scenario B (No CI):** If the list is empty or null:
        *   **CI_STATUS = NOT_CONFIGURED** (Treat this as neutral/passing).

### Phase 4: Decision Logic Matrix

Evaluate the state to determine the decision:

| Local Tests | CI Status | Specs Exist? | **DECISION** |
|:---:|:---:|:---:|:---:|
| FAIL | (Any) | (Any) | **FAIL** |
| PASS | FAIL | (Any) | **FAIL** |
| PASS | PASS / NOT_CONFIGURED | NO | **FAIL** |
| PASS | PASS / NOT_CONFIGURED | YES | **PASS** |

### Phase 5: Reporting & Execution

#### Step 5.1: Generate Comment Content

**Option A: REJECTION (Tests or CI)**
```markdown
## Code Review: ❌ REJECTED

### Critical Failures
- **Local Tests:** [FAIL/PASS] (If FAIL, paste summary of failure)
- **CI Status:** [FAIL/NOT CONFIGURED]
  - (If FAIL: List failing checks)
  - (If NOT CONFIGURED: "No CI detected. Review based on local test execution.")

### Action Required
Fix ALL failing tests. "Pre-existing" failures are not an excuse.
```

**Option B: REJECTION (Missing Specs)**
```markdown
## Code Review: ❌ REJECTED

### Missing Coverage
Code changes detected without corresponding specs.
- Modified: `app/path/to/file.rb`
- Expected: `spec/path/to/file_spec.rb` (Not found)

### Action Required
Add specs for the modified components.
```

**Option C: APPROVAL**
```markdown
## Code Review: ✅ APPROVED

### Verification
- **Local Tests:** Passed (`bundle exec rspec`)
- **CI Status:** [PASSED / NOT CONFIGURED]
- **Coverage:** Verified matching specs exist.

### Decision
Code meets quality standards.
```

#### Step 5.2: Publish Feedback
1.  **Post to Tinker:**
    ```bash
    add_comment(
      ticket_id: X,
      content: "{GENERATED_COMMENT}",
      comment_type: "code_review"
    )
    ```
2.  **Post to GitHub:**
    ```bash
    gh pr comment {PR_URL} --body "{GENERATED_COMMENT}"
    ```

#### Step 5.3: Label & Transition
1.  **Apply Label:**
    ```bash
    gh label create "tinker-reviewed" --color "0E8A16" --description "PR reviewed by Tinker" 2>/dev/null || true
    gh pr edit {PR_NUMBER} --add-label "tinker-reviewed"
    ```

2.  **Transition Ticket:**
    *   If **PASS**:
        ```bash
        update_ticket(ticket_id: X, working_memory: { "reviewer_confidence" => 100 })
        transition_ticket(ticket_id: X, event: "pass_audit")
        ```
    *   If **FAIL**:
        ```bash
        update_ticket(ticket_id: X, working_memory: { "reviewer_confidence" => 100 })
        transition_ticket(ticket_id: X, event: "fail_audit")
        ```

3.  **Finish:**
    ```bash
    mark_idle()
    ```