morph-reviewer

name	morph-reviewer
description	Quality gate and validation layer for Morph tool outputs, focusing on safety, correctness, and appropriate tool usage.

Morph Reviewer

Quality gate and validation layer for Morph tool outputs, focusing on safety, correctness, and appropriate tool usage.

Purpose

Evaluate Morph tool results for quality, safety, correctness, and tool-choice fit. This skill acts as a post-execution reviewer, not a blocker. It helps identify when results need human review, when fallback should have been used, when the wrong Morph tool was chosen, or when additional validation is needed.

Plugin Capability Map

This plugin adds six practical Morph capabilities to Pi:

• existing-file editing through morph_fastapply
• local codebase exploration through warpgrep_codebase_search
• public GitHub source exploration through warpgrep_github_search
• browser automation for direct URLs through morph_browser_test_url
• PR-aware preview validation through morph_preview_test_pr
• session compaction through Morph compact integration

Tool Choice Baseline

Use this baseline when reviewing whether the chosen tool matched the task:

• Existing file, non-trivial edit -> morph_fastapply
• Existing file, tiny exact one-block replacement -> native edit
• Brand new file -> native write
• Local codebase question -> warpgrep_codebase_search
• Public GitHub source question -> warpgrep_github_search
• Direct URL or visible UI flow -> morph_browser_test_url
• PR preview with GitHub context -> morph_preview_test_pr
• Long session context reduction -> Morph compaction

When to Apply

• After morph_fastapply completes (especially without dry run)
• After warpgrep_codebase_search or warpgrep_github_search returns results
• After morph_browser_test_url or morph_preview_test_pr returns results
• After automatic Morph compaction runs
• When Morph tools fall back to native Pi tools
• Before committing changes made via Morph tools

Quick Review Checklist

After any Morph tool execution:

• Tool choice was appropriate for the task
• Input quality was sufficient (anchors, query, etc.)
• Output matches stated intent
• No unexpected side effects
• Safety considerations addressed
• Fallback was appropriate if triggered
• Changes are reversible or approved
• Tests should be run (if applicable)

Review Dimensions

FastApply Edit Quality

Check for:

1. Anchor Ambiguity

   • Were the anchors unique enough?
   • Could the edit have matched unintended locations?
   • Did the diff show exactly what was expected?

2. Completeness

   • Were all intended changes applied?
   • Did any changes get skipped due to poor anchors?
   • Are there related changes that should have been included?

3. Safety

   • Were critical code paths modified?
   • Did the edit touch authentication, authorization, or data validation?
   • Should this change have used dry run first?
   • Is this change reversible via git?

4. Correctness

   • Does the syntax look correct?
   • Are imports/dependencies still valid?
   • Did the edit preserve intended logic?
   • Are there obvious typos or formatting issues?

Red Flags:

• ❌ FastApply applied without dry run on unfamiliar files
• ❌ Diff shows unexpected changes beyond the stated intent
• ❌ Edit touched security-sensitive code without explicit user confirmation
• ❌ Anchor context was too generic (e.g., only // ... existing code ...)
• ❌ Multiple unrelated changes bundled into one FastApply call
• ❌ FastApply used for a brand new file (should use write)
• ❌ FastApply used for a tiny exact one-block change (native edit would be simpler)

Green Flags:

• ✅ Dry run was used first for scattered or large changes
• ✅ Diff matches the stated intent precisely
• ✅ Anchors include distinctive function/class signatures
• ✅ File was read before FastApply decision
• ✅ Appropriate tool choice (FastApply vs edit vs write)
• ✅ Changes are focused and cohesive

WarpGrep Search Quality

Check for:

1. Result Relevance

   • Do results actually answer the search query?
   • Are there false positives or irrelevant matches?
   • Did the search miss obvious relevant code?

2. Completeness

   • Should additional searches be run for related patterns?
   • Are there edge cases not covered by the search?
   • Did the search cover all relevant file types?

3. Interpretation

   • Was the search result interpreted correctly?
   • Are there nuances or context that were missed?
   • Should the actual files be read for deeper understanding?

Red Flags:

• ❌ WarpGrep result used without reading the actual files
• ❌ Search query was too vague or broad
• ❌ Results were assumed complete without validation
• ❌ WarpGrep used for exact file path lookup (should use native tools)
• ❌ Timeout occurred but no fallback was attempted

Green Flags:

• ✅ Search query was specific and well-targeted
• ✅ Results were validated by reading actual files
• ✅ Fallback to native tools when WarpGrep failed
• ✅ Multiple searches used to triangulate understanding
• ✅ Search results informed subsequent edits appropriately

Browser Validation Quality

Check for:

1. Tool Fit

   • Was morph_browser_test_url used for a direct URL or visible UI flow?
   • Was morph_preview_test_pr used when GitHub PR context and preview discovery were needed?
   • Should manual browser tools have been used instead due to missing credentials or preview integration?

2. Task Specificity

   • Was the browser task concrete enough to validate the intended behavior?
   • Did the result actually cover the user-visible flow in question?
   • Were important routes, buttons, or states skipped?

3. Artifacts and Evidence

   • Were recording artifacts available when needed?
   • Does the summary align with the visible artifacts and claimed result?
   • If the run failed, is the failure actionable and specific?

Red Flags:

• ❌ morph_browser_test_url used when the task was really PR-specific
• ❌ morph_preview_test_pr used without a meaningful PR-preview validation goal
• ❌ Browser result claimed success without validating the requested flow
• ❌ Missing credentials or preview deployment should have triggered fallback sooner
• ❌ Summary was too vague to support the conclusion

Green Flags:

• ✅ Tool choice matched the testing target precisely
• ✅ Browser task was concrete and user-visible
• ✅ Recording or artifact links support the conclusion
• ✅ Failures are actionable and clearly scoped
• ✅ Fallback to manual browser tools happened when Morph integration was unavailable

Compaction Quality

Check for:

1. Context Preservation

   • Was the current task context preserved?
   • Are recent decisions and constraints still present?
   • Is there enough context to continue the conversation?

2. Information Loss

   • Were important file contents removed?
   • Did tool outputs get pruned too aggressively?
   • Are there gaps that will cause confusion later?

3. Effectiveness

   • Did compaction actually reduce context size meaningfully?
   • Was the compaction ratio appropriate?
   • Should manual compaction have been used instead?

Red Flags:

• ❌ Compaction removed the current task description
• ❌ Recent file edits were pruned
• ❌ Critical tool outputs were lost
• ❌ Compaction happened too early (< 85% context usage)
• ❌ Compaction removed user constraints or requirements

Green Flags:

• ✅ Current task and recent context preserved
• ✅ Compaction triggered at appropriate threshold
• ✅ Meaningful context reduction achieved
• ✅ Fallback to Pi compaction when Morph failed
• ✅ Compaction query was specific to the task

Fallback Appropriateness

Check for:

1. Fallback Trigger

   • Was fallback triggered for the right reason?
   • Should Morph have been retried with adjustments?
   • Was the fallback tool choice appropriate?

2. Fallback Execution

   • Did the fallback tool succeed?
   • Was the result equivalent to what Morph would have produced?
   • Should the user be notified about the fallback?

Red Flags:

• ❌ Fallback used without attempting to fix the Morph call
• ❌ Same Morph call retried multiple times without adjustment
• ❌ Fallback tool was less appropriate than fixing the Morph call
• ❌ Silent fallback on critical operations

Green Flags:

• ✅ Morph call adjusted before falling back
• ✅ Fallback tool was appropriate for the task
• ✅ User was informed about fallback when relevant
• ✅ Fallback succeeded where Morph failed

Severity Scoring System

Critical (Score: 10)

Characteristics:

• Security vulnerabilities introduced
• Data loss possible
• Production system breakage
• Authentication/authorization bypassed

Action: Immediate rollback and fix required

Examples:

• FastApply removed authentication check
• Edit exposed sensitive credentials
• Compaction removed critical security context

High (Score: 7-9)

Characteristics:

• Core functionality broken
• Incorrect logic introduced
• Major performance degradation
• Unsafe code patterns

Action: Fix before proceeding

Examples:

• FastApply broke main user flow
• Search missed critical dependencies
• Edit introduced memory leak

Medium (Score: 4-6)

Characteristics:

• Non-critical features broken
• Poor code quality
• Incomplete changes
• Minor logic errors

Action: Fix soon, can proceed with caution

Examples:

• FastApply missed related changes
• Search returned incomplete results
• Edit has formatting issues

Low (Score: 1-3)

Characteristics:

• Cosmetic issues
• Minor inefficiencies
• Documentation gaps
• Style inconsistencies

Action: Fix when convenient

Examples:

• FastApply has minor formatting inconsistency
• Search could be more specific
• Edit missing code comment

None (Score: 0)

Characteristics:

• No issues found
• All checks passed
• High quality output

Action: Proceed with confidence

Automated Checks

FastApply Automated Checks

Syntax validation:

// Check if file parses without errors
try {
  parse(editedContent);
  return { valid: true };
} catch (error) {
  return { valid: false, error: error.message };
}

Anchor uniqueness:

// Count occurrences of anchor in file
const occurrences = countMatches(fileContent, anchorPattern);
if (occurrences > 1) {
  return { warning: "Anchor may be ambiguous" };
}

Change scope:

// Verify changes are within expected scope
const changedLines = diff.split('\n').filter(l => l.startsWith('+') || l.startsWith('-'));
if (changedLines.length > expectedLines * 1.5) {
  return { warning: "More changes than expected" };
}

WarpGrep Automated Checks

Result count validation:

// Check if results are reasonable
if (results.length === 0) {
  return { warning: "No results found, query may be too specific" };
}
if (results.length > 100) {
  return { warning: "Too many results, query may be too broad" };
}

File type coverage:

// Verify relevant file types are included
const fileTypes = results.map(r => r.file.split('.').pop());
const expectedTypes = ['js', 'jsx', 'ts', 'tsx'];
const missing = expectedTypes.filter(t => !fileTypes.includes(t));
if (missing.length > 0) {
  return { warning: `Missing file types: ${missing.join(', ')}` };
}

Review Actions

When to Flag for Human Review

Critical issues:

• Security-sensitive changes (auth, permissions, data validation)
• Destructive operations (file deletion, data removal)
• Production configuration changes
• Unexpected diff content
• Repeated Morph failures
• Compaction removed critical context

Process:

1. Stop execution
2. Present issue to user with severity score
3. Show specific concerns
4. Recommend action (rollback, fix, proceed with caution)
5. Wait for explicit user approval

When to Auto-Validate

Safe operations:

• Dry run previews (no actual changes)
• Read-only operations (search, inspection)
• Small, focused edits with good anchors
• Changes in test files or documentation
• Reversible local changes

Process:

1. Run automated checks
2. Verify all checks pass
3. Log validation for audit trail
4. Proceed automatically

When to Recommend Retry

Fixable issues:

• Anchor quality was poor
• Search query was too vague
• Compaction was too aggressive
• Fallback could have been avoided with better input

Process:

1. Identify specific issue
2. Suggest concrete improvement
3. Offer to retry with adjustment
4. Track retry attempts (max 2-3)

Example Review Reports

Example 1: FastApply Success

## FastApply Review: src/auth/login.ts

**Status:** ✅ PASS (Score: 0)
**Tool Choice:** Appropriate (large file, multiple locations)
**Anchor Quality:** Excellent (unique function signatures)
**Completeness:** All intended changes applied
**Safety:** No security concerns
**Correctness:** Syntax valid, logic preserved

**Recommendation:** Proceed with confidence. Run tests to verify.

Example 2: FastApply Warning

## FastApply Review: src/api/users.ts

**Status:** ⚠️ WARNING (Score: 5)
**Tool Choice:** Appropriate
**Anchor Quality:** Fair (could be more specific)
**Completeness:** Partial - missed related validation in line 89
**Safety:** ⚠️ Modified data validation logic
**Correctness:** Syntax valid

**Issues:**
- Anchor matched 2 locations (used first occurrence)
- Related validation logic not updated

**Recommendation:** 
1. Review diff carefully
2. Update validation logic at line 89
3. Run tests before committing

Example 3: FastApply Critical

## FastApply Review: src/auth/middleware.ts

**Status:** ❌ CRITICAL (Score: 10)
**Tool Choice:** Inappropriate (should have used dry run first)
**Anchor Quality:** Poor (generic markers)
**Completeness:** Unknown
**Safety:** 🚨 REMOVED AUTHENTICATION CHECK
**Correctness:** Syntax valid but logic broken

**Issues:**
- Line 45: Authentication check removed
- Line 67: Authorization bypass possible
- Security vulnerability introduced

**Recommendation:** 
🚨 IMMEDIATE ROLLBACK REQUIRED
1. Revert this change immediately
2. Review intended changes
3. Use dry run to preview
4. Ensure auth logic is preserved

Example 4: WarpGrep Review

## WarpGrep Review: Authentication Implementation

**Status:** ✅ PASS (Score: 0)
**Query Quality:** Excellent (specific and targeted)
**Result Relevance:** High (all results relevant)
**Completeness:** Good (covered main patterns)
**Interpretation:** Accurate

**Results:**
- Found 5 authentication implementations
- Covered middleware, hooks, and utilities
- No false positives

**Recommendation:** Results validated. Proceed with analysis.

Integration with Power User Skill

This skill complements morph-power-user:

• Power User: Strategic tool selection and execution
• Reviewer: Post-execution validation and quality gate

Combined workflow:

1. Power User guides tool selection and preparation
2. Execute Morph tool
3. Reviewer validates output quality
4. Proceed or adjust based on review

Issue Prioritization

Priority Matrix

Severity	Safety Impact	Action
Critical	High	Block & rollback
High	High	Block & fix
High	Low	Fix before merge
Medium	High	Fix before merge
Medium	Low	Fix soon
Low	Any	Fix when convenient

Escalation Path

1. Automated checks → Pass/warn/fail
2. Severity scoring → 0-10 scale
3. Safety assessment → High/low impact
4. Action determination → Block/fix/proceed
5. User notification → If score ≥ 7 or safety high

Configuration Awareness

This skill assumes:

• routing.fallbackToNativeTools: true for automatic fallback
• autoCompactEnabled: true for Morph-first compaction
• compactIncludeMarkers: true for compaction transparency

Adjust review criteria if user has different settings.

Success Metrics

• High-risk changes flagged for review: ✓
• Poor anchor quality identified: ✓
• Inappropriate tool usage detected: ✓
• Fallback appropriateness validated: ✓
• Search result quality assessed: ✓
• Compaction effectiveness evaluated: ✓
• Severity scored accurately: ✓
• Automated checks executed: ✓
• Issues prioritized correctly: ✓