Extend it yourself.

By the end of this part, a feature that nobody gave you a prompt for will be live at your link. You’ll choose it, plan it with your agent, write the prompts that build it, and publish it yourself.

You start with the published app from Part 9, the “Later ideas” you noted in Part 3, and everything you’ve set up along the way: a root file, handbooks, tests and checkpoints. The examples show the feature our reference app added, a way to sort the list. Yours will be different.

1. Choose an idea that fits

Open docs/flows.md and find your “Later ideas”. Pick the one you would most like to have.

Before anything is planned, your agent checks the idea against docs/api.md, the description of every message the server answers. Your agent may not change the supplied stand-in server, which has been a rule since Part 6. So an idea fits only if the client can do it alone, using the messages and the book details the server already has. Two examples show the difference:

• A sort order fits. The server already sends every book with its title and author. The client can show those books in any order it likes without asking the server for anything new.
• A star rating does not. A book has a title, an author, a note and a status, and nothing else. There is nowhere to keep a rating, and adding a place would mean changing the server.

If your idea is refused, the agent should tell you what it would have needed from the server, and that answer is worth having. Anything the app must remember about a book, share between people or know about who is using it is the server’s job. Arranging, counting, choosing from and displaying what the server already sends is something a client can do alone. You’ll meet the same question in any app you work on.

The prompt asks for that check and for one sentence you both agree on. Put your idea in the brackets.

Read docs/epics/07-extend.md and do Stage A only. From the Later ideas in docs/flows.md, the one I want is: [your idea]. Check it against docs/api.md and tell me whether the client can do it alone, and why. If it can't, help me find a version of it that can, or offer me ideas that do fit. When we agree, state the idea in one sentence and stop. Do not write an epic or build anything yet.

When it stops you should have a yes with a reason that mentions the API, and your idea in one sentence.

If none of your ideas fits, the agent will offer some that do. These four all work with the server as it is: a sort order for the list, a count of books for each status, a button that picks your next book to read, and a compact view of the cards. Choose one, or let them prompt a better idea of your own.

2. Write the epic together

Every piece of work so far has come from a file in docs/epics/ that we wrote: a plan with an outcome and a list of tasks to tick. Now you write one. “Epic” is this project’s word; the tools themselves call it a plan or a spec.

Your project has a handbook for this, docs/handbooks/epics.md, and your root file points the agent to it. It asks for three things:

• One outcome, as something you can see or do.
• Tasks that can each be checked. “Add a Sort by control with the brand pack’s label” can be checked. “Improve the list” cannot.
• What is out of scope, so that the work has an edge. This is where tempting extras go.

Here is how those look in our reference epic, 08-sort-order.md, shortened:

Outcome: the person can show their books newest first, by title or by author, and go back again.

• Add the wording to the brand pack: the label Sort by and the three orders.
• Add the order to docs/flows.md, in the View books flow and the main page’s wireframe.
• Add the sorting itself, beside the search and the filter.
• Add a labelled Sort by control beside the search field, styled only from the tokens.
• Check that remove and undo still put a book back in the right place while the list is sorted.
• Add one unit test for the sorting and one browser journey that tries each order.
• Ask the person to add three books and try each order.

Out of scope: remembering the chosen order after a refresh, sorting by status, reversing an order, and anything that would need a new message or a new field from the server.

The prompt asks the agent to follow the handbook, to let you describe the outcome first, and to build nothing.

Do Stage B of docs/epics/07-extend.md. Follow docs/handbooks/epics.md to write a new epic with me for the idea we agreed. Ask me to describe the outcome in my own words before you suggest anything. Keep it short, save it in docs/epics/ with the next number, and show it to me. Change it until I say it is what I meant. Build nothing yet.

Read what it writes, slowly. This file is what the agent will build from, so now is the cheap time to change your mind. Ask yourself three things:

• Could I check each task myself, or ask the agent to show me that it’s done?
• Is there a task for new wording in the brand pack, a task for tests, and a last task that is my own check in the browser?
• Does “out of scope” name the extras I was tempted by?

If the epic runs past ten tasks or so, the idea is bigger than it looked. Ask the agent to split it in two and keep the first half.

3. Build it with your own prompts

Now you write the prompts. In Part 6 you saw that a bounded prompt has three elements: what to build, what to leave alone and what to tell you when finished. Add which epic and which tasks, and you have everything a prompt in this project needs.

Here is a first prompt for the sort-order epic. It is an example to read, not one to paste:

Read docs/epics/08-sort-order.md and do its first four tasks only: the wording, the flow, the sorting and the Sort by control. Take the labels from the brand pack and every value from the tokens. Do not change anything in src/server, and do not write the tests yet. When you finish, stop, tell me exactly what to try in the browser and wait for my feedback.

Look at how it is put together before you write yours:

Write the first prompt for your own epic the same way, and send it. You don’t have to get it right first time. Epic 07 tells the agent that if your prompt doesn’t say which epic and tasks to work on, when to stop or what to check, it should say what is missing and let you rewrite it, and not fill the gap by guessing. If it asks, rewrite the prompt and send it again.

When the agent stops, try the feature in the browser exactly as it tells you to, and then try something it didn’t mention. For the sort order we added three books, tried each order, then removed a book while the list was sorted by title and chose Undo, to see that it came back in the right place. If something is wrong, use the three-part report from Part 6: what you did, what you expected, what happened instead.

Then write your second prompt, for the remaining tasks. It will usually be the tests. When they pass, you can watch your new journey in the visual runner from Part 8, under the name you’d expect from your epic.

4. Save it, publish it, see it live

You have done each of these before. The two requests are yours to write, and the upload is yours to do.

1. Save a checkpoint in your usual sentence, with a name that says what the app can now do. Your handbook runs every test first, old and new, so you’ll know the new feature hasn’t broken an old one. If a test fails, the checkpoint stops; ask what failed and get it fixed before going on.
2. Ask for a new production build and the dist folder to upload. A good prompt says what to leave alone: nothing is to be published for you. If you left the style-guide page out last time, say so again.
3. Upload the new dist to the same site, as in Part 9: open your site in Netlify, go to its Deploys page and drag the folder onto it.

Then open your link and use the feature there.

5. Close the epic

A conversation is temporary. A new one starts with nothing that was said in this one, and knows only what the project’s files say. Closing an epic means making those files tell the truth. The epics handbook says what closed means: every task is ticked and each tick stands for something that was checked; anything you dropped is moved to “out of scope”; and docs/progress.md describes the project as it is now.

Ask your agent to close your epic as the epics handbook describes, and tell it in the same message what you checked at your published address, so that your own check can be ticked too.

Then test the result the honest way. Start a new conversation, as you first did in Part 2, and ask:

What's left to do in this project?

An agent that has seen none of your work should tell you that your feature’s epic is closed and nothing in it is open. It will probably add that epic 07 still has two stages to go: tidying the root file, which is next, and making a skill, which is optional. If it gets your feature wrong, thinking a finished task is open or not knowing the feature is published, the files are out of date. Say what is true and ask it to correct the epic and docs/progress.md.

6. Read your root file from top to bottom

Your root file, AGENTS.md, is read at the start of every conversation, and it has grown three times: who you are in Part 2, a standing rule in Part 6 and a handbook in Part 7. Instructions go stale. Your About the person section may no longer be true of someone who can now explain a request and a status code, and the standing rule you added in Part 6 may be one you no longer want. The agent takes every line as a current instruction, so a line that is no longer true is worth removing.

The prompt asks the agent to go through the file with you a section at a time and to remove only what you agree to remove.

Do Stage D of docs/epics/07-extend.md, apart from publishing, which I have done. Read AGENTS.md from top to bottom with me, one section at a time. For each line, ask me whether it is still true and still needed. Remove what is not, and change nothing else without my agreement. Show me what changed when we finish. Then bring docs/progress.md up to date, and record that I have used the new feature at my published address.

It is fine to finish with little or nothing removed; a file that is still true needs no tidying. What you are practising is reading it, because you are the only one who knows whether it is still true. Save a checkpoint when you’re done.

7. Optional: call your checkpoint by name

Everything above is complete without this step. Take it if you’d like to see one more way of keeping an instruction, and stop without worry if your tool won’t allow it.

You already save a checkpoint with one sentence, because your root file points the agent to the handbook. A skill lets you call the same routine by name. A skill is a small folder holding one file, SKILL.md, which has a name, a description of when to use it, and the instructions. The description is also how the agent knows to use the skill when you ask in plain words. Both tools use the same format. They keep the folder in different places and call it differently:

• Claude Code: .claude/skills/checkpoint/SKILL.md, called by typing /checkpoint.
• Codex: .agents/skills/checkpoint/SKILL.md, called by typing $checkpoint, or /skills to choose from a list.

The instructions don’t need to repeat your handbook. This is the whole file in our reference project:

---
name: checkpoint
description: Save a checkpoint of the reading-list project. Use when the person asks for a checkpoint, to save their progress or to commit their work.
---

Follow `docs/handbooks/checkpoint.md` from start to finish.

The routine keeps its single home. If you amend the handbook again, as you did in Part 8, the skill follows.

Do Stage E of docs/epics/07-extend.md. I use [Claude Code or Codex]. Create the checkpoint skill in the folder my tool uses. Keep the file tiny: a name, a description of what it does and when to use it, and one sentence telling you to follow docs/handbooks/checkpoint.md. Show me the file, tell me how to call it, then stop.

Expect to be asked for permission. Each tool guards its own skills folder more closely than the rest of your project, so the agent will ask before writing there, or tell you it isn’t allowed to. Read the request. If it is to create the one file named above, inside your project, approve it.

If it is refused, or the agent can’t create the file, stop here. Nothing is lost: the handbook works exactly as before from the sentence you already use. Ask the agent to note in docs/progress.md that the skill was not made, so that a later conversation doesn’t think it is unfinished work.

If the file was created, there is something new to save, which makes this a good moment to try it. Start a new conversation and type /checkpoint in Claude Code or $checkpoint in Codex. You should see your usual routine begin with the tests, then a note of what changed, which is the new skill, then a request for a name.

Where each instruction belongs

Across these ten parts you have put instructions in five different places. Knowing which place suits which instruction is most of what it means to work with an agent, and not just prompt one.

The signal to move something up from the conversation is repetition. The second or third time you find yourself typing the same thing, ask where it belongs.

What you can do now

You have an app online that you planned, branded, built, tested and extended, and you can explain how it works. More usefully, you know how to go about the next one: decide what you want and write it down, settle the look once, understand the parts before building, ask for one bounded piece at a time, check every result yourself, save what works, and keep the project’s files true so that any new conversation can pick up where the last one stopped.

There is more to both tools than you have used here, such as subagents, hooks, plugins and settings files. A project this size needs none of them. When you’re curious, start with the cheat sheet in Further reading, which sets the two tools’ commands side by side.

The reading list has no accounts and no real server, which is where most real apps get harder. Building RepGarden follows a real web and mobile app being built for Benji, a personal trainer, with accounts, a real server and everything that comes with them. You’ll recognise the way of working, and you’ll see what changes when the server is no longer a stand-in.

FAQ

Further reading

• The slash commands I use in Claude Code and CodexGadirLabs

  The commands for both tools side by side, such as planning first, going back and changing the model, and how to write a handoff note before you clear a long conversation.

• Building RepGardenGadirLabs

  A real web and mobile app for a personal trainer, documented as it is built: designs, accounts, a real server, testing and launch.

• Best practices for Claude CodeAnthropic

  Written for developers and about Claude Code only, so expect unfamiliar examples. The sections on planning before building and on keeping the root file short, which it calls CLAUDE.md, will read as familiar advice, and it introduces hooks, subagents and plugins in a paragraph each.