claude-archeflow-plugin/skills/check-phase/SKILL.md

name, description

name	description
check-phase	Use when you are acting as Guardian, Skeptic, Sage, or Trickster archetype in the Check phase. Defines shared review rules and output format.

Check Phase

Multiple reviewers examine the Maker's implementation in parallel. Each agent definition has its specific protocol — this skill defines the shared rules.

Shared Rules

1. Read the proposal first. Review against the intended design, not invented requirements.
2. Read the actual code. Use git diff on the Maker's branch. Don't review descriptions alone.
3. Structured findings. Use the standardized finding format below for every issue.
4. Clear verdict: APPROVED or REJECTED with rationale.

Finding Format

Every finding must use this format for cross-cycle tracking:

| Location | Severity | Category | Description | Fix |
|----------|----------|----------|-------------|-----|
| src/auth/handler.ts:48 | CRITICAL | security | Empty string bypasses validation | Add length check before processing |

Severity:

• CRITICAL — Must fix. Blocks approval.
• WARNING — Should fix. Doesn't block alone.
• INFO — Nice to have. Never blocks.

Categories (use consistently for cross-cycle tracking):

• security — Injection, auth bypass, data exposure, secrets
• reliability — Error handling, edge cases, race conditions, crashes
• design — Architecture, assumptions, scalability, coupling
• breaking-change — API compatibility, schema migrations, removals
• dependency — New deps, version conflicts, license issues
• quality — Readability, maintainability, naming, duplication
• testing — Missing tests, weak assertions, untested paths
• consistency — Deviates from codebase patterns

Consolidated Output

After all reviewers finish, compile:

## Check Phase Results — Cycle N

### Guardian: APPROVED
| Location | Severity | Category | Description | Fix |
|----------|----------|----------|-------------|-----|
| src/auth/handler.ts:52 | WARNING | security | Missing rate limit | Add rate limiter middleware |

### Skeptic: APPROVED
| Location | Severity | Category | Description | Fix |
|----------|----------|----------|-------------|-----|
| src/auth/handler.ts:30 | INFO | design | Consider caching validated tokens | Add TTL cache for token validation |

### Sage: APPROVED
| Location | Severity | Category | Description | Fix |
|----------|----------|----------|-------------|-----|
| tests/auth.test.ts:15 | WARNING | testing | Test names don't describe behavior | Rename to "should reject expired tokens" |

### Trickster: REJECTED
| Location | Severity | Category | Description | Fix |
|----------|----------|----------|-------------|-----|
| src/auth/handler.ts:48 | CRITICAL | reliability | Empty string bypasses validation | Add `if (!token || token.trim() === '')` guard |

### Deduplication
If two reviewers raise the same issue (same file + same category), merge:
| Guardian + Skeptic | CRITICAL | security | Input not sanitized (src/api.ts:30) | Add validation |

Use the higher severity. Don't double-count in the verdict.

### Verdict: REJECTED — 1 critical finding
→ Build cycle feedback (see orchestration skill) and feed to Plan phase

Why Structured Findings Matter

The standardized format enables:

• Cross-cycle tracking: Same category + location = same issue. Can detect resolution or regression.
• Feedback routing: Security/design findings → Creator. Quality/testing findings → Maker.
• Shadow detection: CRITICAL:WARNING ratios, finding counts, and category distributions are measurable.
• Metrics: Severity counts feed into the orchestration summary.