@pharaoh-so/mcp 0.3.14 → 0.3.16

package/skills/debt/SKILL.md

@@ -1,34 +0,0 @@
----
-name: debt
-prompt-name: find-tech-debt
-description: "Categorized technical debt report using Pharaoh knowledge graph. Four-step pro-tier workflow: dead code detection, duplicate logic discovery, undocumented complex functions via spec gaps, and volatile high-complexity module identification. Categorizes findings as DELETE, CONSOLIDATE, DOCUMENT, STABILIZE, or TEST — each with the specific function or file, effort estimate, and risk of ignoring."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["tech-debt", "dead-code", "consolidation", "pharaoh", "documentation", "volatility", "test-coverage"]}
----
-
-# Find Tech Debt
-
-Categorized technical debt report. Uses `find-tech-debt` — a 4-step pro-tier workflow that finds and categorizes every class of debt: dead code, duplicates, undocumented complexity, volatile modules, and untested functions. Requires Pro tools.
-
-## When to Use
-
-Invoke when asked to find technical debt, prioritize a cleanup sprint, or understand where the codebase has degraded. Use it before planning a refactoring effort or when the codebase has accumulated changes without systematic review.
-
-## Workflow
-
-1. Call `get_unused_code` for the target repository to find dead exports and orphaned functions.
-2. Call `get_consolidation_opportunities` for the target repository to find duplicated logic across modules.
-3. Call `get_vision_gaps` for the target repository to find undocumented complex functions and unimplemented specs.
-4. Call `get_codebase_map` for the target repository with `include_metrics` to find volatile and high-complexity modules.
-
-## Output
-
-Categorized findings with one entry per item:
-
-- **DELETE:** Dead code safe to remove (unreachable, no callers) — with function/file name, effort (small/medium/large), risk of ignoring
-- **CONSOLIDATE:** Duplicated logic that should be unified — with affected modules, effort, risk of ignoring
-- **DOCUMENT:** Complex functions lacking specs or documentation — with function name, complexity score, effort, risk of ignoring
-- **STABILIZE:** Volatile modules that change too often (likely fragile) — with volatility data, effort, risk of ignoring
-- **TEST:** High-complexity functions with no test coverage — with function name, complexity score, effort, risk of ignoring

package/skills/execute/SKILL.md

@@ -1,58 +0,0 @@
----
-name: execute
-prompt-name: execute-plan
-description: "Execute a written implementation plan with review checkpoints. Load plan, review critically, execute tasks sequentially with verification at each step. Stop and ask when blocked — never guess through ambiguity. Finish with branch completion workflow."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["execution", "implementation", "plan", "workflow", "development"]}
----
-
-# Execute Plan
-
-Load a written implementation plan, review it critically, then execute every task with verification at each step.
-
-## When to Use
-
-When you have a written plan (spec, PRD, checklist) and need to implement it systematically. The plan should already exist — use `pharaoh:brainstorm` first if it doesn't.
-
-## Process
-
-### Step 1: Load and Review
-
-1. Read the plan file completely
-2. Review critically — identify questions, concerns, or gaps
-3. If concerns exist: raise them with the user before starting
-4. If no concerns: proceed with execution
-
-### Step 2: Execute Tasks
-
-For each task in the plan:
-
-1. Mark as in-progress
-2. Follow each step exactly — plans should have bite-sized steps
-3. Run verifications as specified in the plan
-4. Mark as completed before moving to next task
-
-### Step 3: Complete
-
-After all tasks are verified:
-- Use `pharaoh:finish` to handle branch completion (merge, PR, or keep)
-
-## When to Stop
-
-**Stop executing immediately when:**
-- Hit a blocker (missing dependency, test failure, unclear instruction)
-- Plan has critical gaps preventing the next step
-- You don't understand an instruction
-- Verification fails repeatedly
-
-Ask for clarification rather than guessing. Don't force through blockers.
-
-## Iron Rules
-
-- Review the plan critically before starting — don't blindly follow a flawed plan
-- Follow plan steps exactly — don't improvise unless blocked
-- Don't skip verifications — they exist for a reason
-- Never start implementation on main/master without explicit user consent
-- When blocked, stop and ask — guessing creates more work than waiting

package/skills/explore/SKILL.md

@@ -1,33 +0,0 @@
----
-name: explore
-prompt-name: explore-module
-description: "Deep-dive into a single codebase module using Pharaoh knowledge graph. Four-step free-tier workflow: full structure with functions, exports, and complexity scores; blast radius of what depends on it; upstream and downstream dependency mapping; and related function discovery. Produces a module briefing with purpose, key functions, dependencies, risk areas, and external API surface."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["module-exploration", "architecture", "pharaoh", "dependencies", "complexity", "api-surface"]}
----
-
-# Explore Module
-
-Deep-dive into a single module. Uses `explore-module` — a 4-step free-tier workflow that surfaces a module's structure, what depends on it, how it connects to the rest of the codebase, and what related utilities exist. Produces a complete module briefing without reading files one at a time.
-
-## When to Use
-
-Invoke when asked to understand what a specific module does, before modifying it, or before writing code that will interact with it. Use it instead of opening files and reading them top to bottom.
-
-## Workflow
-
-1. Call `get_module_context` for the target module to see its full structure — files, functions, exports, and complexity scores.
-2. Call `get_blast_radius` for the target module to understand what depends on it and what it affects.
-3. Call `query_dependencies` for the target module to map its upstream and downstream connections.
-4. Call `search_functions` with key terms from the module name to discover related utilities and entry points.
-
-## Output
-
-A module briefing containing:
-- **Purpose:** what this module does, 1-2 sentences
-- **Key functions:** highest complexity or most-connected functions, with brief descriptions
-- **Dependencies:** what the module imports and what imports it
-- **Risk areas:** high-complexity functions, heavily-depended-on exports
-- **Entry points:** functions that serve as external API or are called from outside the module

package/skills/finish/SKILL.md

@@ -1,80 +0,0 @@
----
-name: finish
-prompt-name: finish-branch
-description: "Complete a development branch after implementation. Verify all tests pass, present structured options (merge locally, create PR, keep branch, or discard), execute the chosen workflow, and clean up worktrees. Never merge broken code or delete work without confirmation."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["git", "merge", "pull-request", "cleanup", "branch-management"]}
----
-
-# Finish Branch
-
-Guide completion of development work after implementation is done. Verify tests, present options, execute choice, clean up.
-
-## When to Use
-
-When implementation is complete and you need to decide how to integrate the work — merge, PR, keep, or discard.
-
-## Process
-
-### Step 1: Verify Tests
-
-Run the full test suite before presenting options.
-
-**If tests fail:** stop. Report failures. Do not proceed until tests pass.
-
-**If tests pass:** continue.
-
-### Step 2: Determine Base Branch
-
-Check what branch this work split from (typically `main` or `master`).
-
-### Step 3: Present Options
-
-Present exactly these 4 options:
-
-```
-Implementation complete. What would you like to do?
-
-1. Merge back to <base-branch> locally
-2. Push and create a Pull Request
-3. Keep the branch as-is (I'll handle it later)
-4. Discard this work
-
-Which option?
-```
-
-### Step 4: Execute Choice
-
-**Option 1 — Merge locally:**
-- Switch to base branch, pull latest, merge feature branch
-- Verify tests on merged result
-- Delete feature branch
-
-**Option 2 — Create PR:**
-- Push branch to remote
-- Create PR with summary and test plan
-- Keep worktree (may need it for review feedback)
-
-**Option 3 — Keep as-is:**
-- Report branch name and worktree path
-- Don't clean up anything
-
-**Option 4 — Discard:**
-- List what will be deleted (branch, commits, worktree)
-- Require typed "discard" confirmation before proceeding
-- Delete branch and clean up worktree
-
-### Step 5: Clean Up Worktree
-
-For Options 1 and 4: remove the worktree after completing the action.
-For Options 2 and 3: keep the worktree.
-
-## Iron Rules
-
-- Never proceed with failing tests
-- Never merge without verifying tests on the merged result
-- Never delete work without explicit confirmation
-- Never force-push without explicit request
-- Always present exactly 4 structured options — no open-ended questions

package/skills/health/SKILL.md

@@ -1,37 +0,0 @@
----
-name: health
-prompt-name: health-check
-description: "Full codebase health sweep using Pharaoh knowledge graph. Six-step pro-tier workflow: module map with metrics, dead code detection, test coverage gaps, duplicate logic, regression risk scoring, and spec drift analysis. Produces an A-F grade, top 5 risks, tech debt hotspots (high-complexity + low-coverage + high-volatility intersections), spec drift summary, and prioritized actions with effort estimates."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["health-check", "tech-debt", "architecture", "pharaoh", "test-coverage", "regression-risk", "spec-drift"]}
----
-
-# Health Check
-
-Full codebase health sweep. Uses `health-check` — a 6-step pro-tier workflow that grades the codebase A-F, surfaces the top risks, maps tech debt hotspots, checks spec alignment, and produces prioritized actions. Requires Pro tools.
-
-## When to Use
-
-Invoke when asked for a codebase health assessment, a technical debt overview, or a risk report. Use it at the start of a maintenance sprint, before a major refactor, or when the codebase has grown without systematic review.
-
-## Workflow
-
-1. Call `get_codebase_map` for the target repository with `include_metrics` to see all modules, their sizes, complexity, and volatility.
-2. Call `get_unused_code` for the target repository to find dead exports and orphaned functions.
-3. Call `get_test_coverage` for the target repository to identify modules and functions lacking tests.
-4. Call `get_consolidation_opportunities` for the target repository to find duplicated logic across modules.
-5. Call `get_regression_risk` for the target repository to assess which modules are most likely to break.
-6. Call `get_vision_gaps` for the target repository to check spec-vs-code drift.
-
-Iron law: Report what the data shows, not what you think should be true.
-
-## Output
-
-A health report containing:
-- **Overall grade (A-F):** based on dead code volume, test coverage, duplication, regression risk, and spec alignment
-- **Top 5 risks:** specific modules or functions, with data backing each risk
-- **Tech debt hotspots:** high-complexity + low-coverage + high-volatility intersections
-- **Spec drift:** what is specified but not built; what is built but not specified
-- **Prioritized actions:** ordered by impact, each with effort estimate (small / medium / large)

package/skills/investigate/SKILL.md

@@ -1,35 +0,0 @@
----
-name: investigate
-prompt-name: investigate-change
-description: "Full architectural context gathering before modifying a function, file, or module using Pharaoh knowledge graph. Four-step free-tier workflow: module structure, blast radius of downstream callers, related function discovery, and dependency mapping. Blocks code suggestions until all context is gathered. Produces an investigation report with structure, blast radius, related functions, dependency context, and risk assessment."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["investigation", "context-gathering", "blast-radius", "pharaoh", "architecture", "change-impact"]}
----
-
-# Investigate Change
-
-Gather full architectural context before modifying anything. Uses `investigate-change` — a 4-step free-tier workflow that maps the target's structure, blast radius, related functions, and dependency context before any code suggestions are made.
-
-## When to Use
-
-Invoke before modifying any function, file, or module — especially when the codebase is unfamiliar or when the change touches shared code. Use it to answer "what do I need to know before touching this?" without reading files one at a time.
-
-## Workflow
-
-1. Call `get_module_context` for the module containing the target to understand its structure and complexity.
-2. Call `get_blast_radius` for the target to see every downstream caller and affected module.
-3. Call `search_functions` for the target name to find related functions and potential naming conflicts.
-4. Call `query_dependencies` to map how the containing module connects to the rest of the codebase.
-
-Do NOT suggest any changes until all 4 queries complete.
-
-## Output
-
-An investigation report containing:
-- **Current structure:** what the target does and where it lives
-- **Blast radius:** every caller and module that would be affected by changes
-- **Related functions:** similar names or overlapping behavior, potential naming conflicts
-- **Dependency context:** how the module connects upstream and downstream
-- **Risk assessment:** safe to change vs. high-risk paths, with specific reasons

package/skills/onboard/SKILL.md

@@ -1,33 +0,0 @@
----
-name: onboard
-prompt-name: onboard-to-codebase
-description: "Quick codebase orientation using Pharaoh knowledge graph. Five-step workflow using only free-tier tools: full module map, deep-dive into the three largest modules, entry point discovery, critical path blast radius, and core data flow mapping. Produces an onboarding summary with module descriptions, entry points, data flow, and key functions to read first."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["onboarding", "codebase-orientation", "architecture", "pharaoh", "module-map", "entry-points"]}
----
-
-# Onboard to Codebase
-
-Quick orientation to an unfamiliar codebase. Uses `onboard-to-codebase` — a 5-step workflow using only free-tier Pharaoh tools to understand modules, entry points, data flow, and key functions without reading files one at a time.
-
-## When to Use
-
-Invoke at the start of any session with an unfamiliar repository, or when asked to understand how a codebase is structured before making changes. Use it instead of exploring files manually.
-
-## Workflow
-
-1. Call `get_codebase_map` for the target repository to see all modules and their relationships.
-2. For the 3 largest modules (by function count), call `get_module_context` to understand their internals.
-3. Call `search_functions` with broad terms like "main", "init", "start", "handler" to find entry points.
-4. Call `get_blast_radius` for the most-connected module to understand the critical path.
-5. Call `query_dependencies` between the two most-connected modules to understand the core data flow.
-
-## Output
-
-An onboarding summary containing:
-- **Module map:** what each module does, 1 sentence each
-- **Entry points:** where execution starts, with function names and file paths
-- **Core data flow:** how the main modules connect, with dependency directions
-- **Key functions to read first:** highest connectivity or most-depended-on functions, with brief descriptions

package/skills/orchestrate/SKILL.md

@@ -1,145 +0,0 @@
----
-name: orchestrate
-prompt-name: orchestrate-plan
-description: "Execute implementation plans by dispatching one subagent per task with two-stage review (spec compliance then code quality). Sequential task execution with quality gates. Controller stays in session, constructs focused context for each agent, never shares session history. Handles DONE/DONE_WITH_CONCERNS/NEEDS_CONTEXT/BLOCKED status protocol."
-version: 0.2.5
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["subagents", "orchestration", "plan-execution", "quality-gates", "spec-review", "code-review"]}
----
-
-# Orchestrate Plan Execution
-
-Execute a plan by dispatching a fresh subagent per task, with two-stage review after each: spec compliance first, then code quality. The controller (you) coordinates — subagents implement and review.
-
-## When to Use
-
-- You have a written implementation plan with 2+ tasks
-- Tasks are mostly independent (different files/modules)
-- You want quality gates between tasks (not just fire-and-forget)
-- You're staying in this session (not dispatching to parallel worktrees)
-
-## When NOT to Use
-
-- Tasks are tightly coupled (use manual execution)
-- You want parallel execution across sessions (use `pharaoh:execute` instead)
-- You don't have a plan yet (use `pharaoh:plan` first)
-- You just need parallel dispatch without review gates (use `pharaoh:parallel`)
-
-## Workflow
-
-### Phase 0 — Setup
-
-1. Read the plan file once. Extract all tasks with full text.
-2. Note cross-task context: shared types, import paths, architectural constraints.
-3. Create a task list tracking each task's status.
-
-### Phase 1 — Per-Task Loop
-
-For each task:
-
-#### 1a. Dispatch Implementer
-
-Launch a subagent with:
-- **Full task text** (paste it, don't make the agent read the file)
-- **Scene-setting context** (where this fits, what's already built, dependencies)
-- **Constraints** (what NOT to change, scope boundaries)
-- **Working directory**
-
-The implementer should:
-1. Ask questions before starting (don't guess)
-2. Implement exactly what the task specifies
-3. Write tests
-4. Commit
-5. Self-review
-6. Report with status: **DONE** / **DONE_WITH_CONCERNS** / **NEEDS_CONTEXT** / **BLOCKED**
-
-#### 1b. Handle Status
-
-- **DONE** → proceed to spec review
-- **DONE_WITH_CONCERNS** → read concerns. If correctness/scope issues, address before review. If observations, note and proceed.
-- **NEEDS_CONTEXT** → provide missing information, re-dispatch
-- **BLOCKED** → assess: provide more context, use a more capable model, break task smaller, or escalate to user
-
-Never ignore an escalation. Never force retry without changes.
-
-#### 1c. Spec Compliance Review
-
-Dispatch a reviewer subagent with:
-- Full task requirements (original spec text)
-- Implementer's report of what they built
-
-The spec reviewer must:
-- Read actual code, not trust the report
-- Check: missing requirements, extra/unneeded work, misinterpretations
-- Verdict: **pass** or **issues found** (with file:line references)
-
-If issues found → implementer fixes → spec reviewer re-reviews → repeat until pass.
-
-#### 1d. Code Quality Review
-
-Only after spec compliance passes. Dispatch a quality reviewer with:
-- What was implemented
-- Git SHAs (base and head)
-- Task requirements
-
-The quality reviewer checks:
-- Single responsibility per file
-- Clean interfaces and decomposition
-- Test quality (assertions that verify behavior, not just coverage)
-- Following existing codebase patterns
-
-If issues found → implementer fixes → quality reviewer re-reviews → repeat until pass.
-
-#### 1e. Mark Complete
-
-Mark the task done. Move to next task.
-
-### Phase 2 — Final Review
-
-After all tasks complete, dispatch one final code reviewer across the entire implementation. Check for:
-- Cross-task integration issues
-- Consistency between tasks
-- Overall architecture coherence
-
-### Phase 3 — Finish
-
-Use `pharaoh:finish` to decide: merge, PR, or cleanup.
-
-## Model Selection
-
-Match model capability to task complexity:
-
-| Task type | Model tier |
-|-----------|-----------|
-| Isolated function, clear spec, 1-2 files | Fast/cheap |
-| Multi-file integration, pattern matching | Standard |
-| Architecture, design, review | Most capable |
-
-## Prompt Quality
-
-| Bad | Good |
-|-----|------|
-| "Implement the auth feature" | Full task text + context + constraints |
-| Sharing session history | Constructing focused context per agent |
-| "Fix it" | Specific report of what's wrong + file references |
-| Skipping spec review | Always spec review before quality review |
-
-## Iron Rules
-
-- **One task at a time** — no parallel implementation (conflicts)
-- **Never skip reviews** — spec compliance AND code quality, in that order
-- **Spec before quality** — wrong order wastes review cycles
-- **Construct context, don't inherit** — each agent gets exactly what it needs
-- **Never trust reports** — reviewers read code, not claims
-- **Fix before proceeding** — no moving to next task with open issues
-- **Escalation is success** — BLOCKED/NEEDS_CONTEXT means the system is working
-
-## Output
-
-After all tasks complete:
-- Summary of what was built (per task)
-- Review findings that were caught and fixed
-- Any concerns flagged by implementers
-- Final reviewer assessment
-- Ready for `pharaoh:finish`

package/skills/pr/SKILL.md

@@ -1,53 +0,0 @@
----
-name: pr
-prompt-name: pre-pr-review
-description: "Pre-pull-request architectural review checklist using Pharaoh codebase knowledge graph. Covers module context, blast radius per touched module, hidden coupling between modules, duplicate logic detection, regression risk scoring, and vision spec alignment. Produces a structured review summary before opening a PR."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["pull-request", "code-review", "architecture", "pharaoh", "pre-pr", "regression-risk"]}
----
-
-# Pre-PR Review
-
-Architectural review checklist to run before opening a pull request. Uses `pre-pr-review` — a 6-step workflow covering module context, blast radius, dependency coupling, duplicate logic, regression risk, and spec drift. Catches architectural problems before reviewers see the code.
-
-## When to Use
-
-Invoke before opening a pull request. Use it when changes touch one or more modules and you want a structured architectural assessment before requesting human review.
-
-## Workflow
-
-### Step 1: Module context
-
-For each touched module, call `get_module_context` to review its current structure and complexity.
-
-### Step 2: Blast radius
-
-For each touched module, call `get_blast_radius` to identify what else is affected by the changes.
-
-### Step 3: Dependency check
-
-Call `query_dependencies` between each pair of touched modules to find hidden coupling introduced by the PR.
-
-### Step 4: Consolidation check
-
-Call `get_consolidation_opportunities` for the target repository to flag any duplicate logic introduced by the PR.
-
-### Step 5: Regression risk
-
-Call `get_regression_risk` for the target repository to assess overall change risk.
-
-### Step 6: Vision alignment
-
-Call `get_vision_gaps` for the target repository to check if changes align with or drift from specs.
-
-## Output
-
-A review summary containing:
-- **Architecture impact:** modules affected, dependency changes introduced
-- **Risk assessment:** blast radius per module, overall regression risk level
-- **Cleanup opportunities:** consolidation candidates, unused code created
-- **Spec alignment:** vision gaps introduced or resolved by the PR
-
-Ready to paste into the PR description or share with reviewers.

package/skills/review-codex/SKILL.md

@@ -1,81 +0,0 @@
----
-name: review-codex
-prompt-name: cross-model-review
-description: "Cross-model security review. Dispatch code to a different AI model or subagent for independent second-opinion review. Evaluator applies AGREE, DISAGREE, or CONTEXT verdicts to each finding. Catches blind spots from single-model reasoning. Use for security-sensitive code, auth flows, data access, and architectural decisions."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["security-review", "cross-model", "second-opinion", "code-review", "verification"]}
----
-
-# Cross-Model Code Review
-
-Get a second opinion on critical code by dispatching it to an independent reviewer — a different agent, model, or subagent. One model's blind spots are another's obvious catches.
-
-## When to Use
-
-- Security-sensitive changes (auth, encryption, access control, token handling)
-- Data access patterns (tenant isolation, query construction, input validation)
-- Architectural decisions with long-term consequences
-- Code you're not fully confident about
-- Before shipping changes that affect user data or billing
-
-## Do Not Use When
-
-- Trivial changes (typos, formatting, dependency bumps)
-- Changes fully covered by existing tests with high mutation scores
-- Time-critical hotfixes where review delay is worse than risk
-
-## Process
-
-### 1. Prepare Review Package
-
-Assemble exactly what the reviewer needs:
-
-- **Changed files:** full diff or complete file contents
-- **Context:** what the code does, why it was changed, what it interacts with
-- **Constraints:** security requirements, isolation rules, performance bounds
-- **Specific concerns:** what you want the reviewer to focus on
-
-Do NOT send your session history — construct focused context.
-
-### 2. Dispatch to Reviewer
-
-Send the review package to an independent agent. The reviewer should have no knowledge of your reasoning process — they evaluate the code fresh.
-
-### 3. Reviewer Applies Verdicts
-
-For each finding, the reviewer assigns:
-
-| Verdict | Meaning |
-|---------|---------|
-| **AGREE** | Confirms the implementation is correct for the stated concern |
-| **DISAGREE** | Identifies a concrete issue with evidence |
-| **CONTEXT** | Cannot determine correctness — needs more information |
-
-Each DISAGREE must include: what's wrong, why it matters, and a suggested fix.
-
-### 4. Evaluate Findings
-
-When review returns:
-
-- **AGREE items:** no action needed
-- **DISAGREE items:** verify the finding against actual code. If confirmed, fix. If the reviewer misunderstood context, document why the current approach is correct.
-- **CONTEXT items:** provide the missing information and re-review that item
-
-## What to Include in Review
-
-| Category | Include | Skip |
-|----------|---------|------|
-| Auth/access control | Token validation, session management, permission checks | UI styling |
-| Data access | Query construction, tenant isolation, input sanitization | Logging format |
-| Cryptography | Key management, encryption/decryption, hashing | String formatting |
-| Error handling | What's exposed to users, what's logged, what's swallowed | Happy path only |
-
-## Key Principles
-
-- **Independent evaluation** — reviewer must not be primed with your conclusions
-- **Evidence-based verdicts** — no "looks fine" without specifics
-- **Verify disagreements** — reviewer may lack context; check before acting
-- **Don't skip uncomfortable findings** — the point is catching what you missed
-- **Repeat for high-stakes changes** — one review round may not be enough