Send and review your first task

Use a prepared workspace and an available provider. This illustrative prompt works without choosing a bug in advance:

Read the repository instructions and find the main application entry point.
Explain how a request or user action reaches it, with links to the relevant files.
Do not edit files, install dependencies, run servers, or delegate.
End with one small improvement I could review as a separate task.

Send it once. Follow the response and tool results in the conversation. If the agent asks for input or permission, read the requested action before responding.

Open the cited files. Check that the explanation follows the code and that the agent respected the task boundaries. An answer with file links is easier to inspect, but links alone do not prove the explanation correct.

Choose the proposed improvement only if you understand its scope. A follow-up can say:

Make that improvement in the files you identified. Preserve other edits.
Run the focused checks appropriate to the change. Explain what changed,
which checks ran, and anything you could not verify. Do not commit or publish.

Read the actual diff alongside the agent’s explanation. A confident summary is useful context; the changed lines are what you are reviewing.

If the change misses your intent, explain what needs to change in the same conversation. Keep the next request as specific as the first.

The following example shows the shape of a useful task and review. Its result is illustrative.

In README.md, clarify where the existing check command should run. Confirm the location from the repository before editing. Change only that instruction; do not commit or push. Return the diff and the evidence for the directory you named.

- Run the checks.
+ From the repository root, run the checks.

Success is a result you can explain and a clear decision to keep, revise, or discard it. Continue with Review and source changes, or learn about Roles. If a connection drops, see Troubleshooting before sending the task again.