Specialist Agents
PP Core does its work through a team of focused subagents rather than one general assistant. Each agent has a single job, a clean context window, and a narrow set of permissions, and an orchestrator coordinates them so the heavy lifting never pollutes the conversation you are driving.
Why Specialists Instead of One Agent
A single agent asked to research, plan, code, and review will carry the residue of every earlier step into the next one. Research notes crowd out planning detail; planning detail crowds out the code. PP Core sidesteps this by giving each responsibility to a dedicated agent that starts fresh, receives only the role definition and artifacts it needs, and writes its result to disk. The benefit compounds: the orchestrator's context never swells with the internals of each subagent's work, because only the finished output comes back.
The Roles
Agents fall into a few families by the part of the phase loop they serve.
| Agent | Family | Responsibility |
|---|---|---|
| pp-phase-researcher | Researcher | Investigates implementation approaches and audits package legitimacy, producing RESEARCH.md |
| pp-project-researcher | Researcher | Explores the ecosystem before a roadmap is drawn, generating stack and architecture notes |
| pp-ui-researcher | Researcher | Detects existing design systems and produces a UI design contract |
| pp-domain-researcher | Researcher | Researches business context and evaluation criteria for AI-related work |
| pp-research-synthesizer | Planner | Consolidates parallel research outputs into a single summary |
| pp-planner | Planner | Builds atomic execution plans with explicit acceptance criteria |
| pp-roadmapper | Planner | Maps requirements to phases during project initialization |
| pp-plan-checker | Checker | Validates plans across multiple quality dimensions before execution |
| pp-executor | Executor | Implements plans and commits code — the only agent permitted to modify files |
| pp-verifier | Verifier | Confirms the implementation meets requirements and checks test quality |
| pp-code-reviewer | Verifier | Reviews code for bugs and security issues (read-only) |
| pp-security-auditor | Verifier | Confirms threat mitigations were actually implemented |
| pp-nyquist-auditor | Verifier | Fills test coverage gaps by generating additional tests |
| pp-codebase-mapper | Mapper | Analyzes an existing codebase across several dimensions in parallel |
| pp-debugger | Specialist | Investigates bugs with persistent session state and tracked hypotheses |
| pp-assumptions-analyzer | Specialist | Surfaces codebase assumptions with confidence levels and consequences |
How Orchestration Works
A command such as /pp-plan-phase or /pp-execute-phase acts as an orchestrator. It does not do the detailed work itself. Instead it spawns the appropriate specialist agents, each in an isolated context window, hands them their brief, and collects what they write back.
Researchers illustrate the pattern well: a single planning command can launch several researchers in parallel, each examining a different facet of the problem at the same time. A synthesizer then folds their separate outputs into one coherent document. Executors follow the same model during the build, running independent tasks as concurrent waves so unrelated work proceeds simultaneously.
/pp-execute-phase
└─ orchestrator
├─ pp-executor (wave 1, task A) ┐ run in parallel
├─ pp-executor (wave 1, task B) ┘
└─ pp-executor (wave 2, task C) ← waits on wave 1
Separation of Powers
The roles are intentionally unequal in what they may touch. Only the executor can edit files. Every other agent operates read-only, whether it is researching, planning, reviewing, or verifying. This keeps the agent that proposes work separate from the agent that performs it, and the agent that performs it separate from the agent that checks it. The result is a built-in chain of accountability: nothing reaches the codebase without passing through an agent whose sole purpose is to write it, and nothing is declared done without a different agent confirming it.