agent-scopinglisted

# Agent Scoping Decide what deserves to be built. Most requests for an agent should be answered with a different agent, a fix upstream, or nothing. ## When to use - Somebody asks for an agent, a skill, or an automation - Planning an AI roadmap for a GTM team - A previous build failed and the next one is being scoped ## Inputs - Reads: `workspace/audit/systems-audit.md` - Needs from user: the task in the form of what a person does today, how often, how long it takes, what a bad output costs, and who would use it ## Workflow ### 1. Run the refusal test first Four questions. A no on any of them means do not build it yet, and say why. **Is the input reliable?** An agent on top of a broken data layer produces confident, well-written, wrong output faster than a human could. If the audit put the data plane below 3, fix that first. This is the most common reason to refuse. **Is there a written quality bar?** If nobody can say what good looks like, the agent cannot be evaluated, and unevaluated output gets trusted by default. Write the rubric first. See `eval-spec-authoring`. **Is the task repeated?** Under roughly weekly, and the maintenance cost exceeds the saving. Do the thing manually. **Is somebody accountable for using it?** Not "the team would benefit." A named person whose work changes. Without one, adoption will be near zero regardless of quality. ### 2. Classify the work, because the class determines the build | Class | Characteristics | Build as | Expected corre