Confirm the checkout in the first minute
A project name is not enough to distinguish a clone, fork or worktree. Ask for the absolute path, branch, current commit, dirty files and relevant repository instructions. Compare that report with the checkout you meant to use before any edit.
Read-only baseline
pwd
git status --short
git branch --show-current
git log -1 --oneline
# Read project instructions and the files involved in the task.Give a bounded task
- Name the user-visible outcome and files or areas in scope.
- State any data, dependency or deployment constraints.
- Specify acceptance checks, including the main error case.
- Choose a branch or separate worktree if other edits are in progress.
- Make publication and external writes explicit decisions.
Reusable request
Inspect the selected project first. Goal: <OUTCOME>.
Scope: <FILES OR AREA>. Constraints: <LIMITS>.
Success: <OBSERVABLE CHECKS>.
Before editing, report path, branch, commit and dirty files.
After editing, show the diff, test results and anything unverified.Read the diff before accepting the answer
The agent’s completion message is a map of its work, not proof that the patch behaves correctly. Record the commit or diff that the tests actually covered.
- Compare all changed files to the stated scope, including generated and untracked files.
- Check dependencies, lockfiles, configuration, permissions and secrets.
- Run the project build and relevant tests on the final combined state.
- Try the user flow manually, including the important failure path.
- Resolve unexplained changes and ask for independent review when impact is high.
Branch or worktree?
A branch in the current checkout is enough for one serial, short change. A separate worktree keeps simultaneous tasks from writing to the same files. In either case, give each task a clear owner and integrate one patch at a time before re-running tests.