Add a feature

You are helping me improve a project that already exists. Today's goal is to add a new feature, planned with me first and built in small steps. Work through the steps in order and explain each in a sentence of plain English. Apart from installing the tools listed below on a separate branch, never change anything until I have agreed to it.

1. **Understand the project.** Read the code and tell me in two sentences what it is and how it runs. Then ask me, in one message: what the new feature is, who it is for, and what they should be able to do afterwards that they can't today. Wait for my answers.
2. **Work safely.** Check that git has no uncommitted changes (if it does, ask me what to do), and that git has a name and email set (if not, ask me and set them for this project only). Then switch to a branch called `improve/feature`, creating it if it doesn't exist, so everything can be undone.
3. **Install the tools**, for this project only, one line at a time. Skills copied in with git are pinned to the version that was safety-checked. If Claude Code refuses a line or a commit, tell me and show me the exact command so I can run it myself in a terminal, then carry on.
   - `d=$(mktemp -d) && git -C "$d" init -q && git -C "$d" fetch -q --depth 1 https://github.com/addyosmani/agent-skills.git 1401c8b8030e023baeebb31781a6653fe8e93026 && git -C "$d" checkout -q FETCH_HEAD && mkdir -p .claude/skills && cp -R "$d/skills/spec-driven-development" .claude/skills/spec-driven-development && rm -rf "$d"`: Writes a short spec you approve before any code: what the feature does, what it leaves out, and how you'll know it works.
   - `d=$(mktemp -d) && git -C "$d" init -q && git -C "$d" fetch -q --depth 1 https://github.com/addyosmani/agent-skills.git 1401c8b8030e023baeebb31781a6653fe8e93026 && git -C "$d" checkout -q FETCH_HEAD && mkdir -p .claude/skills && cp -R "$d/skills/incremental-implementation" .claude/skills/incremental-implementation && rm -rf "$d"`: Builds the feature in thin slices, testing each one, so nothing big breaks at once. It likes to commit on its own; the prompt makes it ask first.
   Commit the installed tools on the branch, so throwing the branch away removes them too.
4. **Agree what to build.** Read the parts of the project the feature touches. First ask me anything the answer depends on, a few questions at a time, and wait for my answers. Use what the installed tools say about doing this well; where a tool has its own workflow, stop at each of its checkpoints for my answer, and never let it start writing code before I have approved the plan. If a tool says to commit without asking, push, or merge into the main branch, ask me instead; never push. If a tool mentions other skills or files that aren't installed (like `tasks/plan.md`), skip them and follow this prompt. Also, if you notice anything urgent outside today's goal (lost data, a broken feature, a password or key in the code), list it under "Urgent, outside today's goal"; if a key or password was ever committed, tell me to rotate it, because deleting it does not remove it from git history. Then give me, in plain words: a short spec, at most one screen (what the feature does, what it deliberately leaves out, and how we will know it works), the parts of the project it touches, two or three ways to build it with their trade-offs and the one you recommend, and the build split into small slices, each one something I can try. If the feature needs something only I can choose (a service, an account, something that costs money), stop and lay out the options with their trade-offs instead of picking one. Stop and wait for me to approve the spec and pick a way. Then save the spec as `SPEC.md` and, with my OK, commit it, so it stays with the project.
5. **Build it a slice at a time.** First, before changing any behaviour, write tests that pin down how the parts you will touch work today (including loading any existing data files), so nothing that works now breaks unnoticed. If the project has no tests yet, use the simplest test runner it already supports and ask before adding one. Show me these tests in plain words and commit them once I agree. Then build only what I approved, one slice at a time, smallest working piece first. For each slice, show me what changed in plain words, add tests for it, and run the project's check (as `CLAUDE.md` describes it now). Never call a slice or the feature done until that check passes. If there is none, or something can only be checked by a person (looking at a page, a screenshot you cannot take, a speed test you cannot run), say so, measure what you can from the code, tell me exactly what to look at, and wait for my "looks good". Touch only what the slice needs, and ask before adding a dependency or changing the database, deployment or settings. If the plan turns out wrong partway, stop and tell me rather than quietly changing it. If a slice needs something only I can choose (a service, an account, something that costs money), stop and lay out the options with their trade-offs instead of picking one. Then wait for my OK before committing the slice with a clear message, and ask before starting the next. When every slice is in, review the whole change as if you had never seen it: compare it with `SPEC.md`; look for bugs, edge cases and input that could save bad data; check that everything that worked before still works the same way; check that no test was deleted, loosened or rewritten just to pass; and check security. List what you find (and anything outside today's goal under "Noticed, not touched"), fix only what I agree to, and commit each fix after I agree. If the feature changes how the project is run or used, offer to update `CLAUDE.md` and any README to match.
6. **Hand over.** What I end up with: The feature on its own branch: tests that pin down what already worked, a `SPEC.md`, the feature built and committed slice by slice with your approval, a fresh review of the whole change, and the check passing. Then tell me how to keep the changes (merge the `improve/feature` branch) or throw them away (delete it), with the exact commands.