task-scope-clarifier

Restate the request as one observable outcome, then define explicit in-scope and out-of-scope items, likely affected files, and testable acceptance criteria. Inspect only the minimum repository context needed to confirm the boundary before writing the task.

List plausible adjacent work such as unrelated refactors, redesigns, or dependency upgrades as explicit exclusions before editing. Keep baseline correctness, accessibility, and security obligations in scope only where the requested change touches them.

Skip scoping when the request already includes a precise, bounded task with testable acceptance criteria, or when you need a full project brief, roadmap, or architecture decision instead. It is also unnecessary when no meaningful ambiguity remains.

Acceptance criteria should be observable and testable statements covering the success path, necessary failure or edge behavior, preserved existing behavior, and relevant validation. Avoid prescribing implementation details unless the repository contract requires them.

Start from files, symbols, and behaviors named in the request, then use targeted searches for direct callers, tests, and docs. Label each path as confirmed, likely, or possible, and distinguish files to inspect from files to edit.