@sienklogic/plan-build-run 2.1.0 → 2.1.1

package/plugins/cursor-pbr/templates/project-CONTEXT.md.tmpl

@@ -0,0 +1,43 @@
+# Project Context
+
+> Cross-cutting decisions that ALL phases must honor.
+> Updated via `/pbr:discuss-phase --project`. Auto-synced to CLAUDE.md on write.
+> Phase-level CONTEXT.md (in phase directories) overrides project-level for that phase.
+>
+> PLANNER NOTE: Embed each locked decision directly into the relevant task's action block.
+> Executors NEVER read this file — PLAN.md is self-contained.
+
+## Locked Decisions
+
+Technology choices, architecture decisions, and constraints that are NON-NEGOTIABLE across ALL phases.
+The planner embeds these into PLAN.md task actions. Executors never read this file directly.
+
+| Decision | Rationale | Locked By |
+|----------|-----------|-----------|
+| {e.g., "Use TypeScript strict mode"} | {User preference, team skill} | User |
+| {e.g., "PostgreSQL via Supabase"} | {Existing infrastructure} | User |
+
+## User Constraints
+
+Budget, timeline, skill level, hosting, team size — factors that shape ALL planning decisions.
+
+- {e.g., "Solo developer, no team"}
+- {e.g., "Deploy to Hetzner VPS"}
+- {e.g., "Must work offline"}
+
+## Deferred Ideas
+
+Ideas explicitly moved to v2 or ruled out. Plans at ANY phase MUST NOT include these.
+
+| Idea | Reason Deferred |
+|------|----------------|
+| {feature} | {reason — e.g., "Post-launch priority"} |
+
+## Claude's Discretion Areas
+
+Areas where planners can make implementation choices without asking the user.
+Document the choice made and rationale when exercised.
+
+| Area | Choice Made | Rationale |
+|------|------------|-----------|
+| {e.g., "Logging library"} | {e.g., "pino"} | {e.g., "Lightweight, structured output"} |

package/plugins/cursor-pbr/templates/prompt-partials/phase-project-context.md.tmpl

@@ -1,4 +1,3 @@
-<!-- canonical: ../../../pbr/templates/prompt-partials/phase-project-context.md.tmpl -->
 <!-- Source: templates/prompt-partials/ | Purpose: Shared context blocks for agent prompt templates -->
 <!-- Usage: Read this file and fill in placeholders, then include the result in agent prompts. -->
 <!-- Orchestrators should omit sections that don't apply to their agent type. -->

package/plugins/cursor-pbr/templates/research-outputs/ARCHITECTURE.md.tmpl

@@ -0,0 +1,91 @@
+<!-- Downstream consumers:
+  - Synthesizer agent: merges architecture findings into SUMMARY.md. Needs: component list, pattern names, data flow summary.
+  - Planner agent: uses architecture for phase dependency ordering. Needs: component dependencies, build order implications, API contract shapes.
+  - Build skill: uses architecture patterns during implementation. Needs: specific patterns tied to the chosen stack, anti-patterns to avoid.
+  Breaks if missing: Planner creates phases with wrong dependency order; build agents implement without architectural guidance.
+-->
+# Architecture Research
+
+**Researched:** {date}
+**Domain:** {domain}
+**Confidence:** {confidence}
+
+## System Architecture
+
+{High-level overview of the system architecture and its major components.}
+
+## Component Diagram
+
+```
+{text_based_component_diagram}
+```
+
+### Component Responsibilities
+
+| Component | Responsibility | Depends On |
+|-----------|----------------|------------|
+| {component} | {responsibility} | {dependencies} |
+
+## Data Flow
+
+### Primary Data Flow
+
+```
+{text_based_data_flow_diagram}
+```
+
+### Key Data Paths
+
+1. **{path_name}:** {description_of_data_flow}
+
+## API Contracts
+
+### {API Endpoint or Interface}
+
+**Request:**
+```
+{request_shape}
+```
+
+**Response:**
+```
+{response_shape}
+```
+
+**Error cases:** {error_description}
+
+## Architecture Patterns
+
+| Pattern | Where Used | Why |
+|---------|-----------|-----|
+| {pattern_name} | {component_or_layer} | {rationale} |
+
+### Pattern Details
+
+#### {Pattern Name}
+
+**What:** {description}
+**When to use:** {conditions}
+**Trade-offs:** {pros_and_cons}
+
+## Anti-Patterns to Avoid
+
+1. **{anti_pattern_name}**
+   - **What people do:** {mistake}
+   - **Why it fails:** {problem}
+   - **Do instead:** {correct_approach}
+
+## Quality Gates
+
+- [ ] Architecture patterns are specific to the chosen stack (not generic advice)
+- [ ] Data flow covers all major paths (happy path, error path, async flows)
+- [ ] API contracts include request shape, response shape, and error cases
+- [ ] Component diagram shows all major components and their connections
+- [ ] At least 2 anti-patterns documented with concrete alternatives
+- [ ] Sources include at least one official documentation or architecture guide reference
+
+## Sources
+
+| # | Type | URL/Description | Confidence |
+|---|------|----------------|------------|
+| S1 | {type} | {url_or_description} | {HIGH/MEDIUM/LOW} |

package/plugins/cursor-pbr/templates/research-outputs/FEATURES.md.tmpl

@@ -0,0 +1,64 @@
+<!-- Downstream consumers:
+  - Synthesizer agent: merges feature findings into SUMMARY.md. Needs: categorized feature list with priorities and effort estimates.
+  - Planner agent: uses feature priorities for requirement prioritization and phase scoping. Needs: must-have/should-have/defer categorization, effort estimates.
+  - Begin skill: presents feature inventory to user for scope discussion. Needs: clear feature descriptions with competitive context.
+  Breaks if missing: Planner scopes phases without feature priority data; synthesizer produces SUMMARY with no feature guidance.
+-->
+# Features Research
+
+**Researched:** {date}
+**Domain:** {domain}
+**Confidence:** {confidence}
+
+## Feature Inventory
+
+| Feature | Category | Priority | Effort | Description |
+|---------|----------|----------|--------|-------------|
+| {feature} | {category} | {must-have/should-have/defer} | {S/M/L/XL} | {brief_description} |
+
+## Competitive Analysis
+
+| Feature | Our Approach | Alternative 1 | Alternative 2 | Tradeoff |
+|---------|-------------|---------------|---------------|----------|
+| {feature} | {our_approach} | {alt_1} | {alt_2} | {tradeoff_analysis} |
+
+## Prioritization Rationale
+
+### Must-Have (table stakes)
+
+{Features users expect as baseline. Without these, the product is not viable.}
+
+- **{feature}:** {why_must_have}
+
+### Should-Have (competitive)
+
+{Features that differentiate from alternatives. Important but not blocking launch.}
+
+- **{feature}:** {why_should_have}
+
+### Defer (v2+)
+
+{Features explicitly excluded from initial scope with rationale.}
+
+- **{feature}:** {why_defer}
+
+## Deferred Features
+
+| Feature | Reason Deferred | Revisit When | Effort if Added Later |
+|---------|----------------|--------------|----------------------|
+| {feature} | {reason} | {trigger} | {effort_estimate} |
+
+## Quality Gates
+
+- [ ] Every feature categorized as must-have, should-have, or defer
+- [ ] Effort estimates present for all features (S/M/L/XL)
+- [ ] Competitive analysis has at least 2 alternatives per major feature
+- [ ] Must-have features have clear rationale for why they are table stakes
+- [ ] Deferred features include revisit triggers
+- [ ] Sources include at least one market or user research reference
+
+## Sources
+
+| # | Type | URL/Description | Confidence |
+|---|------|----------------|------------|
+| S1 | {type} | {url_or_description} | {HIGH/MEDIUM/LOW} |

package/plugins/cursor-pbr/templates/research-outputs/PITFALLS.md.tmpl

@@ -0,0 +1,50 @@
+<!-- Downstream consumers:
+  - Synthesizer agent: merges pitfall findings into SUMMARY.md. Needs: numbered pitfalls with severity and avoidance strategies.
+  - Planner agent: reads pitfalls to add defensive verification steps to plans. Needs: specific, actionable avoidance strategies.
+  - Build skill: uses avoidance strategies during implementation. Needs: detection methods to catch pitfalls early.
+  Breaks if missing: Plans lack defensive verification; synthesizer produces SUMMARY with no risk awareness.
+-->
+# Pitfalls Research
+
+**Researched:** {date}
+**Domain:** {domain}
+**Confidence:** {confidence}
+
+## Critical Pitfalls
+
+{Pitfalls that cause project failure or major rework if not avoided.}
+
+1. **{pitfall_name}** [{source}]
+   - **Impact:** {what_goes_wrong}
+   - **Root cause:** {why_it_happens}
+   - **Avoidance:** {specific_steps_to_prevent}
+   - **Detection:** {how_to_catch_early}
+
+## Common Mistakes
+
+{Mistakes that cause delays but are recoverable.}
+
+1. **{mistake_name}** [{source}]
+   - **Impact:** {what_goes_wrong}
+   - **Avoidance:** {what_to_do_instead}
+
+## Environment-Specific Gotchas
+
+| Environment | Gotcha | Workaround |
+|-------------|--------|------------|
+| {env} | {issue} | {fix} |
+
+## Quality Gates
+
+- [ ] At least 3 critical pitfalls identified with source attribution
+- [ ] Each critical pitfall has a concrete avoidance strategy (not "be careful")
+- [ ] Each critical pitfall has a detection method
+- [ ] Environment-specific gotchas checked for target platform
+- [ ] Common mistakes section has at least 2 entries
+- [ ] Sources include at least one official documentation reference
+
+## Sources
+
+| # | Type | URL/Description | Confidence |
+|---|------|----------------|------------|
+| S1 | {type} | {url_or_description} | {HIGH/MEDIUM/LOW} |

package/plugins/cursor-pbr/templates/research-outputs/STACK.md.tmpl

@@ -0,0 +1,63 @@
+<!-- Downstream consumers:
+  - Synthesizer agent: merges stack findings into SUMMARY.md. Needs: technology table with versions and rationale, confidence levels per recommendation.
+  - Planner agent: uses stack decisions for phase planning and dependency ordering. Needs: prescriptive technology choices (not "consider X or Y"), version numbers, package manager.
+  - Dashboard ResearchTab: displays research confidence. Needs: frontmatter confidence field.
+  Breaks if missing: Synthesizer produces SUMMARY with vague stack section; planner makes technology decisions without research backing.
+-->
+# Stack Research
+
+**Researched:** {date}
+**Domain:** {domain}
+**Confidence:** {confidence}
+
+## Core Stack
+
+| Technology | Version | Purpose | Why Standard |
+|------------|---------|---------|--------------|
+| {technology} | {version} | {purpose} | {rationale} |
+
+## Supporting Tools
+
+| Tool | Version | Purpose | When to Use |
+|------|---------|---------|-------------|
+| {tool} | {version} | {purpose} | {use_case} |
+
+## Package Manager
+
+**Recommended:** {package_manager}
+**Why:** {rationale}
+
+## Deployment Target
+
+| Property | Value | Notes |
+|----------|-------|-------|
+| Platform | {platform} | {notes} |
+| Hosting | {hosting} | {notes} |
+| CI/CD | {ci_cd} | {notes} |
+
+## Alternatives Considered
+
+| Recommended | Alternative | Why Not |
+|-------------|-------------|---------|
+| {our_choice} | {alternative} | {rejection_reason} |
+
+## Version Compatibility
+
+| Package A | Compatible With | Notes |
+|-----------|-----------------|-------|
+| {package_a} | {package_b} | {compatibility_notes} |
+
+## Quality Gates
+
+- [ ] All technology recommendations are prescriptive ("Use X") not exploratory ("Consider X or Y")
+- [ ] Every technology entry has a specific version number (not "latest")
+- [ ] Core stack table has at least 3 entries
+- [ ] Alternatives Considered table documents at least 2 rejected alternatives with rationale
+- [ ] Package manager recommendation includes rationale
+- [ ] Sources include at least one official documentation reference
+
+## Sources
+
+| # | Type | URL/Description | Confidence |
+|---|------|----------------|------------|
+| S1 | {type} | {url_or_description} | {HIGH/MEDIUM/LOW} |

package/plugins/cursor-pbr/templates/research-outputs/SUMMARY.md.tmpl

@@ -0,0 +1,98 @@
+<!-- Downstream consumers:
+  - Planner agent (primary consumer): reads SUMMARY.md for all phase planning decisions. Needs: stack recommendation, architecture recommendation, key risks, feature priorities, confidence assessment.
+  - Begin skill: presents synthesis to user for approval before roadmap creation. Needs: executive summary, consolidated recommendations.
+  - Dashboard ResearchTab: displays synthesis with confidence levels. Needs: confidence assessment table, research coverage.
+  Breaks if missing: Planner makes phase decisions without research backing; user approves roadmap without seeing synthesis; dashboard shows empty research card.
+-->
+# Research Synthesis
+
+**Synthesized:** {date}
+**Input documents:** {count}
+**Confidence:** {overall_confidence}
+
+## Executive Summary
+
+{Unified findings across all research dimensions in under 200 words. State: what was researched, key conclusions, primary recommendation, and confidence level.}
+
+## Stack Recommendation
+
+**Recommended stack:** {one_line_summary}
+
+{Key technology choices with rationale, sourced from STACK research.}
+
+- **{technology}:** {version} -- {why_chosen}
+
+## Architecture Recommendation
+
+**Recommended pattern:** {pattern_name}
+
+{Architecture approach with component overview, sourced from ARCHITECTURE research.}
+
+- **{component}:** {responsibility}
+
+## Key Risks
+
+{Top risks from PITFALLS research, ordered by impact.}
+
+1. **{risk}** -- {mitigation}
+2. **{risk}** -- {mitigation}
+3. **{risk}** -- {mitigation}
+
+## Feature Priorities
+
+{Prioritized feature summary from FEATURES research.}
+
+**Must-have:** {must_have_features}
+**Should-have:** {should_have_features}
+**Deferred:** {deferred_features}
+
+## Consolidated Recommendations
+
+{Actionable recommendations that integrate findings across all dimensions.}
+
+1. {recommendation}
+2. {recommendation}
+3. {recommendation}
+
+## Confidence Assessment
+
+| Dimension | Confidence | Gaps |
+|-----------|------------|------|
+| Stack | {HIGH/MEDIUM/LOW} | {gaps_or_none} |
+| Features | {HIGH/MEDIUM/LOW} | {gaps_or_none} |
+| Architecture | {HIGH/MEDIUM/LOW} | {gaps_or_none} |
+| Pitfalls | {HIGH/MEDIUM/LOW} | {gaps_or_none} |
+
+**Overall confidence:** {confidence}
+
+## Research Coverage
+
+| Dimension | Status | Notes |
+|-----------|--------|-------|
+| Stack | {COMPLETE/PARTIAL/MISSING} | {notes} |
+| Features | {COMPLETE/PARTIAL/MISSING} | {notes} |
+| Architecture | {COMPLETE/PARTIAL/MISSING} | {notes} |
+| Pitfalls | {COMPLETE/PARTIAL/MISSING} | {notes} |
+
+**Dimensions researched:** {count}/4
+**Gaps requiring attention:** {list_or_none}
+
+## Quality Gates
+
+- [ ] Executive summary is under 200 words
+- [ ] All 4 research dimensions referenced (Stack, Features, Architecture, Pitfalls)
+- [ ] Confidence gaps explicitly listed for each dimension
+- [ ] Recommendations are prescriptive and actionable (not "consider" or "evaluate")
+- [ ] Partial failure handled -- missing dimensions noted, not silently omitted
+- [ ] Sources consolidated from all input documents
+
+## Sources
+
+### Primary (HIGH confidence)
+- {source}
+
+### Secondary (MEDIUM confidence)
+- {source}
+
+### Tertiary (LOW confidence)
+- {source}

package/plugins/pbr/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "pbr",
-  "version": "2.0.0",
+  "version": "2.1.1",
   "description": "Plan-Build-Run — Structured development workflow for Claude Code. Solves context rot through disciplined subagent delegation, structured planning, atomic execution, and goal-backward verification.",
   "author": {
     "name": "SienkLogic",
@@ -9,5 +9,10 @@
   "homepage": "https://github.com/SienkLogic/plan-build-run",
   "repository": "https://github.com/SienkLogic/plan-build-run",
   "license": "MIT",
-  "keywords": ["claude-code", "context-engineering", "development-workflow", "subagent-delegation"]
+  "keywords": [
+    "claude-code",
+    "context-engineering",
+    "development-workflow",
+    "subagent-delegation"
+  ]
 }

package/plugins/pbr/UI-CONSISTENCY-GAPS.md

@@ -30,7 +30,7 @@ Tracks remaining gaps found after initial UI consistency pass.
 
 | # | Skill | Issue | Status |
 |---|-------|-------|--------|
-| 3.1 | build | References ui-formatting.md templates but never shows banner inline | DONE |
+| 3.1 | build | References ui-brand.md templates but never shows banner inline | DONE |
 | 3.2 | discuss | No completion banner at all | DONE |
 | 3.3 | debug | No banner for resolved case | DONE |
 | 3.4 | todo | Plain `✓` lines, no branded banner | DONE |

package/plugins/pbr/agents/audit.md

@@ -0,0 +1,247 @@
+---
+name: audit
+color: "#8B5CF6"
+description: "Analyzes Claude Code session logs for PBR workflow compliance, hook firing, state file hygiene, and user experience quality."
+memory: none
+tools:
+  - Read
+  - Bash
+  - Glob
+  - Grep
+  - Write
+---
+
+<files_to_read>
+CRITICAL: If your spawn prompt contains a files_to_read block,
+you MUST Read every listed file BEFORE any other action.
+Skipping this causes hallucinated context and broken output.
+</files_to_read>
+
+> Default files: session JSONL path provided in spawn prompt
+
+# Plan-Build-Run Session Auditor
+
+<role>
+You are **audit**, the session analysis agent for the Plan-Build-Run development system. You analyze Claude Code session JSONL logs to evaluate PBR workflow compliance, hook firing, state management, commit discipline, and user experience quality.
+
+## Core Principle
+
+Evidence over assumption. Every finding must cite specific JSONL line numbers, timestamps, or tool call IDs. Never infer hook behavior without evidence — absent evidence means "no evidence found," not "hooks didn't fire."
+</role>
+
+<upstream_input>
+## Upstream Input
+
+### From `/pbr:audit` Skill
+
+- **Spawned by:** `/pbr:audit` skill
+- **Receives:** Session JSONL path, optional subagent log paths, audit mode (`compliance`|`ux`|`full`), output path
+- **Input format:** Spawn prompt with file paths and mode directive
+</upstream_input>
+
+## JSONL Format
+
+Session logs are newline-delimited JSON. Key entry types:
+
+| Field | Values | Meaning |
+|-------|--------|---------|
+| `type` | `user`, `assistant`, `progress` | Entry type |
+| `message.role` | `human`, `assistant` | Who sent it |
+| `data.type` | `hook_progress` | Hook execution evidence |
+| `data.hookEvent` | `SessionStart`, `PreToolUse`, `PostToolUse`, etc. | Which hook event |
+| `timestamp` | ISO 8601 | When it occurred |
+| `sessionId` | UUID | Session identifier |
+
+User messages contain the actual commands (`/pbr:execute-phase`, `/pbr:quick`, etc.) and freeform instructions.
+
+<execution_flow>
+## Audit Process
+
+<step name="load-session">
+### Step 1: Load Session
+
+Locate and read the JSONL session file. Assess size with `wc -l`. For large files (>1MB), read in chunks using `offset` and `limit` on Read tool, or sample key sections. Focus on user messages (`"role": "human"`), tool calls, and hook progress entries.
+</step>
+
+<step name="compliance-audit">
+### Step 2: Compliance Audit
+
+Run the 8 compliance checks:
+
+#### 2.1 PBR Commands Used
+- Extract all `/pbr:*` command invocations from user messages
+- Was the command sequence logical? (e.g., plan before build, build before review)
+- Were there commands that SHOULD have been used but weren't?
+
+#### 2.2 STATE.md Lifecycle
+- Was STATE.md read before starting work?
+- Was STATE.md updated at phase transitions?
+- After context compaction/continuation, was STATE.md re-read?
+
+#### 2.3 ROADMAP.md Consultation
+- Was ROADMAP.md read during build, plan, or milestone operations?
+
+#### 2.4 SUMMARY.md Creation
+- After any build or quick task, was SUMMARY.md created?
+- Does it contain required frontmatter fields (`requires`, `key_files`, `deferred`)?
+
+#### 2.5 Hook Evidence
+- Are there `hook_progress` entries in the log?
+- Which hooks fired and how many times?
+- Were any hooks missing that should have fired?
+- If NO hook evidence exists, flag as HIGH severity
+
+#### 2.6 Commit Format
+- Extract all `git commit` commands from Bash tool calls
+- Verify format: `{type}({scope}): {description}`
+- Check for forbidden `Co-Authored-By` lines
+
+#### 2.7 Subagent Delegation
+- Was implementation work delegated to executor subagents?
+- Or was it done directly in main context (anti-pattern)?
+- Count tool calls in main context vs subagents
+
+#### 2.8 Active Skill Management
+- Was `.active-skill` written when skills were invoked?
+- Was it cleaned up when skills completed?
+</step>
+
+<step name="ux-audit">
+### Step 3: UX Audit
+
+Run the 5 UX checks:
+
+#### 3.1 User Intent vs Assistant Behavior
+- What did the user ask for? (Extract exact user messages)
+- Did the assistant deliver what was asked?
+- Did the user have to repeat instructions? (Escalation = frustration)
+- Count the number of course-corrections
+
+#### 3.2 Flow Choice Quality
+- Was the chosen PBR command the best fit for the task?
+- Would a different command have been more efficient?
+- Was the ceremony proportionate to the task scope?
+
+#### 3.3 Feedback and Progress
+- Were there progress updates during long operations?
+- Were CI results communicated clearly?
+- Were there silent gaps with no user feedback?
+
+#### 3.4 Handoff Quality
+- After skill completion, was the next step suggested?
+- Did the user know what to do next?
+
+#### 3.5 Context Efficiency
+- Did the session approach or hit context limits?
+- Was work delegated to subagents appropriately?
+- Were there unnecessary file reads burning context?
+</step>
+
+<step name="write-report">
+### Step 4: Write Report
+
+Produce the output report to the specified path using the Output Format template below.
+</step>
+</execution_flow>
+
+<downstream_consumer>
+## Downstream Consumers
+
+### User
+
+- **Produces:** `.planning/audits/{YYYY-MM-DD}-session-audit.md`
+- **Consumed by:** User (review), no downstream agent consumers
+- **Output contract:** Markdown report with Session Metadata, PBR Commands Invoked, Compliance Score, UX Score, Hook Firing Report, Commits Made, Issues Found (Critical/High/Medium/Low), Recommendations
+</downstream_consumer>
+
+<structured_returns>
+## Output Format
+
+Write findings to the specified output path using this structure:
+
+```markdown
+# PBR Session Audit
+
+## Session Metadata
+- **Session ID**: {id}
+- **Time Range**: {start} to {end}
+- **Duration**: {duration}
+- **Claude Code Version**: {version}
+- **Branch**: {branch}
+
+## PBR Commands Invoked
+| # | Command | Arguments | Timestamp |
+|---|---------|-----------|-----------|
+
+## Compliance Score
+| Category | Status | Details |
+|----------|--------|---------|
+
+## UX Score (if audit mode includes UX)
+| Dimension | Rating | Details |
+|-----------|--------|---------|
+
+## Hook Firing Report
+| Hook Event | Count | Notes |
+|------------|-------|-------|
+
+## Commits Made
+| Hash | Message | Format Valid? |
+|------|---------|---------------|
+
+## Issues Found
+### Critical
+### High
+### Medium
+### Low
+
+## Recommendations
+```
+
+## Completion Protocol
+
+CRITICAL: Your final output MUST end with exactly one completion marker.
+Orchestrators pattern-match on these markers to route results. Omitting causes silent failures.
+
+- `## AUDIT COMPLETE` - audit report written to .planning/audits/
+- `## AUDIT FAILED` - could not complete audit (no session logs found, unreadable JSONL)
+</structured_returns>
+
+## Context Budget
+
+- **Maximum**: use `agent_checkpoint_pct` from `.planning/config.json` (default 50, quality 65; only apply values above 50 when `context_window_tokens` >= 500000) — allocate half for reading logs, half for analysis and output
+- Large JSONL files (>1MB): Read in chunks using `offset` and `limit` on Read tool, or use Bash with `wc -l` to assess size first, then sample key sections
+- Focus on user messages (`"role": "human"`), tool calls, and hook progress entries
+- Skip verbose tool output content — focus on tool names and results
+
+### Context Quality Tiers
+
+| Budget Used | Tier | Behavior |
+|------------|------|----------|
+| 0-30% | PEAK | Explore freely, read broadly |
+| 30-{pct}% | GOOD | Be selective with reads (pct = agent_checkpoint_pct from config, default 50) |
+| 50-70% | DEGRADING | Write incrementally, skip non-essential |
+| 70%+ | POOR | Finish current task and return immediately |
+
+<anti_patterns>
+
+## Anti-Patterns
+
+1. DO NOT guess what hooks did — only report what the log evidence shows
+2. DO NOT read the entire JSONL if it exceeds 2000 lines — sample strategically
+3. DO NOT judge workflow violations without understanding the skill type (explore is read-only, doesn't need STATE.md updates)
+4. DO NOT fabricate timestamps or session IDs
+5. DO NOT include raw JSONL content in the output — summarize findings
+6. DO NOT over-report informational items as critical — use appropriate severity
+
+</anti_patterns>
+
+<success_criteria>
+- [ ] Session JSONL files located and read
+- [ ] Compliance checklist evaluated
+- [ ] UX checklist evaluated (if mode includes UX)
+- [ ] Hook firing patterns analyzed
+- [ ] Scores calculated with evidence
+- [ ] Report written with required sections
+- [ ] Completion marker returned
+</success_criteria>