Add /eforge evaluate skill and clean up obsolete LLM references

- Create evaluate.md skill: runs eforge eval, interprets scores, reviews
  sample records for realism, suggests improvements
- Clean up TODO.md: mark Bedrock client, semantic validation, and
  alternative LLM backends as obsolete (replaced by skills architecture)
- Update install_skills.py to bundle the new evaluate skill (4 skills total)
- Phase 4.7 now complete via skill-based approach

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: DavidJBianco

TODO.md

@@ -293,9 +293,9 @@
 - [x] Backward compatible: no persona = uniform activity at all hours
 - [x] 13 tests in `tests/unit/test_persona_activity.py`
 
-### 2.7 LLM Integration (Bedrock Client) — DEFERRED TO PHASE 3
+### 2.7 LLM Integration (Bedrock Client) — ✅ OBSOLETE
 
-**Moved to Phase 3.1** - LLM client and retry logic are only needed for the conversational interface. Will be implemented alongside Phase 3.1 (Conversational Interface).
+**Replaced by Claude Code Skills.** Phase 3 adopted a skills-based architecture where all LLM-driven work (scenario creation, validation, evaluation review) happens through Claude Code skills rather than a built-in Bedrock client. No code-level LLM calls are needed.
 
 ### 2.8+2.9 Medium Dataset Support & Phase 2 Completion ✅ COMPLETE
 
@@ -340,7 +340,7 @@
 
 **Phase 2 Status: ✅ COMPLETE**
 - ✅ All phases complete: 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.8+2.9, 2.10
-- 🔀 Deferred: 2.7 (LLM Integration) → folded into Phase 3.1
+- ✅ Obsolete: 2.7 (LLM Integration) → replaced by Claude Code Skills architecture
 
 **Phase 2 Milestone:** Can generate datasets across 7 formats in parallel with threaded emitters. 100-user 8-hour scenarios complete in ~14 seconds. Persona-based temporal distributions, network visibility with TAP/SPAN sensors, OS-aware log routing, and cross-log consistency. 526 tests passing.
 
@@ -468,10 +468,11 @@
 - [x] Organic Anomaly Rate (1-5% target)
 - [x] Tests: 13 tests
 
-### 4.7 LLM Spot-Check Layer (optional) — DEFERRED
+### 4.7 Evaluate Skill (`/eforge evaluate`) ✅ COMPLETE
 
-- [ ] Deferred until LLM client is available (Bedrock integration)
-- [ ] `--llm-review` flag placeholder in CLI (accepted but not yet functional)
+- [x] Create `commands/eforge/evaluate.md` — runs `eforge eval`, interprets results, provides qualitative LLM review
+- [x] Replaces the originally planned Bedrock-based LLM spot-check layer
+- [x] Qualitative review (record realism, narrative coherence, hunting feasibility) handled conversationally by the skill
 
 ### 4.8 Integration & Acceptance Criteria ✅ COMPLETE
 
@@ -485,7 +486,7 @@
 - [ ] Update `commands/eforge/scenario.md` to check sensor coverage during authoring
 - [ ] Flag when storyline events may not be discoverable given declared topology
 
-**Phase 4 Status:** ✅ All 5 scoring dimensions complete (23 sub-scores). `eforge eval` produces comprehensive quality reports. 653+ tests. LLM spot-check deferred.
+**Phase 4 Status:** ✅ COMPLETE. All 5 scoring dimensions (23 sub-scores), acceptance criteria, `/eforge evaluate` skill. 653+ tests.
 
 **Baseline scores on retail-store-ftp-attack (24K records, 4 sources):**
 - Overall: 78/100
@@ -502,11 +503,11 @@
 **Not part of MVP, but tracked here for future reference.**
 
 ### Short-term (Post-MVP)
-- [ ] Bedrock LLM client for semantic validation (`eforge validate --semantic`)
+- [ ] ~~Bedrock LLM client for semantic validation~~ → Handled by `/eforge validate` skill
 - [ ] Checkpointing and resume for long-running generation
 - [ ] Additional skills: create-persona, create-log-format, create-network, analyze-output
 - [ ] Example scenario collection (ransomware, credential stuffing, insider threat)
-- [ ] ~~Subjective realism evaluation (LLM-based)~~ → Moved to Phase 4.7 (LLM Spot-Check Layer)
+- [ ] ~~Subjective realism evaluation (LLM-based)~~ → Handled by `/eforge evaluate` skill
 - [ ] Config file inheritance/templating
 - [ ] PyPI package distribution
 - [ ] Additional log formats (CloudTrail, Azure Activity, GCP Audit, database logs)
@@ -518,7 +519,7 @@
 - [ ] Separate student/instructor output packages (GROUND_TRUTH.md in instructor-only directory)
 
 ### Medium-term
-- [ ] Alternative LLM backends (OpenAI, Ollama, Anthropic native, Gemini)
+- [ ] ~~Alternative LLM backends (OpenAI, Ollama, Anthropic native, Gemini)~~ → No code-level LLM calls; skills use whatever model the user's Claude Code runs
 - [ ] Web UI for scenario creation
 - [ ] Streaming output to SIEM/data lakes
 - [ ] Log format auto-detection from samples

commands/eforge/evaluate.md

@@ -0,0 +1,125 @@
+---
+name: eforge-evaluate
+description: >
+  Run EvidenceForge data quality evaluation on generated log output, interpret results, review records
+  for realism, and suggest improvements. Use this skill whenever the user wants to evaluate generated
+  data quality, check their logs for issues, review eval scores, assess hunting feasibility, or improve
+  a scenario's output. Also trigger when the user says "evaluate", "check quality", "how did the data
+  turn out", "review the output", or "eforge eval".
+---
+
+# EvidenceForge Data Quality Evaluator
+
+You are helping the user evaluate the quality of generated synthetic security log datasets using EvidenceForge's evaluation framework. The eval command scores datasets across 5 dimensions with 23 sub-scores, all deterministic and statistical. Your job is to run the eval, interpret the results, review sample records for realism, and provide actionable improvement suggestions.
+
+## Quick Start
+
+If the user has a generated output directory and scenario file:
+
+```bash
+cd /Users/dabianco/projects/SURGe/data-gen-test
+uv run eforge eval <output_dir> --scenario <scenario.yaml> --verbose
+```
+
+If they don't have generated output yet, suggest using `/eforge generate` first.
+
+## Workflow
+
+### Step 1: Locate the Output
+
+The user needs to provide:
+1. **Output directory** — the directory containing generated log files (e.g., `output/retail-store-ftp-attack-20260316-140908/`)
+2. **Scenario file** — the YAML scenario used for generation
+
+If the user doesn't specify, look for the most recent output directory under `output/` or wherever they typically generate. Ask if you can't find it.
+
+### Step 2: Run the Evaluation
+
+Run both text and JSON output:
+
+```bash
+uv run eforge eval <output_dir> --scenario <scenario.yaml> --verbose
+```
+
+Also capture the JSON for programmatic analysis:
+
+```bash
+uv run eforge eval <output_dir> --scenario <scenario.yaml> --format json 2>/dev/null
+```
+
+### Step 3: Interpret Results
+
+Present a clear summary of the evaluation results. For each dimension, explain what the score means in practical terms:
+
+**Dimension 1: Record-Level Fidelity (weight 0.15)**
+- Tier A (Parsability): Can every record be parsed? Missing fields? Type errors?
+- Tier B (Co-occurrence): Do field combinations make sense? (e.g., network logons have IP addresses)
+- Tier C (Distributions): Are event type distributions realistic?
+
+**Dimension 2: Cross-Source Coherence (weight 0.25)**
+- Source Correctness: Are records in the right log sources for the system's OS?
+- Trace Coverage: Do storyline events leave traces in all expected formats?
+- Field Agreement: Do timestamps and identifiers match across sources?
+
+**Dimension 3: Background Noise Realism (weight 0.25)**
+- Volume Adequacy: Is there enough background noise relative to the attack signal?
+- User Diversity: Do different users behave differently, or are they cookie-cutter?
+- Activity Plausibility: Are activities appropriate for the system/OS/persona?
+- Anomaly Rate: Is there a realistic 1-5% rate of anomalous-but-benign events?
+
+**Dimension 4: Temporal Realism (weight 0.15)**
+- Work Hours: Do user events cluster in persona-defined work hours?
+- Burstiness: Are inter-event times bursty (realistic) or metronomic (robotic)?
+- Causal Ordering: Are logon→process→logoff sequences correctly ordered?
+- Timing Plausibility: No impossible timing (50 commands in 3 seconds)?
+
+**Dimension 5: Signal Integrity (weight 0.20)**
+- Event Presence: Are all storyline events visible in the logs?
+- Indicator Accuracy: Do traces carry the correct IPs, usernames, hostnames?
+- Pivot Linkability: Can a hunter pivot between consecutive attack steps?
+- Temporal Integrity: Are attack events in the right order at the right times?
+
+### Step 4: Qualitative Record Review
+
+Sample ~10 records from the output directory across different formats. Read them and assess:
+
+1. **Record Realism** — Do individual records look like they came from a real system? Flag anything that looks synthetic, implausible, or templated.
+2. **Narrative Coherence** — Read 15-20 events around a storyline step. Does the sequence tell a coherent story? Any gaps or contradictions?
+3. **Hunting Feasibility** — Given the scenario description and data, could a hunter realistically discover this attack? What approach would work? What obstacles exist?
+
+Present these as qualitative observations, clearly separated from the numeric scores.
+
+### Step 5: Suggest Improvements
+
+For any sub-score below 70, provide specific, actionable suggestions:
+
+| Common Issue | Suggestion |
+|-------------|-----------|
+| Low parsability | Check for empty required fields in the generator (e.g., empty SIDs) |
+| Low volume adequacy | Increase `baseline_activity.intensity` or add more users/systems |
+| Low user diversity | Add more persona types with different work patterns and activities |
+| Low burstiness | Known generator limitation — events are near-uniformly distributed |
+| Low work hour distribution | Check persona work_hours definitions; may need off-hours event generation |
+| Low anomaly rate | Generator may need more variation in baseline (failed logons, errors) |
+
+If multiple issues trace back to the same root cause (e.g., generator limitations), group them and explain the root cause once.
+
+### Step 6: Acceptance Criteria
+
+Report whether hard acceptance criteria pass or fail:
+- Parsability ≥ 98%
+- Source Correctness ≥ 95%
+- Causal Ordering ≥ 99%
+- Event Presence ≥ 90%
+
+If any hard criterion fails, explain what would need to change to pass.
+
+## Command Reference
+
+```
+eforge eval <output_dir> --scenario <scenario.yaml> [--format json|text] [--verbose]
+```
+
+- `--format text` (default): Rich terminal output with colored scores
+- `--format json`: Machine-readable JSON (status messages go to stderr)
+- `--verbose`: Show sample failures and detailed sub-score information

src/evidenceforge/cli/install_skills.py

@@ -13,6 +13,7 @@
     "scenario.md",
     "generate.md",
     "validate.md",
+    "evaluate.md",
 ]
 
 REFERENCE_FILES = [