---
name: evaluator-prd-audit
description: >
  Structured code audit workflow supporting both PRD-based and prompt-based evaluation modes.
  evaluatorX is a pure analyzer — reads docs + code, outputs structured Evaluation Result Payload.
  Document writes are handled by orchestratorX, not evaluatorX.
---

# Evaluator: Code Audit Skill (PRD-Based & Prompt-Based)

## Why This Skill Is Needed

In iterative development, an independent audit step is needed after the coding agent completes implementation:
- Whether code aligns with PRD requirements or original prompt intent
- Whether code quality meets standards
- Optimization direction for the next iteration

**evaluatorX is a pure analyzer**: reads documents and code, outputs structured Evaluation Result Payload. Does not write to any document. Document updates are handled by orchestratorX.

## Trigger Conditions

Loaded when the user or upstream agent requests "audit code", "evaluate implementation", "run evaluator", "review". orchestratorX also invokes this in prompt-based mode.

---

## Core Workflow

### Step 1: Load Specification Documents

1. Read documents passed by orchestratorX (Parent + Child hybrid paths)
2. If no hybrid document, switch to **Prompt-Based mode** (see Step 2B)
3. If specification documents exist, extract:
   - **Requirements list**: functional requirements, non-functional requirements, business rules
   - **Acceptance Criteria (AC)**: verifiable conditions for each requirement
   - **Engineering file index**: Section 8.1 main index
   - **Knowledge graph**: Section 8.2 node outlines
4. **MCP knowledge graph retrieval**: Per Section 8.2, call `mcp_memory_open_nodes` to get detailed entities
5. Read Section 8.3 incremental index differences
6. **Read old Section 9**: Extract previous evaluation results for inheritance (needed by partial mode)

#### Hybrid Tree Reading

Per `orchestrator-playbook/SKILL.md` Hybrid Tree Section Map. evaluatorX-specific: read **Child Section 9** to inherit prior evaluation results (needed by partial mode).

### Step 2: Get Code Changes + Evaluation Mode Detection

1. **Read Change Summary Payload**: coderX's change summary (which files modified, which ACs claimed affected)
2. **Read git diff**: Combine with Payload scope, get unstaged + staged changes
3. If git diff is empty, get changes from the most recent commit
4. **Search context files**: Search related files for modules, interfaces, types referenced by coderX

#### Evaluation Mode Detection

| Mode | Identifier | Trigger | Behavior |
|------|-----------|---------|----------|
| **Full** | `full` | First evaluation / prior Needs Fix / no history 9.* / Payload lacks AC list | Evaluate all ACs in Child Section 7 |
| **Partial** | `partial` | Prior PASS and Payload contains non-empty AC list | Evaluate only declared ACs, inherit rest |
| **Prompt-Based** | `prompt-based` | No PRD/hybrid document [DEPRECATED for xlocal — always has Hybrid Tree] | Evaluate original user prompt intent |

**Decision rules**:
1. No hybrid document -> `prompt-based`
2. Read Child Section 9.1 `evaluation_mode` and 9.4 conclusion
3. Prior `Needs Fix` or no history -> `full`
4. Prior `PASS` and Payload has non-empty AC list -> `partial`
5. Other -> `full` (safe fallback)

**Partial mode execution**:
1. Extract prior passed AC list from Child Section 9.2
2. Identify this round's declared ACs from Payload's `Affected ACs`
3. Evaluate only ACs within declared scope
4. Unaffected ACs directly inherit prior status

#### Step 2B: Prompt-Based Mode (No PRD) [DEPRECATED — xlocal no longer uses this path]

> **Deprecated**: As of the xlocal optimization, Mode B always generates a Hybrid Tree before evaluation. This mode is retained for backward compatibility with other workflows that may lack hybrid documents, but xlocal will never trigger it.

When no hybrid document exists, evaluation criteria is the **original user prompt**:

| Aspect | PRD Mode | Prompt Mode |
|--------|---------|-------------|
| Criteria | PRD requirements + AC | Original prompt intent |
| AC evaluation | Per-item | **Omitted** (no AC) |
| Issue list | Against PRD | Against prompt intent |
| Conclusion | Based on AC | Based on prompt completion |

**Prompt mode flow**:
1. Read the original prompt passed by orchestratorX
2. Decompose into **verifiable intent points**
3. For each intent point, check whether code changes satisfy: met / partially met / not met / irrelevant change
4. Execute the same code quality review as PRD mode (Step 4)
5. Output Evaluation Result Payload (same format, but AC Status Table replaced with intent point analysis)

---

### Step 3: AC Per-Item Evaluation

AC source: current Child's Section 7 (branch AC). Do not read from Parent Section 7 (that is the routing table).

Each AC must be evaluated individually:

| Status | Description |
|--------|-------------|
| Pass | Code directly proves the AC is met |
| Partial Pass | Implementation exists but is incomplete |
| Fail | Current implementation cannot satisfy the AC |
| Unevaluable | Missing runtime conditions or external dependencies |

For each AC record: original text, implementation location (file:line), judgment status, judgment basis.

Requirement-level status is derived from AC results: all Pass -> Fully Implemented, partial Pass -> Partially Implemented, all Fail -> Not Implemented.

### AC Impact Cross-Validation

**Do not trust coderX's declarations.** evaluatorX cross-validates via git diff:

1. Extract changed file list from git diff
2. Build **file <-> AC mapping** from Child Section 7
3. Compare:
   - Diff touches files associated with ACs coderX did not declare -> mark as **implicitly affected**
   - Force-evaluate these implicitly affected ACs
4. Output AC Status Table covers all **actually** affected ACs (declared + implicit)

### Cross-Branch Dependency Handling

When evaluating a Child, check Section 8.3 and Parent Section 8.3:
- If current Child depends on other Children's outputs: record dependency but **do not evaluate** other Children's code
- If dependency unsatisfied (e.g., depends on Child B but Child B status is not PASS): mark as **Blocking Dependency**
- Cross-branch conflict (two Children modify the same file): report as P0 **Cross-Branch Violation**

### Step 4: Code Quality Review

Beyond requirement alignment, review general code quality:

1. **Correctness**: logic errors, boundary omissions, null risks
2. **Robustness**: error handling, input validation
3. **Maintainability**: naming, comments, module structure
4. **Performance risks**: unnecessary loops, repeated queries
5. **Security**: injection risks, sensitive information leaks

#### Tree Mode: Ownership Awareness

- If coderX modified files in another Child's `Owned Entities` -> P0 cross-branch violation
- If modified `Referenced (shared)` -> verify backward compatibility
- If modified `Referenced (root)` -> flag for Parent-level approval

### Step 5: Output Evaluation Result Payload

**Do not write to any document.** Output structured Payload for orchestratorX to read and process. Format follows `orchestrator-playbook/modules/02-bus-payload.md` (Payload Type 2).

### Step 6: Supplementary Search

If the following situations are discovered during evaluation, proactively search other project files:
- Changed code references functions/classes/modules not included in the changes
- Specification requirements involve integration points with existing systems
- Suspected duplicate implementation or conflict with existing functionality

Prioritize reading via 8.1 file index; supplement with 8.3 incremental differences as needed.

---

## Output Behavior Constraints

1. **Evaluate only based on visible facts**: Do not infer beyond code and specification scope. Mark uncertain items as "Pending Confirmation".
2. **Actionability**: Every issue must specify file:line so coderX can directly locate the fix.
3. **Severity distinction**: P0 blocking (must fix) / P1 improvement (optimization opportunity) / P2 suggestion (non-functional).
4. **No standard, no evaluation**: Requirements without defined evaluation criteria in the spec document are marked "Unevaluable".
5. **Index first**: Read 8.1 main index and knowledge entries before evaluation; supplement with 8.3 incremental differences when present.
