Christian Nennemann
83e09b70f2
Sprint 1 — Workflow Intelligence (A1-A3):
- Conditional escalation: fast→standard on 2+ CRITICALs
- Guardian fast-path: skip remaining reviewers on clean pass
- Confidence-triggered escalation: pause/upgrade/probe on low scores
Sprint 2 — Quality Loop (B1-B2, B5-B6):
- Maker self-review checklist before submitting to Check phase
- Proposal diff ("What Changed") on cycle 2+ revisions
- Convergence detection: escalate to user if same finding persists 2 cycles
- Cross-archetype dedup: merge duplicate findings from different reviewers
Sprint 3 — Completion & Verification (B3-B4):
- Completion promise: user-defined done criteria checked in Act phase
- Post-merge verification: run tests on main, auto-revert on failure
Sprint 4 — Parallel & Scale (C1-C4):
- Parallel team orchestration: 2-3 independent teams with merge gate
- Task dependency graph in autonomous queue format
- Auto-resume on interruption via .archeflow/state.json
- Budget-aware scheduling with automatic workflow downgrade
86 lines
3.6 KiB
Markdown
86 lines
3.6 KiB
Markdown
---
|
|
name: check-phase
|
|
description: 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:
|
|
|
|
```markdown
|
|
## 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.
|