Implement Small Change

Use the smallest workflow that can prove the requested behavior without hiding risk.

1. Establish the boundary

Before editing:

1. Read the applicable repository instructions and inspect the current Git status/diff. Preserve unrelated user changes.
2. State the requested observable outcome in one sentence and identify the smallest check that could prove it.
3. Discover the repository before deciding that the change is small. Prefer the user's currently available local MCP or other repo-aware tools over the agent's built-in file search:
   • If a codebase knowledge graph MCP is available, use it first. If the repository is not indexed, complete that tool's required indexing or setup before querying it; then prefer its graph search, dependency or caller tracing, targeted code retrieval, and architecture or relationship queries to establish the affected symbols and blast radius.
   • If another local repo-aware MCP or repository navigation tool is available, use it before rg, globbing, or broad file reads.
   • Fall back to the agent's built-in tools only when no suitable MCP/repo-aware tool is available, or when those tools return insufficient, stale, or inapplicable results. Built-in search remains appropriate for string literals, configuration, scripts, and other non-code files that the graph does not model.
   • Follow repository-specific discovery instructions and use the strongest available source of evidence; do not assume a tool is available merely because it is named in documentation.
4. Locate the exact symbols or configuration involved. Inspect relevant callers, callees, tests, contracts, and runtime path using the selected discovery tools.
5. Classify semantic impact. Do not classify by file count alone; a one-line shared-contract change can be broad, while several colocated files can still be one local change.

Do not ask the user for facts that can be discovered from the repository, runtime, logs, or tools.