Implement a small feature

Goal

Complete a narrowly scoped software change and review the code diff, test results, and remaining risks before delivery.

Before you begin

Complete Understand an existing project first, or at least identify the relevant modules and test entry points.
Use Git or another method to preserve a clean baseline. Captain Who is not a replacement for version control or backups.
Confirm that the project's existing tests can run locally.
For a first exercise, use Default permissions so file changes and commands wait for your confirmation at important points.

Steps

1. Define the acceptance criteria

Choose a small but complete requirement, such as fixing a display issue, adding validation, or extending an existing interface. For example:

text

Add behavior that restores the full list when the search box is cleared.

Acceptance criteria:
- The clear button appears only when the input is not empty.
- Selecting it clears the query and returns focus to the input.
- The Escape key also clears the query.
- Add tests that cover all three behaviors.
- Do not change the search algorithm or styles on other pages.

Inspect the current implementation and tests first, then propose a short plan. Make changes only after confirming the scope. When finished, run the smallest relevant tests and summarize the diff.

For a real task, replace the example with your own requirements, boundaries, and observable outcomes.

2. Review the plan before allowing changes

Check whether the files the Agent identified are reasonable and whether it missed the data layer, protocol, or tests. If the plan clearly expands the scope, ask the Agent to narrow it before a large diff is produced.

3. Handle approvals one at a time

When the Agent proposes a file patch, write, or command, the approval card shows a safety summary. Pay particular attention to whether:

the path belongs to the current project;
the change touches credentials, build and release systems, or unrelated modules;
the command installs dependencies, deletes data, or accesses the network;
Don't ask again for this turn is genuinely appropriate for later operations of the same type.

If you are unsure, reject the request and ask for a narrower method in the reason.

4. Request the smallest validation

Have the Agent first run the tests, type checks, or static checks directly related to the change. Expand to the full suite only when necessary so unrelated historical failures do not obscure the current assessment.

5. Review the change yourself

Inspect the final diff in Review in the right sidebar or in your external Git tool. Check for debug output, unintended formatting, generated files, or unexplained behavior changes.

You can continue with:

text

Review your work using the current actual diff. Map each acceptance criterion to verified evidence, then list anything not verified and any possible regression risks. Do not make further changes.

Expected result

The final delivery includes a limited, explainable code diff, corresponding tests, validation results that were actually executed, and limitations that have not been hidden. “Tests were written” and “tests were run and passed” must be reported separately.

Troubleshooting

The change grows out of scope: Stop the current Run, preserve the existing result, and start a new conversation with smaller acceptance criteria.
A file conflicts with another change: Do not overwrite it repeatedly. Reread the latest file and have the Agent produce a new change based on the current version.
Tests fail: First distinguish failures introduced by this change from failures that already existed, then decide whether to fix or record them.
A command result is unknown: Do not immediately repeat a command that might have side effects. Check the actual files, processes, or external system first.
The model merely claims completion: Request the diff, test output, and file locations. Without evidence, treat the task as incomplete.

For more complex requirements, see Manage large projects and Use multiple Agents in parallel.