# Scope The Work > Draws the boundary of one piece of work before it starts: what is in, what is explicitly out, what "done" means, and who decides if that changes. Trigger when the user says "scope this out", "what's actually in scope here", "define the boundaries of this project", "what counts as done", "before I start this, what am I actually committing to", "how do I stop this from growing", "what should I say no to", or describes work they are about to start or hand off and asks what to nail down first. Also trigger when a request has already grown once and the user wants to draw the line before it grows again. Writes the in list, the out list, the done condition, and names who can move the line, ending on a filled boundary note. Use pick-the-medium for how to communicate something and delegate for who does work already scoped; this is what the work actually is, before either question comes up. Not a legal statement of work, a boundary the person doing the work can hold themselves to. - Skill: `theanirudhkumar/scope-the-work` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add theanirudhkumar/scope-the-work` - Raw SKILL.md: https://api.skillmd.com/api/skills/theanirudhkumar/scope-the-work/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: theAnirudhKumar (https://skillmd.com/u/theanirudhkumar) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/theanirudhkumar/scope-the-work --- # Scope the Work Most scope creep is not a client or a stakeholder changing their mind. It is a boundary that was never written down in the first place, so there was nothing to point back to when the request quietly grew. The failure this exists to prevent: **work that keeps absorbing "one more thing" because nobody ever said what was outside it, so every addition looks reasonable in isolation.** That is not a discipline problem. It is a missing artifact, and it is written once, before the work starts, not re-litigated every time something new comes up. --- ## What this needs **Minimum: what the work is and roughly what "finished" would look like.** It will produce the in/out lists and the done condition from that, and mark what it had to assume. **Better with** who asked for this and what they actually need it for, since the done condition is only honest if it matches what the request is for, not just what was said. **Best with** a case where this same piece of work grew before, so the out list can name the specific thing that crept last time rather than a generic one. --- ## Step 1: Name the actual ask, not the topic "Redesign the onboarding flow" is a topic. "Cut onboarding drop-off by fixing the three screens where people are quitting" is an ask. A boundary drawn around a topic has no edge; a boundary drawn around a specific ask does. If the request as given is a topic, ask what the actual need behind it is before scoping it. ## Step 2: Write the in list What this piece of work actually covers, specific enough that someone could check a finished deliverable against it. Not aspirational, not everything that would be nice: only what this instance of the work commits to. ## Step 3: Write the out list The adjacent things a reasonable person might assume are included, named explicitly as not included. This is the list that does the real work later: when one of these comes up mid-project, it is not a surprise, it is something already named and set aside. ## Step 4: Write the done condition One sentence that is checkable, not a feeling. "Done" is not "it looks good" or "everyone's happy with it"; it is a condition someone else could verify without asking the person who did the work whether it counts. ## Step 5: Name who moves the line If something on the out list turns out to actually be necessary, someone has to be able to say so and move it into scope on purpose, rather than it sliding in unnoticed. Name that person or that role. Without this, the out list is decoration: everything eventually gets added because nobody was ever positioned to say no on the record. ## Step 6: Output the boundary note In list, out list, done condition, who moves the line. Short enough to reread in under a minute when something new comes up mid-work, because that is the moment it actually gets used. --- ## Output A filled boundary note: in, out, done, who decides changes. Not a project plan, not a timeline, not a full SOW. ## Failure modes to watch for **An out list with nothing on it.** If nothing was excluded, nothing was actually scoped, and the in list was probably written at topic level, not ask level. Go back to Step 1. **A done condition that only the requester can judge.** "When it feels right" or "when they're happy" cannot be checked by anyone else and will not survive a disagreement later. Push for something a third party could verify. **Naming "we" as who moves the line.** A boundary nobody specifically owns is a boundary nobody enforces. Name a person or a named role, not a group. ## What this does not do Decide who performs the work once it is scoped; that is delegate's job, working from this skill's own in list. Does not produce a formal statement of work, a contract, pricing, or legal terms; this is a working boundary for the person actually doing or overseeing the work, not a client-facing document. Does not estimate how long the work will take; a skill built for that is a separate concern from what the work covers. ## Supporting files - `assets/boundary-note.md` - a one-page fill-in template: the ask, in, out, done condition, who moves the line.