Build a small project from a brief to a checked result

Last checked and updated: September 8, 2026. Editorial and source review; exercises below are authored practice, not reported benchmark runs.

Build the expense summary from your project brief. You need that SPEC.md and a coding agent working in the practice folder. The Claude Code setup lesson covers one option.

Your result will be a local page, a repeatable check, and instructions someone else can follow. Public deployment is a separate decision. There is no requirement to finish in a weekend or to use two agents.

Give the build an exact input

Use this fictional data:

[
  { "category": "food", "amount": 12.50 },
  { "category": "food", "amount": 7.50 },
  { "category": "travel", "amount": 5.00 },
  { "category": "supplies", "amount": 10.00 }
]

Before the agent starts, calculate the expected result yourself: food 20.00, travel 5.00, supplies 10.00, and a grand total of 35.00. These are expected values for this fixture, not measurements from a model run.

Build the smallest usable version

Send this after reviewing the plan:

Implement the local expense summary described in SPEC.md using the sample rows.
Keep all work in this practice folder. Do not change SPEC.md to fit your code.
Do not add network calls, accounts, payments, uploads, or deployment.
Show totals by category and the grand total with two decimal places.
Keep the input easy to replace for the empty and invalid-input checks.
Run the checks from the brief. Record the command and actual result.
Explain how I can open the page and repeat the checks.

Review any proposed installation before proceeding. If the agent says it cannot run a check, keep that limitation visible and run the check yourself if you can. An unexecuted test is not a passing test.

Check the result from the outside

Open the page using the supplied instructions. Work through these cases:

Input	Expected behavior
The four sample rows	Category totals 20.00, 5.00, and 10.00; grand total 35.00
Empty list	A clear empty state and total 0.00
A row with amount `"unknown"`	An explicit error identifying the invalid amount; no silently accepted total
Food rows changed to 1.25 and 2.75	Food total 4.00; the remaining categories unchanged; grand total 19.00

The final case helps catch a page that merely prints the expected numbers. The result must change when the input changes.

For each case, save what you supplied and what happened. Check a phone-sized window too: the category names, totals, and errors should remain readable without sideways scrolling.

If something fails, describe the observed mismatch:

With the two food amounts changed to 1.25 and 2.75, the page still shows 20.00.
The expected food total is 4.00 and the expected grand total is 19.00.
Find why the displayed totals do not follow the input, fix it,
and rerun all four checks from the brief.

That gives the agent evidence to investigate. It also protects you from accepting a fix that only changes the displayed number.

Use a handoff only when it helps

If you already use Hermes for planning, it can help draft or review SPEC.md. Give the same approved file to the coding agent. Avoid passing a long conversation when a short file contains the decisions the next tool needs.

Use ordinary requests such as “Read SPEC.md and list requirements that the implementation does not satisfy.” This exercise does not require special /write-spec or /verify-spec commands. Those names would need installed custom skills; do not assume they are built in. Hermes documents how skills are defined and loaded in its skills guide.

A second agent’s review is another source of findings. It does not replace opening the page or running the checks. One tool is sufficient when it can perform the task and you can inspect the evidence.

Package what you made

Ask for a short README.md containing:

How to open the local page.
Where the sample input lives and how to change it.
How to repeat the checks, including the changed-input case.
What is intentionally absent, such as real expense import and persistence.

Then follow those instructions yourself from a fresh terminal or browser window. Correct anything that assumes hidden knowledge from your conversation.

You are finished when the four checks pass, the page is readable, and the instructions let another person repeat the result. Save the project and its evidence. You have a small working artifact you can improve, not just a screenshot of something that looked done.

Return to the first-project path to review your work. If you want to make a project for other people next, read the niche-directory demand exercise before choosing a larger scope.