Build in parts

Before the loop: DEV_PLAN.md as the guide

In the previous chapter you created the DEV_PLAN.md: a file with numbered phases, each with an objective, deliverables, and acceptance criteria. It is the source of truth for this chapter. Before writing any code, open the file and find the first phase with status TODO.

The agent should always read DEV_PLAN.md before starting a phase. When the phase is done, you mark it as DONE in the file. That state is visible, auditable, and prevents the agent from repeating work or skipping steps.

The loop for each phase

You already have a DEV_PLAN.md split into phases. The goal of this chapter is simple: show the loop you repeat starting with phase 1 and moving phase by phase until the full plan is complete.

Do not take the whole plan and ask the agent to build everything at once, and do not pick a random phase just because it looks easier. You start with phase 1. When phase 1 is done with validation and a commit, go back to DEV_PLAN.md, mark it as DONE, pick phase 2, and repeat.

1. Open DEV_PLAN.md and focus only on phase 1 or the next phase with status TODO
2. Review and refine that phase before execution
3. Ask the agent to create the PRD for that phase
4. Switch the tool to PLAN mode
5. Ask for an execution and validation plan based on that PRD
6. Return to normal mode and implement the phase
7. Test and validate against the PRD
8. Commit, mark the phase as DONE in DEV_PLAN.md, and move to the next one

1. Read DEV_PLAN.md, review the phase, and create the PRD

The first step in the loop is to open DEV_PLAN.md and take phase 1. In later cycles, always take the next phase with status TODO. Before writing any code, check whether that phase is clear enough. If it is vague, too large, or missing testable criteria, refine it first.

Then ask the agent to turn that phase into a specific PRD. The PRD is the execution document for the phase: what is included, what is excluded, how it should work, and how you will validate it. Once phase 1 is closed, you repeat exactly the same process for phase 2, and so on.

I want to execute phase [PHASE_NAME] from the DEV_PLAN.md.

If this is the first cycle, start with phase 1.
If phase 1 is already done, use the next unfinished phase.

Before writing any code, read:
- DEV_PLAN.md
- ROADMAP.md
- AGENTS.md or CLAUDE.md

TASK
Analyze phase [PHASE_NAME] from the DEV_PLAN.md, refine anything vague, and create a PRD for that phase.

Create this file:
- docs/prd/[PHASE_FILE].md

The PRD must be in English and include:
- Goal
- Scope
- Out of scope
- User flow
- UI states
- Technical notes
- Acceptance criteria
- Manual validation
- Risks / open questions

IMPORTANT RULES
- focus on a single phase
- do not invent scope outside the DEV_PLAN.md
- if the phase is too large, point that out before proceeding
- do not implement anything yet
- generate only the final PRD content

2. Switch to PLAN mode

Once the PRD is ready, do not ask for code yet. First, switch the tool to PLAN mode and ask for a plan to execute and validate the current phase.

This forces the agent to think before acting: which files it will touch, which order makes sense, what the risks are, and how to prove the phase is complete. You do this for phase 1, then repeat it for phase 2, and keep going until the DEV_PLAN.md is fully done.

I am now going to execute phase [PHASE_NAME].

I am following the DEV_PLAN.md one phase at a time.

Read these files:
- DEV_PLAN.md
- ROADMAP.md
- AGENTS.md or CLAUDE.md
- docs/prd/[PHASE_FILE].md

I am switching the tool to PLAN mode.

TASK
Create an execution and validation plan for this phase.

The plan must include:
- implementation sequence
- files likely to be changed
- technical risks
- how to validate locally
- PRD criteria that must be checked at the end

IMPORTANT RULES
- do not implement yet
- keep the plan small and executable
- use the PRD as the main source of truth for this phase
- if the PRD is vague, point that out before proceeding

3. Execute, test, and validate

Only after the PRD and the phase plan are ready should implementation begin. At that point you already have clearer scope, criteria, and validation, which reduces invented scope a lot.

The focus is still one phase only. Do not mix two phases in the same cycle. Close the current one first, then move forward.

4. Generate the report and move to the next phase

When the phase is implemented and validated locally, close the cycle with a report. That report becomes project memory: what was built, what changed, how it was validated, and what remains open.

After that, go back to DEV_PLAN.md, mark the phase as DONE, and open the next phase with status TODO. That is how you move from phase 1 all the way to the last phase without losing clarity.

Phase [PHASE_NAME] has been implemented and validated locally.

After this report, I will mark this phase as DONE in the DEV_PLAN.md and move to the next unfinished phase.

Use these files as context:
- DEV_PLAN.md
- ROADMAP.md
- AGENTS.md or CLAUDE.md
- docs/prd/[PHASE_FILE].md

TASK
Create this file:
- reports/[PHASE_SLUG]-report.md

The report must be in English and include:
- summary of what was implemented
- files created or changed
- technical decisions made
- how the phase was validated
- PRD criteria that were satisfied
- problems found and how they were resolved
- pending work or limitations for the next phase

IMPORTANT RULES
- write objectively
- do not invent results that did not happen
- if something in the PRD was not completed, make that explicit
- generate only the final report content

git add .
git commit -m "[summarize what changed in this chapter]"
git push