Stats
Actions
Tags
From scoping
Turn raw project inputs (briefs, meeting transcripts, screenshots, voice notes, loose prompts) into a complete, staged scoping package — scope.md as the source of truth, screens.md for design agents, phased task cards for coding agents, and API docs for frontend consumers. Use this whenever the user asks to "scope a project," "turn this into a scope," "create a scope.md," "build a development plan from this brief," "produce screen specs," or hands over any project description, meeting transcript, client brief, or set of feature screenshots and asks for an executable spec. Also use when the user mentions producing artefacts for a coding agent, frontend design agent, or development team based on a project description.
How this skill is triggered — by the user, by Claude, or both
Slash command
/scoping:scopingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Turn unstructured project inputs into a complete, executable scoping package.
Turn unstructured project inputs into a complete, executable scoping package.
Scoping is the most important step in any project. If scoping goes well, the project goes well. This skill exists to make sure scoping is thorough, structured, and reproducible across projects.
For each project, a folder containing:
<project-name>/
├── inputs/ ← copy of original brief, transcript, screenshots
├── scope.md ← single source of truth: platform, models, settings, business rules
├── screens.md ← screen-by-screen reference for frontend design agents
├── tasks/
│ ├── workstream-1-<name>.md
│ ├── workstream-2-<name>.md
│ └── ...
└── api/ ← only if the project has an API surface
├── api.md ← human-readable, frontend-consumer focused
└── openapi.yaml ← machine-readable spec generated from api.md
Note: this skill does not produce a DESIGN.md. Design system work is handled separately.
The skill supports three modes. Always ask which mode at the start of stage 1.
scope.md only. Target ~1500 words. No screens.md, no tasks/, no api/. Skip stages 3–6 entirely.If the user is unsure which mode to use, recommend Standard as default. Lite is for sub-week projects. Deep is for projects scoped over multiple months across multiple developers.
This skill produces artefacts in gated stages. Each stage requires explicit user confirmation before moving to the next. This is non-negotiable: a misunderstood requirement in stage 1 contaminates every artefact downstream, and re-running a multi-stage generation is expensive in tokens and time.
The stages are:
After each stage, end the turn with: a brief summary of what's in the artefact, a list of any assumptions made, and an explicit ask to confirm or request changes before proceeding.
The user will typically provide one or more of:
Read every input thoroughly before asking anything. For voice recordings without transcripts, transcribe them first. For screenshots, describe what each shows and extract the features visible. For documents, summarise the platform in 3–5 sentences in your own thinking before proceeding.
If the user gives you a folder path or attaches files, save copies to <project-name>/inputs/ so the project folder is self-contained.
Ask the user which mode (Lite / Standard / Deep) — see "Detail modes" above. Recommend a default based on the apparent project size from inputs. The chosen mode shapes everything downstream.
Stack defaults live at ~/.claude-skills/scoping/stack-defaults.md (in the user's home folder, persisted across all projects).
Read this file at the start of every project:
cat ~/.claude-skills/scoping/stack-defaults.md 2>/dev/null
If the file doesn't exist or is empty, this is the user's first run with this skill — proceed without defaults. If defaults exist, present them to the user and ask whether to apply them to this project or override per-component (e.g. "use Laravel default but switch DB to PostgreSQL for this one").
Never make silent assumptions. The user has explicitly chosen "always ask before assuming, even small things."
Group questions sensibly (don't fire one at a time). Ask about anything you cannot determine from the inputs:
Use ask_user_input_v0 for choice-based questions where it makes sense (single_select / multi_select for stack choices, scope decisions, etc.). Use plain prose for open-ended questions ("describe the user roles and what each can do").
If this run involved choosing or changing a tech stack, ask at the end of stage 1: "Want me to save this stack as your defaults for future projects?"
If yes, write to ~/.claude-skills/scoping/stack-defaults.md using the format in references/stack-defaults-template.md. Create the directory first if it doesn't exist:
mkdir -p ~/.claude-skills/scoping
Summarise back to the user:
Ask: "Does this match your understanding? Any corrections before I write scope.md?"
Wait for confirmation. Do not proceed without it.
Read references/scope-template.md for the full template and section-by-section guidance. The template has variants for each detail mode.
scope.md is the single source of truth. Every other artefact derives from it. If something isn't in scope.md, it doesn't exist in the project.
After producing it:
<project-name>/scope.mdpresent_files tool to make it visibleRead references/screens-template.md for the template.
screens.md is for frontend design agents. Each screen gets a structured entry covering purpose, route, components, all states, data shown, user actions, edge cases. Designers should be able to produce mockups using only this file plus the project's design system (which is provided separately by the user, not generated by this skill).
Derive screens from scope.md — every user flow in scope.md must have its screens covered here. Cross-reference each screen back to the scope.md feature(s) it implements.
After producing it:
<project-name>/screens.mdpresent_filesRead references/tasks-template.md for the template and phasing principles.
The structure depends on mode:
phase-1-foundation.md, phase-2-<feature>.md...)Phasing principles (apply to both):
After producing them:
<project-name>/tasks/present_filesSkip this stage entirely if the project has no API surface (e.g. WordPress site, static marketing site).
Read references/api-template.md for the template.
The audience for these docs is frontend developers building React / React Native / mobile clients that consume the API. The format is consumer-focused: endpoint reference, request/response shapes, auth, error codes, examples. It includes enough detail for backend developers to implement against (validation rules, status codes) but does not prescribe backend implementation.
Produce two files:
api.md — human-readable. Endpoints grouped by resource. For each: method, path, auth required, request schema, response schema, error codes, example request/response.openapi.yaml — generated from api.md. Use OpenAPI 3.1.If parsing api.md to generate the YAML proves brittle, write the YAML directly from the same source content — but flag the drift risk to the user.
After producing them:
<project-name>/api/api.md and <project-name>/api/openapi.yamlpresent_filesDefault to Australian / British English for all generated content unless the user explicitly asks for US English. This applies to every artefact.
Every generated scope.md (and screens.md / api.md when produced) starts with a version header:
_Version 1.0 — <ISO date>_
_Mode: <Lite/Standard/Deep>_
_Spelling: Australian English_
When the user requests changes to a generated scope, do not just regenerate silently. Bump the version (1.0 → 1.1 for additions, 2.0 for restructures), and add a "Changes since v:" block immediately under the version header that summarises what changed in 4–8 bullets. This makes scope evolution legible to anyone returning to the doc later, including coding agents resuming work after time away.
Each generated artefact has a single, exclusive ownership domain. Coding agents are told this in §1.5 of scope.md, and the skill enforces it during generation:
When generating downstream artefacts, do not re-document content owned by upstream artefacts. screens.md does not redescribe business logic. api.md does not redescribe data models. tasks/ does not redescribe features. They cross-reference upstream using § notation. If a coding agent finds two artefacts contradict, the rule is to escalate, not silently choose.
If a piece of information is missing and you've already asked, mark it explicitly in the document as **TBC**: <what needs deciding> rather than fabricating a plausible answer. Coding agents fail silently on fabricated requirements.
When the user states a constraint that should bind the implementation (e.g. "the role system needs to support coaches and moderators later" or "videos must never be publicly accessible"), surface it as an explicit Engineering rule callout in scope.md rather than burying it in prose. Format:
Engineering rule: do not hard-code role checks around only
adminanduser. Implement a future-safe role/permission model.
The scope template (§17 Engineering Notes) carries a checklist of common rules to consider including — transactions + afterCommit, snapshot fields for historical records, server-side total recalculation, data-repair tooling alongside imports, server-side validation, feature flags at the boundary, extensible role checks, external calls through jobs. Walk that checklist for every project; include each rule that genuinely applies.
For Deep mode, every module gets categorised as:
This pattern prevents both scope creep and short-sighted architecture.
Standard and Deep modes include a Settings catalogue section in scope.md — every admin-configurable value with its key (e.g. chat.ban_view_mode), purpose, allowed values, and default. Aggregate these into a SystemSetting-style model in the data model section.
Default to including Mermaid diagrams where they genuinely aid understanding:
Don't force diagrams into trivial cases. A model with three fields and a belongsTo User doesn't need an ERD.
§ notationThis creates a navigable web rather than disconnected documents.
After each stage, use the present_files tool to make the artefact visible to the user. Don't just dump content into the chat.
If the user says "no, that's wrong" mid-stage, stop. Don't try to patch over by adding more sections. Ask what's wrong specifically, fix the upstream artefact (often scope.md), and re-run downstream stages from there.
If the user's brief contradicts itself (e.g. transcript says one thing, written brief says another), do NOT pick one and hope. Surface the conflict explicitly during stage 1 clarification.
references/scope-template.md — scope.md template with mode variantsreferences/screens-template.md — screens.md templatereferences/tasks-template.md — task card and workstream templatereferences/api-template.md — api.md template (frontend-consumer focus) and openapi.yaml conventionsreferences/stack-defaults-template.md — format for ~/.claude-skills/scoping/stack-defaults.mdFetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Applies a firm's KYC/AML rules grid to parsed onboarding records: assigns risk rating, checks required documents, outputs rule outcomes with citations, and routes for escalation.
Generates daily or weekly digests of activity from connected sources (chat, email, docs, tasks, CRM), highlighting action items, decisions, mentions, and project updates.
npx claudepluginhub mike-ab/catch-solutions-claude-skills --plugin scoping