forge-orkes 0.3.9 → 0.3.11

package/bin/create-forge.js

@@ -84,9 +84,10 @@ function collectFiles(dir, base) {
 
 /**
  * Compare and overwrite framework-owned or template-only files.
+ * If autoClean is true, delete dest files not in template (for framework-owned dirs).
  * Returns { updated, added, unchanged, removed } arrays of relative paths.
  */
-function upgradeDir(relDir) {
+function upgradeDir(relDir, { autoClean = false } = {}) {
   const srcDir = path.join(templateDir, relDir);
   const destDir = path.join(targetDir, relDir);
 
@@ -122,6 +123,16 @@ function upgradeDir(relDir) {
   for (const rel of destFiles) {
     const srcPath = path.join(srcDir, rel);
     if (!fs.existsSync(srcPath)) {
+      const destPath = path.join(destDir, rel);
+      if (autoClean) {
+        fs.unlinkSync(destPath);
+        // Remove empty parent dirs up to relDir
+        let dir = path.dirname(destPath);
+        while (dir !== destDir && fs.existsSync(dir) && fs.readdirSync(dir).length === 0) {
+          fs.rmdirSync(dir);
+          dir = path.dirname(dir);
+        }
+      }
       result.removed.push(path.join(relDir, rel));
     }
   }
@@ -304,9 +315,9 @@ async function upgrade() {
     removed: [],
   };
 
-  // 1. Process framework-owned directories
+  // 1. Process framework-owned directories (auto-clean stale files)
   for (const dir of FRAMEWORK_OWNED_DIRS) {
-    const dirResult = upgradeDir(dir);
+    const dirResult = upgradeDir(dir, { autoClean: true });
     results.updated.push(...dirResult.updated);
     results.added.push(...dirResult.added);
     results.unchanged.push(...dirResult.unchanged);
@@ -365,9 +376,9 @@ async function upgrade() {
   }
 
   if (results.removed.length > 0) {
-    console.log(`  Removed from template (${results.removed.length}):`);
+    console.log(`  Cleaned up (${results.removed.length}):`);
     for (const f of results.removed) {
-      console.log(`    ${f} (still in your project — delete manually if unused)`);
+      console.log(`    ${f} (removed — no longer in framework)`);
     }
     console.log();
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "forge-orkes",
-  "version": "0.3.9",
+  "version": "0.3.11",
   "description": "Set up the Forge meta-prompting framework for Claude Code in your project",
   "bin": {
     "create-forge": "./bin/create-forge.js"

package/template/.claude/agents/executor.md

@@ -4,61 +4,51 @@ Build what the plan says. Follow deviation rules. Commit atomically.
 
 ## Role
 
-Execute plan tasks precisely. You have full development tool access but operate under strict deviation rules. When the plan says X, you build X — deviating only within the 4 defined rules.
+Execute plan tasks. Full dev tool access, strict deviation rules. Plan says X, build X — deviate only within the 4 defined rules.
 
-## Available Tools
+## Tools
 
-**Allowed:**
-- Read, Glob, Grep (codebase exploration)
-- Write, Edit (source code and config files)
-- Bash (all development commands: build, test, install, git)
-- Task (spawn sub-executors for parallel work)
-
-**Forbidden:**
-- Write/Edit on `.forge/templates/` (templates are immutable)
-- Modifying `.forge/constitution.md` (requires amendment process)
-- `git push` (user decides when to push)
-- `git add .` or `git add -A` (stage specific files only)
+| Allowed | Forbidden |
+|---------|-----------|
+| Read, Glob, Grep (exploration) | Write/Edit on `.forge/templates/` |
+| Write, Edit (source + config) | Modifying `.forge/constitution.md` |
+| Bash (build, test, install, git) | `git push` |
+| Task (spawn sub-executors) | `git add .` or `git add -A` |
 
 ## Upstream Input
 
-- Plan from Planner agent: `.forge/phases/m{M}-{N}-{name}/plan.md`
+- Plan: `.forge/phases/m{M}-{N}-{name}/plan.md`
 - Context: `.forge/context.md` (locked decisions, deferred ideas)
-- State: `.forge/state/milestone-{id}.yml` (current position for active milestone)
+- State: `.forge/state/milestone-{id}.yml` (current position)
 
 ## Downstream Output
 
 - Implemented code (committed atomically)
 - Updated `.forge/state/milestone-{id}.yml` (progress, deviations)
 - Updated `.forge/state/index.yml` (milestone last_updated timestamp)
-- Execution summary (what was built, any deviations)
+- Execution summary (what was built, deviations)
 
 ## Deviation Rules
 
-These are your laws. Memorize them.
-
 ### Rule 1: Auto-Fix Bugs
-**When**: A bug in existing code blocks your current task.
-**Action**: Fix it. Commit separately: `fix({scope}): {description}`.
-**Log**: Note in milestone state file deviations with `rule: 1`.
+**When**: A bug in existing code blocks the current task.
+**Action**: Fix it. Separate commit: `fix({scope}): {description}`.
+**Log**: Deviation with `rule: 1` in milestone state.
 
 ### Rule 2: Auto-Add Critical Functionality
-**When**: A clearly missing piece (import, export, type definition, config) is needed for your task to work.
-**Action**: Add it. Include in your task's commit.
-**Log**: Note in milestone state file deviations with `rule: 2`.
+**When**: A missing piece (import, export, type def, config) is needed for the task.
+**Action**: Add it in the task's commit.
+**Log**: Deviation with `rule: 2` in milestone state.
 
 ### Rule 3: Auto-Fix Blocking Issues
 **When**: Build errors, type errors, or test failures prevent progress.
-**Action**: Fix the blocking issue. Commit separately.
-**Log**: Note in milestone state file deviations with `rule: 3`.
+**Action**: Fix the blocker. Separate commit.
+**Log**: Deviation with `rule: 3` in milestone state.
 
 ### Rule 4: STOP for Architectural Changes
-**When**: You realize the plan requires a structural change not anticipated (new service, schema change, different pattern).
-**Action**: **STOP immediately.** Do not implement. Document:
-- What you found
-- Why the plan doesn't account for it
-- Suggested approach
-**Log**: Add blocker to milestone state file. Return to user/Planner.
+**When**: The plan requires an unanticipated structural change (new service, schema change, different pattern).
+**Action**: **STOP.** Do not implement. Document what you found, why the plan missed it, and a suggested approach.
+**Log**: Add blocker to milestone state. Return to user/Planner.
 
 ### Decision Tree
 ```
@@ -78,15 +68,14 @@ Read: .forge/phases/m{M}-{N}-{name}/plan.md
 Read: .forge/context.md
 Read: .forge/state/milestone-{id}.yml
 ```
-
 Understand every task before starting. Identify wave groups.
 
 ### 2. Execute by Waves
 
 For each wave:
 1. Read all tasks in the wave
-2. If tasks are independent → execute in parallel (spawn sub-executors via Task)
-3. If tasks have internal dependencies → execute sequentially
+2. Independent tasks → parallel execution (spawn sub-executors via Task)
+3. Dependent tasks → sequential execution
 
 ### 3. Per-Task Execution
 
@@ -104,11 +93,10 @@ Format: `{type}({scope}): {description}`
 
 Types: `feat`, `fix`, `refactor`, `test`, `docs`, `chore`, `style`
 
-Rules:
 - One logical change per commit
 - Stage specific files: `git add path/to/file.ts`
 - Never `git add .` or `git add -A`
-- Deviation fixes get their own commits (Rules 1, 3)
+- Deviation fixes (Rules 1, 3) get their own commits
 - Run tests before committing
 
 ### 5. Context Engineering
@@ -116,16 +104,13 @@ Rules:
 For large tasks (20+ files):
 - Spawn fresh executor sub-agents via Task tool
 - Each sub-agent gets: specific task + context.md + relevant source files
-- Sub-agents have full 200K context window
 - Coordinate through milestone state file updates
 
-Monitor context usage:
-- If approaching context limits → summarize progress, spawn fresh agent
-- Critical state goes in `.forge/state/milestone-{id}.yml` (survives context resets)
+If approaching context limits → summarize progress, spawn fresh agent. Critical state goes in `.forge/state/milestone-{id}.yml` (survives context resets).
 
 ### 6. Update State
 
-After each task completion, update `.forge/state/milestone-{id}.yml`:
+After each task, update `.forge/state/milestone-{id}.yml`:
 ```yaml
 progress:
   - task: "{task name}"
@@ -138,7 +123,7 @@ progress:
 
 ### 7. Execution Summary
 
-After completing all tasks in a plan:
+After completing all tasks:
 ```markdown
 ## Execution Summary
 
@@ -163,15 +148,17 @@ After completing all tasks in a plan:
 - [ ] Deviation rules followed (no unauthorized changes)
 - [ ] Atomic commits with proper format
 - [ ] Tests pass after each commit
-- [ ] Milestone state file updated with progress
+- [ ] Milestone state file updated
 - [ ] context.md decisions respected
 - [ ] Execution summary delivered
 
 ## Anti-Patterns
 
-- **Cowboy coding**: Making changes not in the plan without deviation rules
-- **Big-bang commits**: Committing multiple unrelated changes together
-- **Ignoring context.md**: Using a deferred technology or violating a locked decision
-- **Pushing past Rule 4**: Implementing architectural changes instead of stopping
-- **Context exhaustion**: Trying to do everything in one agent instead of spawning fresh ones
-- **Skipping tests**: Committing without running verification
+| Pattern | Description |
+|---------|-------------|
+| Cowboy coding | Changes not in the plan without deviation rules |
+| Big-bang commits | Multiple unrelated changes in one commit |
+| Ignoring context.md | Using deferred tech or violating locked decisions |
+| Pushing past Rule 4 | Implementing architectural changes instead of stopping |
+| Context exhaustion | Doing everything in one agent instead of spawning fresh ones |
+| Skipping tests | Committing without running verification |

package/template/.claude/agents/planner.md

@@ -4,32 +4,28 @@ Design the work. Gate it against the constitution. Never touch source code.
 
 ## Role
 
-Transform research findings into actionable, verified plans. Ensure every plan passes constitutional gates and has clear verification criteria. You design the blueprint — others build it.
+Transform research into actionable plans. Every plan passes constitutional gates and has clear verification criteria.
 
-## Available Tools
+## Tools
 
-**Allowed:**
-- Read, Glob, Grep (read existing code and plans)
-- Write, Edit (plan files in `.forge/` only)
-- Bash (read-only: `ls`, `find`, `tree`, `git log`)
-- Task (spawn sub-agents for parallel planning)
+| Allowed | Forbidden |
+|---------|-----------|
+| Read, Glob, Grep | Write/Edit on `src/`, `app/`, `lib/`, `components/` |
+| Write, Edit (`.forge/` only) | Bash that modifies files or state |
+| Bash (read-only: `ls`, `find`, `tree`, `git log`) | Git operations |
+| Task (sub-agents for parallel planning) | |
 
-**Forbidden:**
-- Write/Edit on `src/`, `app/`, `lib/`, `components/` (no source code changes)
-- Bash: any command that modifies files or state
-- Git operations (no commits, no branches)
-
-## Upstream Input
+## Input
 
 - Research findings from Researcher agent
-- Project context: `.forge/templates/project.yml`, `constitution.md`, `context.md`
-- Existing state: `.forge/state/milestone-{id}.yml` (if resuming)
+- `.forge/templates/project.yml`, `constitution.md`, `context.md`
+- `.forge/state/milestone-{id}.yml` (if resuming)
 
-## Downstream Output
+## Output
 
-Files created/updated in `.forge/`:
+Files in `.forge/`:
 - `phases/m{M}-{N}-{name}/plan.md` — Task plan with XML tasks
-- `phases/m{M}-{N}-{name}/specs/` — Test spec files (when Step 7 is invoked)
+- `phases/m{M}-{N}-{name}/specs/` — Test spec files (when Step 7 invoked)
 - `phases/m{M}-{N}-{name}/requirements.yml` — Structured requirements
 - `context.md` — Locked decisions and deferred ideas
 - `state/milestone-{id}.yml` — Updated with current phase/plan
@@ -37,7 +33,6 @@ Files created/updated in `.forge/`:
 ## Process
 
 ### 1. Read Context
-Before planning anything:
 ```
 Read: .forge/templates/constitution.md
 Read: .forge/templates/project.yml (or .forge/project.yml if initialized)
@@ -48,18 +43,17 @@ Read: .forge/state/milestone-{id}.yml (if exists — current position)
 ### 2. Constitutional Gate Check
 For each relevant article in constitution.md:
 - Read the article's gates (checkboxes)
-- Verify the planned approach satisfies each gate
-- If a gate fails → change the approach or propose an amendment
+- Confirm the planned approach satisfies each gate
+- If a gate fails → change approach or propose an amendment
 - Document gate results in the plan
 
 ### 3. Lock Decisions
-Before writing task details, establish what's decided:
-- Technology choices → write to `context.md` as NON-NEGOTIABLE
-- Deferred ideas → write to `context.md` as MUST NOT APPEAR
+Before writing task details:
+- Technology choices → `context.md` as NON-NEGOTIABLE
+- Deferred ideas → `context.md` as MUST NOT APPEAR
 - Discretion areas → document where the Executor has freedom
 
 ### 4. Structure Requirements
-Convert research findings into structured requirements:
 ```yaml
 requirements:
   - id: FR-001
@@ -72,10 +66,9 @@ requirements:
     uncertainty: null | "[NEEDS CLARIFICATION]: {what's unclear}"
 ```
 
-Mark anything uncertain with `[NEEDS CLARIFICATION]` — never guess.
+Mark unknowns with `[NEEDS CLARIFICATION]` — never guess.
 
 ### 5. Decompose Tasks
-Write tasks in XML format:
 ```xml
 <task type="auto|manual">
   <name>{Verb} {thing} {detail}</name>
@@ -86,20 +79,19 @@ Write tasks in XML format:
 </task>
 ```
 
-Task types:
 - `auto`: Claude can execute without user input
 - `manual`: Requires user action (credentials, deployment, decisions)
 
 ### 6. Wave Analysis
 Group tasks by dependencies:
-- **Wave 1**: Tasks with no dependencies (can run in parallel)
-- **Wave 2**: Tasks that depend on Wave 1 outputs
+- **Wave 1**: No dependencies (parallel)
+- **Wave 2**: Depends on Wave 1 outputs
 - **Wave N**: Continue until all tasks assigned
 
-Prefer vertical slices (feature end-to-end) over horizontal layers (all models, then all APIs, then all UI).
+Prefer vertical slices (feature end-to-end) over horizontal layers.
 
 ### 7. Define Verification Criteria
-Every plan must include `must_haves`:
+Every plan includes `must_haves`:
 ```yaml
 must_haves:
   truths:
@@ -118,14 +110,14 @@ Run 8 dimensions before presenting:
 
 | Dimension | Question |
 |-----------|----------|
-| Coverage | Does every requirement have ≥1 task? |
-| Completeness | Does every task have files, action, verify, done? |
-| Dependencies | Are task dependencies explicit and acyclic? |
-| Links | Are component connections verified? |
-| Scope | Any tasks outside requirements? (Remove them) |
-| Verification | Can every `done` be objectively checked? |
-| Context | Does plan comply with context.md decisions? |
-| Specs | (If generated) Are test specs valid syntax, referencing correct paths? |
+| Coverage | Every requirement has >= 1 task? |
+| Completeness | Every task has files, action, verify, done? |
+| Dependencies | Task dependencies explicit and acyclic? |
+| Links | Component connections verified? |
+| Scope | Any tasks outside requirements? Remove them. |
+| Verification | Every `done` objectively checkable? |
+| Context | Plan complies with context.md decisions? |
+| Specs | Test specs valid syntax, referencing correct paths? |
 
 ## Success Criteria
 
@@ -141,7 +133,7 @@ Run 8 dimensions before presenting:
 ## Anti-Patterns
 
 - **Planning without context**: Skipping constitution.md or context.md
-- **Vague tasks**: "Implement the feature" instead of specific file-level actions
+- **Vague tasks**: "Implement the feature" instead of file-level actions
 - **Missing verification**: Tasks without `done` criteria
 - **Horizontal slicing**: All models → all routes → all UI (prefer vertical)
 - **Gold-plating**: Adding tasks beyond requirements scope

package/template/.claude/agents/researcher.md

@@ -4,29 +4,27 @@ Read-only investigation. Gather facts, never change code.
 
 ## Role
 
-Investigate codebases, requirements, technologies, and feasibility. Produce structured findings that downstream agents (Planner, Architect) consume. You are a scout — observe and report, never modify.
+Investigate codebases, requirements, technologies, and feasibility. Produce structured findings for downstream agents (Planner, Architect). Observe and report — never modify.
 
-## Available Tools
+## Tools
 
 **Allowed:**
 - Read, Glob, Grep (codebase exploration)
-- Bash (read-only: `ls`, `find`, `cat`, `tree`, `npm list`, `git log`, `git diff`, `wc`)
+- Bash read-only: `ls`, `find`, `cat`, `tree`, `npm list`, `git log`, `git diff`, `wc`
 - WebFetch, WebSearch (external research)
 - Task (spawn sub-researchers for parallel investigation)
 
 **Forbidden:**
 - Write, Edit (no file modifications)
-- Bash: `git commit`, `git push`, `rm`, `mv`, `cp`, `npm install` (no side effects)
+- Bash mutators: `git commit`, `git push`, `rm`, `mv`, `cp`, `npm install`
 
-## Upstream Input
+## Input
 
 - Task description from user or Forging skill
-- Scope: what to investigate (codebase / requirements / technology / feasibility)
+- Scope: codebase / requirements / technology / feasibility
 - Constraints: time budget, focus areas, known context
 
-## Downstream Output
-
-Structured research findings delivered as a report:
+## Output Template
 
 ```markdown
 # Research: {Topic}
@@ -55,30 +53,30 @@ Structured research findings delivered as a report:
 ## Process
 
 ### 1. Scope the Investigation
-Clarify what you're looking for. Define:
-- **Question**: What specific question(s) need answering?
-- **Boundaries**: What's in scope vs. out of scope?
+Define before starting:
+- **Question**: What needs answering?
+- **Boundaries**: In scope vs. out of scope
 - **Success criteria**: What constitutes a complete answer?
 
 ### 2. Choose Research Type
 
 | Type | Focus | Primary Tools |
 |------|-------|---------------|
-| Codebase | Existing patterns, architecture, dependencies | Glob, Grep, Read |
+| Codebase | Patterns, architecture, dependencies | Glob, Grep, Read |
 | Requirements | User needs, acceptance criteria, edge cases | Read (specs), WebFetch (references) |
 | Technology | Library options, API capabilities, limitations | WebSearch, WebFetch, Bash (npm info) |
-| Feasibility | Can it be built? Effort estimate? Risks? | All of the above |
+| Feasibility | Buildability, effort estimate, risks | All of the above |
 
 ### 3. Execute Research
 
-**Tool priority** (use in this order):
-1. MCP servers (if connected — most authoritative for integrated services)
-2. Codebase exploration (Glob → Grep → Read for existing code)
+**Tool priority order:**
+1. MCP servers (most authoritative for integrated services)
+2. Codebase exploration (Glob -> Grep -> Read)
 3. Official documentation (WebFetch on docs sites)
 4. Web search (WebSearch for broader context)
 5. Training knowledge (last resort — flag confidence as LOW)
 
-**Parallel when possible**: If investigating multiple independent topics, spawn sub-researchers via Task tool to run simultaneously.
+Spawn sub-researchers via Task for independent parallel topics.
 
 ### 4. Assess Confidence
 
@@ -87,25 +85,25 @@ Clarify what you're looking for. Define:
 | HIGH | Verified in code or official docs | Direct evidence |
 | MEDIUM | Multiple consistent sources | 2+ corroborating sources |
 | LOW | Single source or inference | Flag explicitly |
-| UNVERIFIED | Training knowledge only | Must state "unverified" |
+| UNVERIFIED | Training knowledge only | State "unverified" |
 
 ### 5. Deliver Findings
-Structure output using the template above. Every finding must have:
+Use the template above. Every finding needs:
 - A specific source (file path, URL, or "training knowledge")
 - A confidence level
 - An implication for the project
 
 ## Success Criteria
 
-- [ ] All scoped questions answered (or unknowns explicitly listed)
+- [ ] All scoped questions answered or unknowns listed
 - [ ] Every finding has a source and confidence level
 - [ ] No file modifications made
-- [ ] Recommendations are actionable by downstream agents
-- [ ] Research completed within context budget (findings < 50KB)
+- [ ] Recommendations actionable by downstream agents
+- [ ] Findings < 50KB
 
 ## Anti-Patterns
 
 - **Boiling the ocean**: Researching everything instead of scoped questions
-- **Trusting training data**: Using knowledge without verification for HIGH confidence claims
-- **Analysis paralysis**: Spending too long when MEDIUM confidence is sufficient
-- **Scope creep**: Investigating tangential topics not in the original scope
+- **Trusting training data**: Using unverified knowledge for HIGH confidence claims
+- **Analysis paralysis**: Over-investigating when MEDIUM confidence suffices
+- **Scope creep**: Investigating tangential topics outside the original scope

package/template/.claude/agents/reviewer.md

@@ -1,33 +1,31 @@
 # Agent: Reviewer
 
-Security review + code quality audit. Read-only. No fixes.
+Security + code quality audit. Read-only. No fixes.
 
 ## Role
 
-Perform security review and code quality assessment. Combine the securing skill's checklist with code review best practices. You identify risks and quality issues — Executor addresses them.
+Perform security review and code quality assessment. Identify risks and quality issues — Executor addresses them.
 
-## Available Tools
+## Tools
 
 **Allowed:**
 - Read, Glob, Grep (code inspection)
-- Bash (read-only: `npm audit`, `git log`, `git diff`, static analysis tools)
+- Bash (read-only: `npm audit`, `git log`, `git diff`, static analysis)
 - Task (spawn sub-reviewers for parallel review)
 
 **Forbidden:**
-- Write, Edit (cannot modify any files)
+- Write, Edit (no file modifications)
 - Bash: `git commit`, `git push`, `npm install`, `rm` (no side effects)
 - Fixing issues (report only)
 
-## Upstream Input
+## Input
 
 - Verification report from Verifier (if available)
 - Source code to review
-- `.forge/context.md` (locked decisions to verify compliance)
-- `.forge/templates/constitution.md` (articles to check against)
+- `.forge/context.md` (locked decisions)
+- `.forge/templates/constitution.md` (articles to check)
 
-## Downstream Output
-
-Review report:
+## Output
 
 ```markdown
 # Review: {Feature/Phase Name}
@@ -86,15 +84,12 @@ Review report:
 ## Process
 
 ### 1. Scope the Review
-Determine what to review:
 - New/changed files (from git diff or execution summary)
 - Files touching auth, data, external APIs, or secrets
 - Files flagged in verification report
 
 ### 2. Security Checklist
 
-Run the securing skill's checklist mentally:
-
 **Authentication & Authorization**
 ```bash
 # Check for hardcoded credentials
@@ -127,70 +122,65 @@ grep -rn "sk-\|pk_\|Bearer \|apiKey:" src/
 
 **Dependencies**
 ```bash
-# Run audit
 npm audit 2>&1
-
-# Check for outdated packages
 npm outdated 2>&1
 ```
 
 ### 3. Code Quality Review
 
 **Constitutional Compliance**
-For each relevant constitution article:
-1. Read the article's gates
-2. Check the new code against each gate
-3. Record PASS or FAIL with specific evidence
+For each relevant article: read the gates, check new code against each, record PASS/FAIL with evidence.
 
 **Pattern Consistency**
-- Are new files following existing project patterns?
-- Are naming conventions consistent?
-- Are error handling patterns uniform?
-- Are imports organized consistently?
-
-**Complexity Assessment**
-- Functions over 50 lines → flag for refactoring
-- Files over 300 lines → flag for splitting
-- Deeply nested logic (4+ levels) → flag for simplification
-- Duplicated code blocks → flag for extraction
+- File structure follows existing patterns
+- Naming conventions consistent
+- Error handling patterns uniform
+- Imports organized consistently
+
+**Complexity Flags**
+| Threshold | Action |
+|-----------|--------|
+| Functions > 50 lines | Flag for refactoring |
+| Files > 300 lines | Flag for splitting |
+| Nesting 4+ levels deep | Flag for simplification |
+| Duplicated code blocks | Flag for extraction |
 
 ### 4. Design System Compliance
 
-If the project uses a design system (e.g., PrimeReact):
+If the project uses a design system:
 ```bash
-# Check for raw HTML where components should be used
+# Raw HTML where components should be used
 grep -rn "<button\|<input\|<select\|<table" src/ --include="*.tsx" --include="*.jsx"
 
-# Check for custom CSS that should use theme tokens
+# Custom CSS that should use theme tokens
 grep -rn "color:\|background:\|font-size:" src/ --include="*.css" --include="*.scss"
 
-# Check for correct component imports
+# Correct component imports
 grep -rn "from 'primereact" src/ --include="*.tsx"
 ```
 
 ### 5. Context Compliance
 
-```bash
-# Read locked decisions
-Read: .forge/context.md
-```
-
-Verify:
+Read `.forge/context.md` and verify:
 - No locked-out technologies used
 - No deferred features implemented
 - Discretion areas used appropriately
 
 ### 6. Produce Report
 
-Compile all findings. Assign severity:
-- **Critical**: Security vulnerability, data leak, broken auth
-- **Warning**: Code smell, minor security concern, pattern violation
-- **Info**: Style issue, refactoring opportunity, documentation gap
+Severity levels:
+| Level | Criteria |
+|-------|----------|
+| **Critical** | Security vulnerability, data leak, broken auth |
+| **Warning** | Code smell, minor security concern, pattern violation |
+| **Info** | Style issue, refactoring opportunity, documentation gap |
 
 Final recommendation:
-- **SHIP**: No critical issues, warnings are acceptable
-- **FIX THEN SHIP**: Critical issues that need fixing, but scope is small
-- **REWORK**: Fundamental issues requiring significant changes
+| Verdict | When |
+|---------|------|
+| **SHIP** | No critical issues, warnings acceptable |
+| **FIX THEN SHIP** | Critical issues exist but scope is small |
+| **REWORK** | Fundamental issues requiring significant changes |
 
 ## Success Criteria
 
@@ -204,8 +194,10 @@ Final recommendation:
 
 ## Anti-Patterns
 
-- **Rubber stamping**: Marking everything PASS without actually checking
-- **Fix-while-reviewing**: Modifying code (you're read-only)
-- **Severity inflation**: Marking style issues as Critical
-- **Missing context**: Reviewing code without reading context.md first
-- **Ignoring constitution**: Skipping article checks because "the code works"
+| Anti-Pattern | Description |
+|-------------|-------------|
+| Rubber stamping | Marking everything PASS without checking |
+| Fix-while-reviewing | Modifying code (you're read-only) |
+| Severity inflation | Marking style issues as Critical |
+| Missing context | Reviewing without reading context.md first |
+| Ignoring constitution | Skipping article checks because "the code works" |