@pharaoh-so/mcp 0.3.51 → 0.3.53

package/commands/sessions.md

@@ -1,101 +0,0 @@
----
-description: Decompose work into parallel, isolated sessions using git worktrees
----
-
-# Session Decomposition
-
-Break large tasks into parallel, isolated work sessions. Each session runs in its own git worktree with fresh context, focused scope, and atomic commits.
-
-## When to Use
-
-- Task is too large for a single context window
-- Work has 3+ independent sub-tasks that don't touch the same files
-- You need to preserve context quality across a multi-hour effort
-- Multiple features or fixes can proceed in parallel
-
-## Do Not Use When
-
-- Sub-tasks share files or state
-- Work is sequential (each step depends on the previous)
-- Task fits comfortably in one session
-
-## Step 1: Reconnaissance
-
-If Pharaoh MCP tools are available, call `get_codebase_map` and `get_module_context` on affected modules to understand the current landscape before decomposing.
-
-## Step 2: Decompose
-
-Break the task into sessions. Each session must:
-
-- Have a clear, narrow goal (one feature, one fix, one module)
-- Touch a distinct set of files — no overlap between sessions
-- Be independently verifiable (tests pass, build succeeds)
-- Produce atomic commits that make sense on their own
-
-## Step 3: Write Session Prompts
-
-For each session, write a complete prompt containing:
-
-- **Goal:** what this session produces (1-2 sentences)
-- **Scope:** which files/modules to touch (explicit list)
-- **Constraints:** what NOT to change
-- **Verification:** how to confirm the work is correct
-- **Context:** any architectural decisions or patterns to follow
-
-## Step 4: Present for Review (MANDATORY — do NOT skip)
-
-**STOP. Paste every session prompt into the chat as a numbered list.**
-
-For each session, show:
-1. The session name
-2. The full prompt text
-3. Which sessions need `/plan` review (flag anything non-trivial)
-
-**Wait for the user to approve, modify, add, remove, or reorder sessions before proceeding.** Do not create worktrees or execute any work until the user explicitly approves the decomposition.
-
-If the user says "looks good" or similar, proceed. If they request changes, update the prompts and present again.
-
-## Step 5: Create Worktrees
-
-Only after user approval. For each session, create an isolated worktree:
-
-```bash
-git worktree add .worktrees/<session-name> -b <branch-name>
-```
-
-Install dependencies in each worktree. Verify clean baseline (tests pass).
-
-## Step 6: Execute Sessions
-
-Run each session independently. Sessions should not reference each other's work-in-progress — they operate on the same base commit.
-
-## Step 7: Integrate
-
-After all sessions complete:
-
-1. Verify each branch independently (tests pass, build succeeds)
-2. Merge branches sequentially into the target branch
-3. Resolve any conflicts (rare if decomposition was clean)
-4. Run full verification on the integrated result
-
-## Decomposition Rules
-
-| Good decomposition | Bad decomposition |
-|---|---|
-| Session A: auth module, Session B: billing module | Session A: backend, Session B: frontend (likely share types) |
-| Session A: new feature, Session B: unrelated bugfix | Session A: write code, Session B: write tests (coupled) |
-| Session A: parser, Session B: renderer (clear interface) | Session A: first half of file, Session B: second half |
-
-## Key Principles
-
-- **No shared files** — if two sessions touch the same file, merge them into one
-- **Fresh context per session** — don't carry state between sessions
-- **Atomic commits** — each session's output should be a coherent, reviewable unit
-- **Verify before integrating** — never merge a session that doesn't pass its own checks
-- **Decomposition is the hard part** — spend time getting boundaries right before starting work
-- **The user reviews before execution** — always present prompts, never skip to building
----
-
-Here is the task to decompose into sessions:
-
-$ARGUMENTS

package/skills/parallel/SKILL.md

@@ -1,75 +0,0 @@
----
-name: parallel
-prompt-name: parallel-agents
-description: "Dispatch 2+ independent subagent tasks that run concurrently. Each agent gets focused scope, clear goal, constraints, and expected output. No shared state between agents. Review and integrate results after all complete."
-version: 0.2.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["parallel", "subagents", "concurrency", "delegation", "efficiency"]}
----
-
-# Parallel Dispatch
-
-Delegate independent tasks to specialized agents running concurrently. Each agent gets isolated context and focused scope. Never share your session history — construct exactly what each agent needs.
-
-## When to Use
-
-- 2+ independent tasks with no shared state
-- Multiple failures across different subsystems
-- Each problem can be understood without context from others
-- Agents won't edit the same files
-
-## Do Not Use When
-
-- Failures are related (fixing one might fix others)
-- Tasks require understanding full system state
-- Agents would edit the same files or resources
-- You don't yet know what's broken (investigate first)
-
-## The Pattern
-
-### 1. Identify Independent Domains
-
-Group work by what's independent:
-- Different test files with different root causes
-- Different modules with unrelated issues
-- Different features with no shared code
-
-### 2. Craft Agent Prompts
-
-Each agent gets:
-
-- **Specific scope:** one file, one module, one subsystem
-- **Clear goal:** what success looks like
-- **Constraints:** what NOT to change
-- **Context:** error messages, relevant code paths, architectural notes
-- **Expected output:** summary of findings and changes
-
-### 3. Dispatch
-
-Launch all agents simultaneously. They run concurrently with no coordination needed.
-
-### 4. Review and Integrate
-
-When agents return:
-
-1. Read each summary — understand what changed
-2. Check for conflicts — did agents edit overlapping code?
-3. Run full test suite — verify all fixes work together
-4. Spot-check results — agents can make systematic errors
-
-## Prompt Quality
-
-| Bad | Good |
-|-----|------|
-| "Fix all the tests" | "Fix the 3 failures in agent-abort.test.ts" |
-| "Fix the race condition" | "Fix timing in abort test — here are the error messages: ..." |
-| No constraints | "Do NOT change production code, fix tests only" |
-| "Fix it" | "Return: root cause summary + what you changed" |
-
-## Iron Rules
-
-- **One task per agent** — focused agents produce better results than broad ones
-- **No shared state** — agents must not depend on each other's output
-- **Never trust agent reports** — verify changes independently before integrating
-- **Construct context, don't inherit** — give each agent exactly what it needs, nothing more

package/skills/sessions/SKILL.md

@@ -1,102 +0,0 @@
----
-name: sessions
-prompt-name: session-decomposition
-description: "Decompose work into parallel, isolated sessions using git worktrees. Each session gets fresh context, a narrow scope, and produces atomic commits. Presents session prompts for user review before execution."
-version: 0.3.0
-homepage: https://pharaoh.so
-user-invocable: true
-metadata: {"emoji": "☥", "tags": ["sessions", "worktrees", "parallel-work", "context-management", "decomposition"]}
----
-
-# Session Decomposition
-
-Break large tasks into parallel, isolated work sessions. Each session runs in its own git worktree with fresh context, focused scope, and atomic commits.
-
-## When to Use
-
-- Task is too large for a single context window
-- Work has 3+ independent sub-tasks that don't touch the same files
-- You need to preserve context quality across a multi-hour effort
-- Multiple features or fixes can proceed in parallel
-
-## Do Not Use When
-
-- Sub-tasks share files or state
-- Work is sequential (each step depends on the previous)
-- Task fits comfortably in one session
-
-## Step 1: Reconnaissance
-
-If Pharaoh MCP tools are available, call `get_codebase_map` and `get_module_context` on affected modules to understand the current landscape before decomposing.
-
-## Step 2: Decompose
-
-Break the task into sessions. Each session must:
-
-- Have a clear, narrow goal (one feature, one fix, one module)
-- Touch a distinct set of files — no overlap between sessions
-- Be independently verifiable (tests pass, build succeeds)
-- Produce atomic commits that make sense on their own
-
-## Step 3: Write Session Prompts
-
-For each session, write a complete prompt containing:
-
-- **Goal:** what this session produces (1-2 sentences)
-- **Scope:** which files/modules to touch (explicit list)
-- **Constraints:** what NOT to change
-- **Verification:** how to confirm the work is correct
-- **Context:** any architectural decisions or patterns to follow
-
-## Step 4: Present for Review (MANDATORY — do NOT skip)
-
-**STOP. Paste every session prompt into the chat as a numbered list.**
-
-For each session, show:
-1. The session name
-2. The full prompt text
-3. Which sessions need `/plan` review (flag anything non-trivial)
-
-**Wait for the user to approve, modify, add, remove, or reorder sessions before proceeding.** Do not create worktrees or execute any work until the user explicitly approves the decomposition.
-
-If the user says "looks good" or similar, proceed. If they request changes, update the prompts and present again.
-
-## Step 5: Create Worktrees
-
-Only after user approval. For each session, create an isolated worktree:
-
-```bash
-git worktree add .worktrees/<session-name> -b <branch-name>
-```
-
-Install dependencies in each worktree. Verify clean baseline (tests pass).
-
-## Step 6: Execute Sessions
-
-Run each session independently. Sessions should not reference each other's work-in-progress — they operate on the same base commit.
-
-## Step 7: Integrate
-
-After all sessions complete:
-
-1. Verify each branch independently (tests pass, build succeeds)
-2. Merge branches sequentially into the target branch
-3. Resolve any conflicts (rare if decomposition was clean)
-4. Run full verification on the integrated result
-
-## Decomposition Rules
-
-| Good decomposition | Bad decomposition |
-|---|---|
-| Session A: auth module, Session B: billing module | Session A: backend, Session B: frontend (likely share types) |
-| Session A: new feature, Session B: unrelated bugfix | Session A: write code, Session B: write tests (coupled) |
-| Session A: parser, Session B: renderer (clear interface) | Session A: first half of file, Session B: second half |
-
-## Key Principles
-
-- **No shared files** — if two sessions touch the same file, merge them into one
-- **Fresh context per session** — don't carry state between sessions
-- **Atomic commits** — each session's output should be a coherent, reviewable unit
-- **Verify before integrating** — never merge a session that doesn't pass its own checks
-- **Decomposition is the hard part** — spend time getting boundaries right before starting work
-- **The user reviews before execution** — always present prompts, never skip to building