task-scope-clarifier

Converts rough implementation requests into bounded tasks with acceptance criteria and affected files.

Updated Jul 7, 2026

Search Tags:#implementation planning #requirements #acceptance criteria #impact analysis #scope control #task scoping

Ready to run

npx skills add https://github.com/vmitsaras/Agent-Skills --skill task-scope-clarifier-vmitsaras

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: task-scope-clarifier
Source: https://github.com/vmitsaras/Agent-Skills/tree/main/skills/project-planning/task-scope-clarifier
Command: npx skills add https://github.com/vmitsaras/Agent-Skills --skill task-scope-clarifier-vmitsaras

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Vague change requests often lead to scope creep, speculative refactoring, and unclear completion criteria. This Skill turns a rough implementation request into a bounded, implementation-ready task before any code is edited. ## Core Features & Use Cases - Scope Definition: Produces a goal statement, explicit in-scope and out-of-scope items, and evidence-backed lists of files likely affected. - Acceptance Criteria & Risk Surfacing: Writes observable, testable acceptance criteria and distinguishes blocking risks from checks that can happen during implementation. - Use Case: A maintainer receives a bug report saying "fix the broken export button." Before coding, they run this Skill to confirm the intended behavior, identify the relevant component and tests, exclude unrelated UI polish, and define the first verification step. ## Quick Start Ask the agent to clarify the scope of your change request before implementation, for example: "Turn this bug report into a clear, bounded task with acceptance criteria and likely affected files."

Frequently Asked Questions about task-scope-clarifier

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I turn a vague feature request into a clear development task?▼

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.

How to prevent scope creep when implementing small code changes?▼

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.

When should I not use task scoping before implementation?▼

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.

What should acceptance criteria for a coding task include?▼

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.

How do I identify which files a code change will affect?▼

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.