The Phase Loop
Every piece of work in PP Core flows through the same repeatable cycle of five steps. That cycle is the phase loop, and the phase is the fundamental unit PP Core uses to break a project into pieces small enough to plan, build, and check with confidence.
Why the Phase Is the Unit of Work
A large feature handled as one continuous chat tends to collapse under its own weight. Decisions get buried, the model loses the thread, and nobody can tell whether the result matches what was asked. PP Core avoids this by slicing a project into phases that are each scoped to fit inside a single working session.
A phase is deliberately small. In practice it holds only a couple of atomic plans, each with a handful of tasks. That size is not arbitrary: it is the largest amount of work that can be reasoned about cleanly within one focused context window. Because every phase produces durable artifacts on disk, progress is traceable to files rather than to a conversation that will eventually scroll out of reach. A project, then, is simply an ordered list of phases recorded in ROADMAP.md, with each requirement in REQUIREMENTS.md traceable to the phase that satisfies it.
The Five Steps
Each phase advances through the same sequence: discuss, plan, execute, verify, ship. The steps run in order, and each one hands a written artifact to the next.
1. Discuss
The loop opens by establishing what the phase should actually do and how it should do it. Running /pp-discuss-phase walks through adaptive questioning to surface implementation preferences: which libraries to use, which patterns to follow, how to handle testing, and any constraints that matter. The output is a CONTEXT.md file containing numbered decisions, so every later choice can be traced back to an explicit agreement rather than an assumption.
2. Plan
With context locked, /pp-plan-phase turns intent into an executable strategy. This step performs research into the relevant approaches and then sequences the work into atomic tasks with clear acceptance criteria and dependencies. It writes a RESEARCH.md capturing what was learned and a PLAN.md describing exactly what will be built. The plan is concrete enough that execution becomes mechanical.
3. Execute
/pp-execute-phase carries out the plan. PP Core spawns executor agents that write the code and commit it, grouping independent tasks into parallel waves where the dependency graph allows. As work completes, the step records a SUMMARY.md documenting what was implemented, any deviations from the plan, and issues resolved along the way.
4. Verify
Execution finishing is not the same as the work being correct. The verify step confirms that what was built actually satisfies the requirements the phase set out to meet. Automated verification produces a VERIFICATION.md with a pass or fail verdict backed by evidence, and /pp-verify-work adds conversational user acceptance testing so a human can confirm the phase is genuinely ready.
5. Ship
The final step packages the verified work and prepares it for merge. /pp-ship creates a pull request, runs review, and advances the project state so the roadmap reflects the completed phase. Once a phase ships, the loop begins again on the next one.
The Loop in Practice
The artifacts form a chain that mirrors the steps:
CONTEXT.md → RESEARCH.md / PLAN.md → SUMMARY.md → VERIFICATION.md
(discuss) (plan) (execute) (verify)
Because each step writes its result to disk before the next begins, the loop is fully resumable. You can stop after any step, close the session, and return later without losing your place. The phase loop is what turns open-ended AI assistance into a disciplined, reviewable process: intent is captured before code is written, and code is held accountable to that intent before it ships.