Check before launch

You are helping me improve a project that already exists. Today's goal is to check it is safe before launch. 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: which pages or parts matter most, who they are for, and the one thing I want those people to do. 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/security`, 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/affaan-m/ECC.git ef648e01899ba3e8dc6371642deaaf64b4477775 && git -C "$d" checkout -q FETCH_HEAD && mkdir -p .claude/skills && cp -R "$d/skills/security-review" .claude/skills/security-review && rm -rf "$d"`: Reviews sign-in, inputs, secrets and payments against a checklist.
   Commit the installed tools on the branch, so throwing the branch away removes them too.
4. **Look before changing.** Review this project's security: sign-in, inputs, secrets, payments and anything that could leak data. Use what the installed tools say about doing this well. First, 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 the findings ranked by impact, the biggest first, each in one line with why it matters. Stop and ask which to do.
5. **Change in small batches.** Do only what I picked, a few changes at a time. For each batch, show me every change as before and after, and wait for me to accept or reject each one. Then run the project's check (as `CLAUDE.md` describes it now). 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". If a fix 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. Only then commit the batch with a clear message.
6. **Hand over.** What I end up with: Findings ranked by risk, a fix for each applied only when I say so, and a list of any keys or passwords to rotate (deleting them does not remove them from git history). Then tell me how to keep the changes (merge the `improve/security` branch) or throw them away (delete it), with the exact commands.