Audit Existing Project Before Changing It
You get a staged audit of an existing codebase, with a short report you can check, instead of an agent that rewrites things at once. It works because the agent must inspect first, wait for your approval, change in small steps and then verify.
Struggled in our testThe reply was honest and used the four headings. It inspected nothing, made no changes and ran no checks, so steps 1, 3 and 4 were not done. It did give planned items with risks and completion tests, and it ended with the requested next task.
The prompt
Act as a careful senior engineer joining an existing codebase through a coding agent that can read files and run commands.
Task: Prepare {project_name} for better AI-assisted work without breaking what already exists. Preserve the current stack and conventions: {stack_and_constraints}.
Steps:
1. Understand: inspect the files, package manager, existing instructions, dependencies and current checks. Report only what you actually find.
2. Decide: propose improvements, each with its risk, its dependencies and a clear completion test. Wait for my choice before editing: {priorities}.
3. Configure: apply only the approved changes in small steps. Reuse existing files and rules rather than duplicating them.
4. Verify: run the available checks, compare before and after, and say what you could not test.
Output:
A short report with four headings: Findings, Approved changes made, Verification results, Pending work. Keep each to a few bullet points. Mark anything unverified as "unverified". Finish with the single best next task: {next_goal}.
Change the parts in curly braces. Use it when you hand an unfamiliar or half-configured project to a coding agent and want to keep its existing stack intact.
What happened when we ran it
We sent
Act as a careful senior engineer joining an existing codebase through a coding agent that can read files and run commands. Task: Prepare Hearth Bookings, a booking web app for three independent yoga studios for better AI-assisted work without breaking what already exists. Preserve the current stack and conventions: Node 20 with Express and a MySQL database, npm as package manager, no TypeScript, Jest tests that must keep passing, and no database migrations without my explicit approval.. Steps: 1. Understand: inspect the files, package manager, existing instructions, dependencies and current checks. Report only what you actually find. 2. Decide: propose improvements, each with its risk, its dependencies and a clear completion test. Wait for my choice before editing: Fix the missing lint setup, write a short README of how to run the app, and add a contributor instructions file for AI agents. Do not touch the payments code.. 3. Configure: apply only the approved changes in small steps. Reuse existing files and rules rather than duplicating them. 4. Verify: run the available checks, compare before and after, and say what you could not test. Output: A short report with four headings: Findings, Approved changes made, Verification results, Pending work. Keep each to a few bullet points. Mark anything unverified as "unverified". Finish with the single best next task: Reduce the risk in the booking confirmation flow, which currently has no tests.
The model replied
# Report
I have no file-reading or command-running tools in this session, so I have not inspected the project. I won't invent findings about the stack, scripts, or tests. Everything below is unverified unless it comes from the environment details.
## Findings
- The working directory is `C:\Users\mr3yn\OneDrive\Desktop\Repo Radar`, and it is **not a git repository**. Edits can't be reverted with git, so I'd take a backup copy first.
- The stack you described (Node 20, Express, MySQL, npm, Jest, no TypeScript) is **unverified** against `package.json`, the lockfile, `.nvmrc`, or `engines`.
- Whether any lint config, README, or agent instructions file already exists is **unverified**.
- Which Jest tests exist and whether they pass today is **unverified**. There is no baseline yet.
- I don't know where the payments code lives, so I can't yet confirm that nothing I change will touch it.
## Approved changes made
- **None.** Nothing was edited, because nothing was inspected.
- Planned, using your approved scope (each is small and reversible):
1. **Lint setup.** Risk is low to medium. Dependency: the existing ESLint config and `package.json` must be read first. Done when `npm run lint` runs and exits cleanly, or reports only pre-existing issues that I list without mass-fixing. It would exclude payments paths and add no auto-fix over existing code.
2. **README.** Risk is low. Dependency: the real scripts, env vars, and DB setup steps must be read first. Done when every command in it has been run or is marked unverified.
3. **`AGENTS.md` for contributors.** Risk is low. It would cover the stack, the commands, "no migrations without approval", "don't touch payments", and "Jest must pass". If `CLAUDE.md` or similar already exists, I'd extend that file instead of duplicating it. Done when each rule matches something found in the repo.
## Verification results
- Nothing was run, so there are no before/after results. All checks are **unverified**.
- Planned: run `npm test` before any edit and again after. Then run `npm run lint`, and finally confirm that the payments files are unchanged by comparing them with the backup.
## Pending work
- Please confirm that I can use file and shell tools in this directory, or paste `package.json`, the file tree, and the `npm test` output.
- Decide whether I should initialize git. I wouldn't do it without your say-so.
- Confirm where the payments code lives, so I can exclude it explicitly.
## Best next task
Reduce the risk in the booking confirmation flow, which currently has no tests. Start with characterization tests that pin down the current behavior (success, double-booking, and invalid input), using mocked DB access. Make no behavior changes until those tests pass.
Run on Claude Sonnet 5.5, 01 Nov 2026. Automatic check: 2 out of 5.
Mentioned for
Claude Code, Codex
Where it came from
Found on GitHub, shared by soumatheusgomes: soumatheusgomes/vibe-coding-toolkit.
This is our own version of the idea, written and tested by us. The original may differ.