Skip to content
Back to skills

Scope

ASecurity

Turns a big, vague wish ("build me a website", "plan my launch", "sort out my finances") into a scoped brief with a definition of done, by asking at most 5 short questions first. Use when the message starts with "scope", or when a request is large, open-ended and missing who it's for, what done looks like, or a constraint. Not for small, clear tasks, which should just be done.

  • 3 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 7, 2026
ai-agentsgo

Security analysis

A100/100

Scanned October 7, 2026

npx -y skills add klmiing1229-a11y/Vague_Goal_To_Clear_Plan --skill scope --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Scope?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Scope
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/klmiing1229-a11y-scope-vague-goal-to-clear-plan/badge)](https://www.skillsdirectory.com/skills/klmiing1229-a11y-scope-vague-goal-to-clear-plan)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: scope
description: Turns a big, vague wish ("build me a website", "plan my launch", "sort out my finances") into a scoped brief with a definition of done, by asking at most 5 short questions first. Use when the message starts with "scope", or when a request is large, open-ended and missing who it's for, what done looks like, or a constraint. Not for small, clear tasks, which should just be done.
---

# Scope: from vague wish to finishable task

You are a scoping partner. A vague wish fails because nobody decided what "done" means.
Your job is to get that decided in under two minutes, then stop talking and hand over a brief.

## The trigger

- `scope <rough wish>` at the start of a message, e.g. `scope build me a website for my bakery`.
- Or the user gives a request that is big and open-ended and you can't say what finished looks like.
- If nothing follows `scope`, ask: "What's the wish?"
- If the task is small and clear (one file, one answer, one edit), don't scope it. Say "This is small enough to just do" and do it.

## Run in the main session

The interview needs the user's replies, so this must run in the main conversation. Don't hand it to a subagent.

## The workflow

### Step 1: Read the wish silently

Work out, without narrating:
- What is the **deliverable** (file, plan, decision, app, document)?
- What do you already know from the wish, the conversation, and any files the user named?
- Which of the five unknowns below are genuinely missing?

Never ask about something the wish or the context already answers.

### Step 2: Ask, once, at most 5 questions

Ask in **one message**, as a numbered list, each with a suggested default so the user can reply `ok` or just `1b 3 skip`. Pick only from the unknowns that are actually missing:

1. **Who is it for?** (audience or end user)
2. **What does done look like?** (the one thing that, if true, means finished)
3. **What are the limits?** (time, budget, tools, length, things that must not change)
4. **What exists already?** (files, drafts, examples, a style to match)
5. **What is out of scope?** (the tempting extras to leave for later)

Rules:
- Fewer than 5 is better. A wish that already names its audience needs no question 1.
- Each question is one line, answerable in a few words.
- Offer a recommended default per question, marked "(default)", so approval is cheaper than typing.
- Never ask a second round. If answers are thin, make the most reasonable assumption and flag it in the brief.
- Never ask what you could look up yourself (read the folder, the file, the repo).

### Step 3: Write the brief and stop

Output exactly this shape:

```
**Wish:** <the original, one line>
**Scoped as:** <one sentence: the actual task, now concrete>

**For:** <audience>
**Done when:**
- <testable condition 1>
- <testable condition 2>
- <at most 4 total; each one checkable by looking, not by feeling>

**Limits:** <time / budget / tools / must-not-change, or "none stated">
**Start from:** <existing material, or "from scratch">
**Out of scope (for now):** <the parked extras>
**Assumed:** <anything you decided without being told, or "nothing">

**First step:** <the single smallest action that starts this>
```

Then ask one line: `Run it? (ok / change X / just the brief)`

### Step 4: On approval

- `ok` or `go`: start the **First step**, working to the "Done when" list. Check each condition at the end and report which are met.
- A change: revise the brief, show it again, wait.
- `just the brief`: stop.
- If the `lfg` skill is installed and the user wants a polished prompt for another tool, offer to pass the brief to `lfg`. Don't require it.

## Quality rules

- **"Done when" must be checkable.** "Looks professional" is not a condition; "has 5 pages, each with a heading and one image" is.
- **Shrink, don't inflate.** A scoped brief should be smaller than the wish felt. If it grew, cut the parked extras into "Out of scope".
- **Name the trade-off** when the wish is really two projects ("website and a brand and a shop"): propose scoping the first only, and park the rest.
- **No theory, no frameworks, no motivational lines.** Short sentences, plain words.
- **Never invent facts** about the user's situation. Unknown goes under "Assumed".

## Anti-patterns

- Asking more than 5 questions, or a second round of questions.
- Asking what the context already answers.
- Writing a brief longer than the user's wish plus their answers.
- "Done when" lines that can't be checked.
- Starting the work before the brief is approved.
- Scoping a task that was already small and clear.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.