This skill is NOT optional. Every task executed by ln-401/ln-403/ln-404 MUST be reviewed by ln-402 immediately. No exceptions, no batching, no skipping.
-
Receive task (isolated context): Get task ID from orchestrator (ln-400)—NO other context passed. Load all information independently from Linear. Detect type (label "tests" -> test task, else implementation/refactor).
-
Read context: Full task + parent Story; load affected components/docs; review diffs if available.
-
Review checks:
- Approach: diff aligned with Technical Approach in Story. If different → rationale documented in code comments.
- No hardcoded creds/URLs/magic numbers; config in env/config.
- Error handling: all external calls (API, DB, file I/O) wrapped in try/catch or equivalent. No swallowed exceptions. Layering respected; reuse existing components.
- Logging: errors at ERROR; auth/payment events at INFO; debug data at DEBUG. No sensitive data in logs.
- Comments: explain WHY not WHAT; no commented-out code; docstrings on public methods; Task ID present in new code blocks ().
- Naming: follows project's existing convention (check 3+ similar files). No abbreviations except domain terms. No single-letter variables (except loops).
- Docs: if public API changed → API docs updated. If new env var → .env.example updated. If new concept → README/architecture doc updated.
- Tests updated/run: for impl/refactor ensure affected tests adjusted; for test tasks verify risk-based limits and priority (≤15) per planner template.
-
AC Validation (MANDATORY for implementation tasks):
Load parent Story AC and verify implementation against 4 criteria (see
references/ac_validation_checklist.md
):
- AC Completeness: All AC scenarios covered (happy path + errors + edge cases).
- AC Specificity: Exact requirements met (HTTP codes 200/401/403, timing <200ms, exact messages).
- Task Dependencies: Task N uses ONLY Tasks 1 to N-1 (no forward dependencies on N+1, N+2).
- Database Creation: Task creates ONLY tables in Story scope (no big-bang schema).
If ANY criterion fails → To Rework with specific guidance from checklist.
-
Side-Effect Bug Detection (MANDATORY):
While reviewing affected code, actively scan for bugs/issues NOT related to current task:
- Pre-existing bugs in touched files
- Broken patterns in adjacent code
- Security issues in related components
- Deprecated APIs, outdated dependencies
- Missing error handling in caller/callee functions
For each side-effect bug found:
- Create new task in same Story (Linear: create_issue with parentId=Story.id; File: create task file)
- Title:
[BUG] {Short description}
- Description: Location, issue, suggested fix
- Label: ,
- Priority: based on severity (security → 1 Urgent, logic → 2 High, style → 4 Low)
- Do NOT defer — create task immediately, reviewer catches what executor missed
-
Agent Review: Per
shared/references/agent_delegation_pattern.md
§Parallel Aggregation.
- Template: with + from Step 2.
- Verdict escalation: Agent findings with area=security|correctness can escalate Done → To Rework.
- Display:
"Agent Review: codex ({duration}s, {N}), gemini ({duration}s, {N}). Validated: {accepted}/{total}"
-
Decision (for current task only):
- If only nits and no critical agent findings: apply minor fixes and set Done.
- If issues remain (own review OR accepted agent suggestions with security/correctness area): set To Rework with comment explaining why (best-practice ref) and how to fix.
- Side-effect bugs do NOT block current task's Done status (they are separate tasks).
- If Done: commit all uncommitted changes with message referencing task ID:
git add -A && git commit -m "Implement {task_id}: {task_title}"
-
Update: Set task status in Linear; update kanban: if Done → remove task from kanban (Done section tracks Stories only, not individual Tasks); if To Rework → move task to To Rework section; add review comment with findings/actions. If side-effect bugs created, mention them in comment. Include agent review summary in comment.