pmc

Finalize a completed ticket: write 5-final.md, update 4-progress.md, commit. WHEN TO USE: - All required tests pass (via /pmc:ticket-status) - Ready to mark ticket as COMPLETE or BLOCKED - User says "complete ticket", "finalize", "wrap up ticket" PRODUCES: - 5-final.md with Status: COMPLETE or BLOCKED - Updated 4-progress.md frontmatter - Git commit: "T0000N: complete"

Orchestrate KB development workflow from request to completion. Coordinates skills in sequence: kb → plan → test → validate → complete → reflect → inbox. WORKFLOW: 1. LOOKUP - /pmc:kb (check existing PRDs, patterns, code maps) 2. PLAN - /pmc:plan + /pmc:plan-validation + /pmc:lint-kb 3. IMPLEMENT - /pmc:test (TDD cycle: RED → GREEN → REFACTOR) 4. VALIDATE - /pmc:validate + /pmc:ticket-status 5. COMPLETE - /pmc:complete (write 5-final.md, commit) 6. REFLECT - /pmc:reflect + /pmc:lint-kb 7. INBOX - /pmc:inbox (process pending items) Use when: - User says "implement", "build", "develop", "work on" - Starting new feature or phase work - Need guided workflow from start to finish - User says "dev workflow", "full cycle"

Process pending items from 0-inbox/ task queue. Assess scope and create appropriate KB artifacts (tickets, phases, PRDs). WHEN TO USE: - After completing primary work (ticket, phase, user request) - User says "check inbox", "process inbox", "what's pending" - Periodic inbox review SOURCES: - Direct user messages (not immediately actionable) - GitHub issues/PRs - Slack messages - External integrations NOT during main workflow - only after primary directive complete.

Knowledge base for session continuity. Maintains project documentation with fixed directory structure (.pmc/docs/) and formats for PRDs, SOPs, tickets (T0000N), patterns, decisions, code maps, research, and status. CRITICAL BEHAVIORS: 1. LOOKUP FIRST - Before any task, check kb for existing docs (SOPs, patterns, code maps, status) that may guide the work. Don't reinvent what's documented. 2. LEARN = DOCUMENT - When user says "learn X", record it in appropriate doc: - Procedure? → 2-sop/ - Problem/solution? → 6-patterns/ (with Status: open|resolved) - Code flow? → 7-code-maps/ - Research/notes? → 8-research/ - Design decision? → 5-decisions/D###-{name}.md - User clarification? → capture in ticket 5-final.md 3. CAPTURE INTENT - When user clarifies requirements or expresses preferences, record in ticket's 5-final.md (Revealed Intent section). 4. INBOX - Direct user messages → 0-inbox/ for later processing by /pmc:dev or /pmc:plan. Use when: setting up docs structure, creating/managing tickets, documenting solutions, mapping code flows, archiving completed work, tracking project status, capturing user intent, OR when user asks to "learn" something.

Validate and enforce KB documentation formats, completeness, and integrity. Checks recent docs (uncommitted or last N commits) against KB standards. CHECKS PERFORMED: 1. FORMAT - Documents follow required templates (headers, sections) 2. COMPLETENESS - Tickets/issues have all required files (1-5) 3. INTEGRITY - All tickets in index.md, phases in roadmap.md 4. PATTERNS - Have Status: open|resolved 5. NAMING - Files follow conventions (verb-noun, feat-, comp-, etc.) Use when: - Before committing KB docs - After creating tickets/issues - Periodic maintenance - User says "lint kb", "check docs", "validate kb"

Validate skill documents against PMC skill design principles. Checks format ownership, composite skill structure, and internal consistency. CHECKS: 1. FORMAT OWNERSHIP - kb skill owns all format templates (kb/references/) 2. COMPOSITE STRUCTURE - Steps must have associated skills, stage announcements 3. INTERNAL CONSISTENCY - No gaps, broken references, or missing sections Use when: - Creating new skills - Reviewing existing skills - Periodic skill maintenance - User says "lint skills", "check skills", "validate skills"

PMC memory system for persistent context across sessions. Store, search, and retrieve project knowledge using semantic vector search (OpenAI embeddings) and full-text keyword search. Use when: storing important context, searching for past solutions, retrieving project-specific knowledge, or building up institutional memory.

Validate planning documents before implementation begins. Checks ambiguity resolution, prerequisites, and testing methods. Use when: - Before starting implementation of a ticket - User says "validate plan", "check plan", "ready to implement?" - After completing 2-plan.md and 3-spec.md - Before TDD cycle begins

Plan development work following KB skill's structured approach with PRDs, phases, tickets, TDD specifications, and parallel execution planning. WORKFLOW: 1. KB LOOKUP - Check existing PRDs, patterns, code maps, SOPs 2. SCOPE - Small (ticket only) or Large (PRD + phases)? 3. PRD - Create for large work 4. PHASES - Break into 2-5 tickets + Phase E2E 5. TICKETS - Create with TDD spec (3-spec.md is critical) 6. PARALLEL ANALYSIS - Dependency matrix, file conflicts, execution mode 7. GIT SETUP - Phase branch, worktrees for parallel tickets 8. QUESTIONS - Resolve all ambiguity before implementation Use when: - User asks to implement something non-trivial - User says "plan", "design", "how would you implement" - Task requires multiple files or sessions - Requirements are unclear

Perform reflection after completing work to capture learnings in KB. Ensures knowledge is preserved for future sessions. WHEN TO USE: - After completing a ticket (before archiving) - After completing a phase - Before session ends (user says "wrapping up", "stopping for now") - When user says "reflect", "capture learnings", "what did we learn" CAPTURES: - Patterns: problems solved (resolved) OR issues found (open) - Decisions: architectural/design choices made - Code flows: new understanding of codebase - Procedures: repetitive tasks worth documenting - Learnings: in ticket's 5-final.md

Execute tests following TDD cycle: RED (verify test fails) → GREEN (implement to pass) → REFACTOR. Interprets tests.json and performs steps using available tools (browser MCP, API, CLI, etc.). WHEN TO USE: - Starting implementation of a ticket with TDD: yes - After writing test spec (3-spec.md) and tests.json - When user says "run tests", "test this", "TDD cycle" - After fixing a failing test REQUIRES: - Ticket with 3-spec.md - tests.json in .pmc/docs/tests/tickets/T0000N/

Programmatic verification of KB state: tickets, phases, tests, integrity. Provides scripts for automated checking at each workflow stage. SCRIPTS: - check_ticket.py: Ticket docs, tests, final status → next step - check_phase.py: Phase progress, all tickets complete? - check_tests.py: Trajectory, RED verification, coverage vs spec - check_integrity.py: Index.md matches dirs, roadmap has all active items Use when: - Checking ticket/phase completion - Validating before commit/archive - CI/CD automation - User says "status", "check", "verify"

Synchronize knowledge base documentation with current codebase implementation. Performs full, incremental, or targeted audits of source code and updates code maps, PRDs, patterns, SOPs, and user-facing docs to match reality. Use when: - After major refactors - Periodic maintenance (monthly) - Before starting new phase of work - When docs feel stale - User says "update kb", "sync docs", "audit docs"

Verify test execution by replaying trajectory and checking script coverage. Ensures tests actually happened as recorded and scripts cover all test cases. WHEN TO USE: - After tests claim to pass (verify they actually ran) - Before marking ticket complete (audit trail) - When reviewing someone else's work - User says "validate", "verify tests", "check coverage" - Periodic audit of test integrity CHECKS: 1. TRAJECTORY - Steps match recorded actions 2. EVIDENCE - Screenshots, logs, outputs exist 3. COVERAGE - Scripts test all cases from 3-spec.md 4. COMPLETENESS - All required tests have trajectory

Develop, test, and register PMC workflows. Workflows are JSON state machines for Claude CLI, shell, sub-workflows. WORKFLOW: 1. DEFINE - Create workflow JSON with states, transitions 2. VALIDATE - pmc validate <workflow.json> 3. MOCK - Create mock scripts for each state 4. TEST MOCK - pmc run --mock to test transitions 5. TEST REAL - pmc run with real data 6. REGISTER - Add to registry.json Use when: - User says "create workflow", "new workflow", "automate" - Automating repetitive multi-step processes - Building CI/CD or development pipelines