claude-mpm 5.4.59__py3-none-any.whl → 5.4.64__py3-none-any.whl

claude_mpm/skills/bundled/pm/pm-delegation-patterns/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: pm-delegation-patterns
+version: "1.0.0"
+description: Common delegation patterns for PM agent
+when_to_use: delegation questions, agent selection, workflow patterns
+category: pm-reference
+tags: [delegation, agents, patterns, pm-required]
+---
+
+# Common Delegation Patterns
+
+## Full Stack Feature
+
+**Workflow**: Research → Analyzer → react-engineer + Engineer → Ops (deploy) → Ops (VERIFY) → api-qa + web-qa → Docs
+
+**When**: Complete feature requiring frontend, backend, and deployment
+
+**Example**:
+```
+User: "Add user dashboard with analytics"
+PM delegates:
+  1. Research: Investigate dashboard frameworks and analytics libraries
+  2. Code Analyzer: Review solution approach
+  3. react-engineer: Build dashboard UI components
+  4. Engineer: Implement analytics API endpoints
+  5. Ops: Deploy to staging
+  6. Ops: Verify deployment (health checks, logs)
+  7. api-qa: Test API endpoints
+  8. web-qa: Test dashboard UI
+  9. Documentation: Update API docs and user guide
+```
+
+## API Development
+
+**Workflow**: Research → Analyzer → Engineer → Deploy (if needed) → Ops (VERIFY) → web-qa (fetch tests) → Docs
+
+**When**: Backend API implementation without frontend
+
+**Example**:
+```
+User: "Create REST API for user management"
+PM delegates:
+  1. Research: API design patterns, authentication
+  2. Code Analyzer: Review API design
+  3. Engineer: Implement API endpoints
+  4. Ops: Deploy API to staging (if needed)
+  5. Ops: Verify deployment
+  6. web-qa: Run fetch tests on endpoints
+  7. Documentation: Generate API documentation
+```
+
+## Web UI
+
+**Workflow**: Research → Analyzer → web-ui/react-engineer → Ops (deploy) → Ops (VERIFY with Playwright) → web-qa → Docs
+
+**When**: Frontend-only changes
+
+**Example**:
+```
+User: "Redesign landing page"
+PM delegates:
+  1. Research: UI/UX best practices, component libraries
+  2. Code Analyzer: Review design approach
+  3. react-engineer: Implement new landing page
+  4. Ops: Deploy to staging
+  5. Ops: Verify deployment with Playwright
+  6. web-qa: Visual regression testing
+  7. Documentation: Update component documentation
+```
+
+## Local Development
+
+**Workflow**: Research → Analyzer → Engineer → **local-ops** (PM2/Docker) → **local-ops** (VERIFY logs+fetch) → QA → Docs
+
+**When**: Working with localhost, PM2, Docker, or local processes
+
+**Example**:
+```
+User: "Set up local development server"
+PM delegates:
+  1. Research: Local development setup best practices
+  2. Code Analyzer: Review setup approach
+  3. Engineer: Configure development environment
+  4. local-ops: Start server with PM2/Docker
+  5. local-ops: Verify server running (lsof, curl, logs)
+  6. QA: Test local endpoints
+  7. Documentation: Update setup guide
+```
+
+## Bug Fix
+
+**Workflow**: Research → Analyzer → Engineer → Deploy → Ops (VERIFY) → web-qa (regression) → version-control
+
+**When**: Fixing reported bugs
+
+**Example**:
+```
+User: "Fix login error on Safari"
+PM delegates:
+  1. Research: Investigate Safari-specific issues
+  2. Code Analyzer: Review fix approach
+  3. Engineer: Implement fix
+  4. Ops: Deploy fix to staging
+  5. Ops: Verify deployment
+  6. web-qa: Run regression tests, verify Safari fix
+  7. version-control: Create PR with fix
+```
+
+## Vercel Site
+
+**Workflow**: Research → Analyzer → Engineer → vercel-ops (deploy) → vercel-ops (VERIFY) → web-qa → Docs
+
+**When**: Vercel-hosted applications
+
+**Example**:
+```
+User: "Deploy blog to Vercel"
+PM delegates:
+  1. Research: Vercel deployment best practices
+  2. Code Analyzer: Review deployment config
+  3. Engineer: Configure Vercel settings
+  4. vercel-ops: Deploy to Vercel
+  5. vercel-ops: Verify deployment (health check)
+  6. web-qa: Test deployed site
+  7. Documentation: Update deployment guide
+```
+
+## Railway App
+
+**Workflow**: Research → Analyzer → Engineer → railway-ops (deploy) → railway-ops (VERIFY) → api-qa → Docs
+
+**When**: Railway-hosted applications
+
+**Example**:
+```
+User: "Deploy API to Railway"
+PM delegates:
+  1. Research: Railway deployment patterns
+  2. Code Analyzer: Review Railway config
+  3. Engineer: Configure Railway settings
+  4. railway-ops: Deploy to Railway
+  5. railway-ops: Verify deployment
+  6. api-qa: Test API endpoints
+  7. Documentation: Update deployment docs
+```
+
+## Agent Selection by Trigger Keywords
+
+| Keywords | Agent | Use Case |
+|----------|-------|----------|
+| localhost, PM2, docker-compose, port, process | **local-ops** | Local development |
+| vercel, edge function, serverless | **vercel-ops** | Vercel platform |
+| railway, nixpacks | **railway-ops** | Railway platform |
+| gcp, google cloud, IAM, OAuth consent | **gcp-ops** | Google Cloud |
+| clerk, auth middleware, OAuth provider | **clerk-ops** | Clerk authentication |
+| browser, screenshot, click, navigate, DOM | **web-qa** | Browser testing |
+| ticket, issue, PROJ-123, #123 | **ticketing** | Ticket operations |
+| skill, stack, framework | **mpm-skills-manager** | Skill management |
+
+## Delegation Best Practices
+
+1. **Provide Context**: Include relevant background for agent
+2. **Clear Acceptance Criteria**: Define completion criteria
+3. **Wait for Completion**: Don't interrupt agent work
+4. **Collect Evidence**: Get specific artifacts from agents
+5. **Immediate File Tracking**: Track files right after agent creates them
+6. **Chain Verification**: QA verification after implementation

claude_mpm/skills/bundled/pm/pm-git-file-tracking/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: pm-git-file-tracking
+version: "1.0.0"
+description: Protocol for tracking files immediately after agent creation
+when_to_use: after agent creates files, before marking todo complete, git operations
+category: pm-workflow
+tags: [git, file-tracking, workflow, pm-required]
+---
+
+# Git File Tracking Protocol
+
+**Critical Principle**: Track files IMMEDIATELY after an agent creates them, not at session end.
+
+## File Tracking Decision Flow
+
+```
+Agent completes work and returns to PM
+    ↓
+Did agent create files? → NO → Mark todo complete, continue
+    ↓ YES
+MANDATORY FILE TRACKING (BLOCKING)
+    ↓
+Step 1: Run `git status` to see new files
+Step 2: Check decision matrix (deliverable vs temp/ignored)
+Step 3: Run `git add <files>` for all deliverables
+Step 4: Run `git commit -m "..."` with proper context
+Step 5: Verify tracking with `git status`
+    ↓
+ONLY NOW: Mark todo as completed
+```
+
+**BLOCKING REQUIREMENT**: PM cannot mark todo complete until files are tracked.
+
+## Decision Matrix: When to Track Files
+
+| File Type | Track? | Reason |
+|-----------|--------|--------|
+| New source files (`.py`, `.js`, etc.) | ✅ YES | Production code must be versioned |
+| New config files (`.json`, `.yaml`, etc.) | ✅ YES | Configuration changes must be tracked |
+| New documentation (`.md` in `/docs/`) | ✅ YES | Documentation is part of deliverables |
+| Documentation in project root (`.md`) | ❌ NO | Only core docs allowed (README, CHANGELOG, CONTRIBUTING) |
+| New test files (`test_*.py`, `*.test.js`) | ✅ YES | Tests are critical artifacts |
+| New scripts (`.sh`, `.py` in `/scripts/`) | ✅ YES | Automation must be versioned |
+| Files in `/tmp/` directory | ❌ NO | Temporary by design (gitignored) |
+| Files in `.gitignore` | ❌ NO | Intentionally excluded |
+| Build artifacts (`dist/`, `build/`) | ❌ NO | Generated, not source |
+| Virtual environments (`venv/`, `node_modules/`) | ❌ NO | Dependencies, not source |
+
+## Commit Message Format
+
+```bash
+git commit -m "feat: add {description}
+
+- Created {file_type} for {purpose}
+- Includes {key_features}
+- Part of {initiative}
+
+🤖 Generated with [Claude MPM](https://github.com/bobmatnyc/claude-mpm)
+
+Co-Authored-By: Claude <noreply@anthropic.com>"
+```
+
+## Before Ending Any Session
+
+**Final verification checklist**:
+
+```bash
+# 1. Check for untracked files
+git status
+
+# 2. If any deliverable files found (should be rare):
+git add <files>
+git commit -m "feat: final session deliverables..."
+
+# 3. Verify tracking complete
+git status  # Should show "nothing to commit, working tree clean"
+```
+
+**Ideal State**: `git status` shows NO untracked deliverable files because PM tracked them immediately after each agent.
+
+## Example Workflow
+
+```bash
+# After Engineer creates new OAuth files
+git status
+# Shows: src/auth/oauth2.js (untracked)
+#        src/routes/auth.js (untracked)
+
+git add src/auth/oauth2.js src/routes/auth.js
+
+git commit -m "feat: add OAuth2 authentication
+
+- Created OAuth2 authentication module
+- Added authentication routes
+- Part of user login feature
+
+🤖 Generated with [Claude MPM](https://github.com/bobmatnyc/claude-mpm)
+
+Co-Authored-By: Claude <noreply@anthropic.com>"
+
+# Verify tracking complete
+git status  # Should show clean working tree
+```
+
+## Integration with Todo Workflow
+
+**BLOCKING SEQUENCE**:
+1. Agent completes task and returns to PM
+2. PM checks if files were created
+3. If YES → Run file tracking protocol (cannot proceed until complete)
+4. Only after tracking verified → Mark todo as completed
+
+This ensures no deliverables are lost between agent completion and session end.

claude_mpm/skills/bundled/pm/pm-pr-workflow/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: pm-pr-workflow
+version: "1.0.0"
+description: Branch protection and PR creation workflow
+when_to_use: PR creation, branch operations, git push to main
+category: pm-workflow
+tags: [git, pr, branch-protection, pm-required]
+---
+
+# PR Workflow and Branch Protection
+
+## Branch Protection Enforcement
+
+**CRITICAL**: PM must enforce branch protection for main branch.
+
+### Detection (run before any main branch operation)
+
+```bash
+git config user.email
+```
+
+### Routing Rules
+
+- User is `bobmatnyc@users.noreply.github.com` → Can push directly to main (if explicitly requested)
+- Any other user → MUST use feature branch + PR workflow
+
+### User Request Translation
+
+When non-privileged users request main branch operations:
+
+| User Request | PM Action |
+|--------------|-----------|
+| "commit to main" | "Creating feature branch workflow instead" |
+| "push to main" | "Branch protection requires PR workflow" |
+| "merge to main" | "Creating PR for review" |
+
+**Error Prevention**: PM proactively guides non-privileged users to correct workflow (don't wait for git errors).
+
+## PR Workflow Delegation
+
+**Default**: Main-based PRs (unless user explicitly requests stacked)
+
+### When User Requests PRs
+
+- Single ticket → One PR (no question needed)
+- Independent features → Main-based (no question needed)
+- User says "stacked" or "dependent" → Stacked PRs (no question needed)
+
+### Recommend Main-Based When
+
+- User doesn't specify preference
+- Independent features or bug fixes
+- Multiple agents working in parallel
+- Simple enhancements
+
+### Recommend Stacked PRs When
+
+- User explicitly requests "stacked" or "dependent" PRs
+- Large feature with clear phase dependencies
+- User is comfortable with rebase workflows
+
+Always delegate to version-control agent with strategy parameters.
+
+## PR Creation Workflow
+
+When creating PRs, delegate to version-control agent with:
+
+```
+Task:
+  agent: "version-control"
+  task: "Create PR for {feature}"
+  context: |
+    Work completed: {summary}
+    Files changed: {file_list}
+    Tests: {test_status}
+    QA verification: {qa_evidence}
+  acceptance_criteria:
+    - Create feature branch from main
+    - Push all commits to feature branch
+    - Create PR with proper description
+    - Link ticket if applicable
+    - Request reviews if needed
+```
+
+## Common Patterns
+
+### Single Feature PR
+```bash
+# Feature branch → PR → Main
+feature/user-auth → PR #123 → main
+```
+
+### Stacked PRs (when requested)
+```bash
+# Stacked feature development
+feature/auth-base → PR #123 → main
+feature/oauth (based on auth-base) → PR #124 → feature/auth-base
+feature/session (based on oauth) → PR #125 → feature/oauth
+```
+
+### Bug Fix PR
+```bash
+# Hotfix branch → PR → Main
+fix/login-error → PR #126 → main
+```
+
+## Branch Protection Checklist
+
+Before any main branch operation:
+- [ ] Check git user email
+- [ ] Verify user has main branch access
+- [ ] If not privileged user, route to feature branch workflow
+- [ ] Create clear user messaging about branch protection
+
+## Integration with Git File Tracking
+
+All file tracking should happen on feature branches before PR creation:
+
+1. Agent creates files
+2. PM tracks files immediately (git add + commit)
+3. PM delegates PR creation to version-control
+4. version-control pushes branch and creates PR
+
+This ensures all work is tracked before entering PR workflow.

claude_mpm/skills/bundled/pm/pm-ticketing-integration/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: pm-ticketing-integration
+version: "1.0.0"
+description: Ticket-driven development protocol
+when_to_use: ticket IDs mentioned, issue URLs, work tracking
+category: pm-workflow
+tags: [tickets, integration, workflow, pm-required]
+---
+
+# Ticketing Integration Protocol
+
+## Detection Rules
+
+PM detects ticket context from:
+- Ticket ID patterns: `PROJ-123`, `#123`, `MPM-456`, `JJF-62`
+- Ticket URLs: `github.com/.../issues/123`, `linear.app/.../issue/XXX`
+- Explicit references: "work on ticket", "implement issue", "fix bug #123"
+- Session start context (first user message with ticket reference)
+
+## CRITICAL ENFORCEMENT
+
+**PM MUST NEVER use these tools directly - ALWAYS delegate to ticketing agent:**
+
+- ❌ PM using WebFetch on ticket URLs → Delegate to ticketing
+- ❌ PM using `mcp__mcp-ticketer__*` tools → Delegate to ticketing
+- ❌ PM using ANY tools to access tickets → ONLY delegate to ticketing agent
+
+**Delegation Rule**: ALL ticket operations must be delegated to ticketing agent.
+
+## TICKET-DRIVEN DEVELOPMENT PROTOCOL (TkDD)
+
+**When ticket detected** (PROJ-123, #123, ticket URLs, "work on ticket"):
+
+### PM MUST Execute This Workflow
+
+**1. Work Start** → Delegate to ticketing:
+```
+Task:
+  agent: "ticketing"
+  task: "Start work on ticket {ticket_id}"
+  acceptance_criteria:
+    - Transition ticket to 'in_progress'
+    - Add comment: "Work started by Claude MPM"
+    - Confirm state change
+```
+
+**2. Each Phase** → Comment with deliverables:
+```
+Task:
+  agent: "ticketing"
+  task: "Update ticket {ticket_id} with progress"
+  context: |
+    Phase completed: {phase_name}
+    Deliverables: {deliverable_summary}
+  acceptance_criteria:
+    - Add comment with phase completion details
+    - Include links to commits/PRs if applicable
+```
+
+**3. Work Complete** → Transition to done/closed:
+```
+Task:
+  agent: "ticketing"
+  task: "Complete ticket {ticket_id}"
+  context: |
+    Work summary: {summary}
+    QA verification: {qa_evidence}
+    Files changed: {file_list}
+  acceptance_criteria:
+    - Transition to 'done' or 'closed'
+    - Add comprehensive completion comment
+    - Link PR if created
+```
+
+**4. Blockers** → Comment blocker details:
+```
+Task:
+  agent: "ticketing"
+  task: "Report blocker on ticket {ticket_id}"
+  context: |
+    Blocker: {blocker_description}
+    Impact: {impact}
+    Waiting on: {dependency}
+  acceptance_criteria:
+    - Update ticket state to 'blocked'
+    - Add blocker details in comment
+    - Notify relevant stakeholders if applicable
+```
+
+## Documentation Routing with Ticket Context
+
+### When Ticket Context Provided
+
+When user starts session with ticket reference:
+- PM delegates to ticketing agent to attach work products
+- Research findings → Attached as comments to ticket
+- Specifications → Attached as files or formatted comments
+- Still create local docs as backup in `{docs_path}/`
+- All agent delegations include ticket context
+
+### When NO Ticket Context
+
+- All documentation goes to `{docs_path}/` (default: `docs/research/`)
+- No ticket attachment operations
+- Named with pattern: `{topic}-{date}.md`
+
+## Ticket Context Propagation
+
+When ticket is detected, PM includes ticket context in all delegations:
+
+```
+Task:
+  agent: "{any_agent}"
+  task: "{task_description}"
+  context: |
+    Ticket: {ticket_id}
+    Ticket summary: {summary_from_ticketing_agent}
+    {other_context}
+  acceptance_criteria:
+    {criteria}
+```
+
+This ensures all agents know work is ticket-driven and can reference it.
+
+## Example TkDD Workflow
+
+```
+User: "Work on ticket PROJ-123"
+    ↓
+PM delegates to ticketing: Get ticket details
+    ↓
+PM delegates to ticketing: Transition to 'in_progress', comment "Work started"
+    ↓
+PM delegates to research: Investigate approach (with ticket context)
+    ↓
+PM delegates to ticketing: Comment "Research phase complete: {findings}"
+    ↓
+PM delegates to engineer: Implement feature (with ticket context)
+    ↓
+PM delegates to ticketing: Comment "Implementation complete: {files}"
+    ↓
+PM delegates to QA: Verify implementation
+    ↓
+PM delegates to ticketing: Transition to 'done', comment "Work complete: {summary}"
+```
+
+## Violation Prevention
+
+**Circuit Breaker**: PM using ticket tools directly triggers:
+- Violation #1: ⚠️ WARNING - Must delegate immediately
+- Violation #2: 🚨 ESCALATION - Session flagged for review
+- Violation #3: ❌ FAILURE - Session non-compliant
+
+This enforcement ensures PM maintains pure coordination role.