@pharaoh-so/mcp 0.3.14 → 0.3.16

package/skills/review-receive/SKILL.md

@@ -1,82 +0,0 @@
----
-name: review-receive
-prompt-name: receive-code-review
-description: "Receive code review feedback with technical rigor. No performative agreement — verify suggestions against codebase reality before implementing. Push back with evidence when feedback is wrong. Clarify all unclear items before implementing any. External feedback is suggestions to evaluate, not orders to follow."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["code-review", "feedback", "technical-rigor", "pushback", "collaboration"]}
----
-
-# Receiving Code Review
-
-Code review requires technical evaluation, not emotional performance.
-
-**Verify before implementing. Ask before assuming. Technical correctness over social comfort.**
-
-## When to Use
-
-When receiving code review feedback — from humans, external reviewers, or automated tools. Especially when feedback seems unclear or technically questionable.
-
-## The Response Pattern
-
-1. **READ:** complete feedback without reacting
-2. **UNDERSTAND:** restate the requirement in your own words (or ask)
-3. **VERIFY:** check against codebase reality
-4. **EVALUATE:** technically sound for THIS codebase?
-5. **RESPOND:** technical acknowledgment or reasoned pushback
-6. **IMPLEMENT:** one item at a time, test each
-
-## Forbidden Responses
-
-Never respond with:
-- "You're absolutely right!"
-- "Great point!" / "Excellent feedback!"
-- "Let me implement that now" (before verification)
-- Any gratitude expression
-
-Instead: restate the technical requirement, ask clarifying questions, push back with evidence if wrong, or just start fixing.
-
-## Handling Unclear Feedback
-
-If ANY item is unclear: **stop — do not implement anything yet.** Ask for clarification on unclear items before touching code. Items may be related; partial understanding produces wrong implementations.
-
-## Evaluating External Feedback
-
-Before implementing suggestions from external reviewers:
-
-1. Is this technically correct for THIS codebase?
-2. Does it break existing functionality?
-3. Is there a reason for the current implementation?
-4. Does the reviewer understand the full context?
-5. Does it conflict with prior architectural decisions?
-
-If a suggestion seems wrong, push back with technical reasoning — reference working tests, actual code, or codebase patterns.
-
-## When to Push Back
-
-- Suggestion breaks existing functionality
-- Reviewer lacks full context
-- Feature is unused (YAGNI)
-- Technically incorrect for this stack
-- Conflicts with established architectural decisions
-
-**How:** technical reasoning, specific questions, references to working code. Never defensive — just factual.
-
-## Implementation Order
-
-For multi-item feedback:
-
-1. Clarify anything unclear FIRST
-2. Implement in priority order: blocking issues, simple fixes, complex fixes
-3. Test each fix individually
-4. Verify no regressions
-
-## Acknowledging Correct Feedback
-
-When feedback IS correct:
-- "Fixed. [Brief description of what changed]"
-- "Good catch — [specific issue]. Fixed in [location]."
-- Or just fix it silently — the code shows you heard.
-
-Actions speak. No performative agreement needed.

package/skills/wiring/SKILL.md

@@ -1,35 +0,0 @@
----
-name: wiring
-prompt-name: validate-wiring
-description: "Wiring validation for a codebase module using Pharaoh knowledge graph. Four-step pro-tier workflow: entry point reachability, caller verification via blast radius, test coverage per function, and dead code detection. Categorizes functions as CONNECTED, UNREACHABLE, DEAD, or UNTESTED. Produces a PASS or FAIL verdict with specific issues listed. Iron law: zero callers on a non-entry-point export means the code is not wired."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["wiring", "reachability", "dead-code", "pharaoh", "test-coverage", "entry-points", "validation"]}
----
-
-# Validate Wiring
-
-Verify that code in a module is properly connected. Uses `validate-wiring` — a 4-step pro-tier workflow that checks reachability from entry points, verifies functions have callers, confirms test coverage, and detects dead code. Produces a PASS / FAIL verdict with categorized findings. Requires Pro tools.
-
-## When to Use
-
-Invoke after adding new exports or functions, before merging code that adds a new module, or when dead code is suspected. Use it to answer "is this code actually being used?" with data instead of guesswork.
-
-## Workflow
-
-1. Call `check_reachability` for the target module to verify all exports are reachable from production entry points.
-2. Call `get_blast_radius` for the target module to verify functions have callers.
-3. Call `get_test_coverage` for the target module to check which functions are tested.
-4. Call `get_unused_code` for the target module to detect any dead code.
-
-Iron law: Zero callers on a non-entry-point export = the code is not wired.
-
-## Output
-
-A wiring report containing:
-- **CONNECTED:** Functions reachable from entry points with test coverage
-- **UNREACHABLE:** Exports with no path from entry points
-- **DEAD:** Functions with zero callers (not entry points)
-- **UNTESTED:** Reachable functions lacking test coverage
-- **Verdict:** PASS (all exports wired and tested) or FAIL (with specific issues listed and recommended actions)

package/skills/worktree/SKILL.md

@@ -1,86 +0,0 @@
----
-name: worktree
-prompt-name: git-worktree
-description: "Set up isolated git worktrees for feature work. Smart directory selection with safety verification — checks for existing worktree directories, verifies gitignore, auto-detects project setup, and confirms clean test baseline before starting. Prevents accidentally committing worktree contents."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["git", "worktree", "isolation", "branching", "workspace"]}
----
-
-# Git Worktrees
-
-Create isolated workspaces sharing the same repository. Work on multiple branches simultaneously without switching.
-
-## When to Use
-
-Before starting feature work that needs isolation from the current workspace. Before executing implementation plans. Any time you need a clean branch without disturbing current work.
-
-## Directory Selection
-
-Follow this priority order:
-
-1. **Check existing directories:** look for `.worktrees/` or `worktrees/` in the project root. If both exist, `.worktrees/` wins.
-2. **Check project docs:** look for worktree directory preferences in CLAUDE.md or project config.
-3. **Ask the user:** if no directory exists and no preference is documented.
-
-## Safety Verification
-
-For project-local worktree directories:
-
-```bash
-git check-ignore -q .worktrees 2>/dev/null
-```
-
-If the directory is NOT gitignored: add it to `.gitignore` and commit before creating worktrees. This prevents accidentally committing worktree contents to the repository.
-
-Global directories (outside the project) don't need this check.
-
-## Creation Steps
-
-### 1. Create Worktree
-
-```bash
-git worktree add <path>/<branch-name> -b <branch-name>
-cd <path>/<branch-name>
-```
-
-### 2. Install Dependencies
-
-Auto-detect from project files:
-
-| File | Command |
-|------|---------|
-| `package.json` + `pnpm-lock.yaml` | `pnpm install` |
-| `package.json` | `npm install` |
-| `Cargo.toml` | `cargo build` |
-| `requirements.txt` | `pip install -r requirements.txt` |
-| `go.mod` | `go mod download` |
-
-### 3. Verify Clean Baseline
-
-Run the project's test suite. If tests fail, report failures and ask whether to proceed or investigate. Don't start work on a broken baseline.
-
-### 4. Report
-
-```
-Worktree ready at <full-path>
-Tests passing (<N> tests, 0 failures)
-Ready to implement <feature-name>
-```
-
-## Common Mistakes
-
-| Mistake | Fix |
-|---------|-----|
-| Skipping gitignore verification | Always check before creating project-local worktrees |
-| Assuming directory location | Follow priority: existing > docs > ask |
-| Proceeding with failing baseline tests | Report failures, get permission first |
-| Hardcoding setup commands | Auto-detect from project files |
-
-## Red Flags
-
-- Never create a worktree without verifying it's gitignored (project-local)
-- Never skip baseline test verification
-- Never proceed with failing tests without asking
-- Never assume directory location when ambiguous