evaluator-prd-audit

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 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.