Build a new app from an empty folder
You will build a small habit tracker: add daily habits, mark them done, and watch your streaks grow. It runs entirely in the browser and saves to localStorage, so there is no database or backend to set up. You will not write the code yourself. Instead you drive the agent through Define, Plan, Build, Verify, Review, and Ship. Pick any stack when the spec asks, even plain HTML, CSS, and JS. The goal is to feel what each skill buys you.
Pressure-test the idea before any code
Interview me about a habit tracker I want to build. Ask one question at a time until you are ~95% sure what I actually want, then stop. Cover which habits, daily vs weekly, how a streak works, what a missed day does, and that data stays on this device. The agent asks one focused question at a time and refuses to start building until the intent is clear.
A habit tracker sounds obvious until you hit the edge cases: what counts as a streak, what a missed day does to it, timezones, and whether data lives only on this device. A few questions now save a rebuild later.
Write the spec
Follow the spec-driven-development skill. Write a SPEC.md for the habit tracker: objectives, the localStorage data model, the core screens and states, the streak rules, testing strategy, and explicit non-goals. The agent produces a SPEC.md covering objectives, the data shape, screens, streak rules, testing, and boundaries.
You review a short plan in a couple of minutes instead of chasing decisions through 2,000 lines of generated code later. The data model and streak rules are exactly what you want pinned down before any UI exists.
Break it into small, ordered tasks
Follow the planning-and-task-breakdown skill. Turn SPEC.md into small, verifiable tasks with acceptance criteria and dependency ordering: add a habit, mark a day done, compute streaks, show stats, persist to localStorage. Write them to tasks/plan.md. The agent decomposes the spec into thin, independently shippable tasks with clear done criteria.
Small tasks are the unit you can actually verify. They stop the agent from writing one giant blob you cannot review.
Build the first slice, test-first
Follow incremental-implementation and test-driven-development. Implement the first task: computing a streak from a list of completed dates. Write the failing test first, cover the edge cases (a missed day, today not done yet), make it pass, then commit. The agent writes a failing test for the streak logic, implements just enough to pass, runs it, and commits that slice.
Streak math is where the bugs hide, so it is the perfect thing to drive with tests. Each slice arrives tested and committed on its own, so a bad change is one revert away.
Design the storage contract and the UI
Design the localStorage module contract first: load, save, the data schema, and what happens when stored data is missing or from an older version. Then build a minimal, accessible UI: a list of habits, a way to mark today done, and a streak display. Keep it production-quality. The api-and-interface-design and frontend-ui-engineering skills activate automatically for these tasks.
A clean storage contract keeps persistence out of your UI, and WCAG-aware components are exactly where agents cut corners. The skills hold the line so the output is not AI-generated slop.
Prove it works with real runtime data
Run the full test suite. Then verify in a real browser: mark a habit done, confirm the streak updates in the DOM, and reload to confirm it persisted in localStorage. If you have the Chrome DevTools MCP configured, browser-testing-with-devtools will capture the DOM and network for you; if not, click through it yourself. The agent runs the suite, and captures browser evidence via the Chrome DevTools MCP if it is configured, otherwise walks you through the check by hand.
"Seems right" is never enough. You want to see the streak update and the data still there after a refresh, as evidence. The browser-testing-with-devtools skill automates that when the MCP is available.
Review before you call it done
Follow code-review-and-quality across all five axes, then run security-and-hardening focused on rendering user-entered habit names safely (no XSS) and on validating data loaded from localStorage, which is untrusted and can be tampered with or corrupted. The agent reviews correctness, readability, architecture, security, and performance, and hardens how user input and stored data are handled.
Habit names are user input rendered into the page, a classic XSS footgun, and localStorage is an untrusted boundary. This is the step that catches both before a user does.
Ship with a go / no-go
Follow the shipping-and-launch skill. Produce a pre-launch checklist, put a new habit-type behind a feature flag, plan a deploy to any static host, and write the rollback steps. Then give me a go or no-go. The agent runs a pre-launch checklist, sets up a flag and a static deploy plan with rollback, and returns an honest recommendation.
Shipping is a decision, not a vibe. A static app still deserves a checklist, a reversible flag, and a rollback path, then you make the call.
A working, tested, reviewed habit tracker that runs entirely in the browser and remembers your streaks, plus the artifacts that made it safe: SPEC.md, a task plan, tests, and a launch checklist. You reviewed a decision at every phase instead of a wall of code at the end.