idea-to-scope
Skill0 starsChanged 25 days agoMITView on GitHub
Turn a vague feature idea into a small, testable scope and explicit non-goals before code changes. Use for product discovery and unclear requests; not for a fully specified small fix.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- acceptance-qaSkill
- architecture-reviewSkill
- bug-fix-verificationSkill
- dependency-upgradeSkill
- docs-syncSkill
- implementation-planSkill
- independent-reviewSkill
- migration-safetySkill
- performance-investigationSkill
- pull-request-handoffSkill
- release-checkpointSkill
- root-cause-investigationSkill
- security-reviewSkill
- surgical-changeSkill
- test-gap-auditSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Start with the user problem, not a screen or a package name.
- Distinctive: line 12
Define a first slice: Write the smallest behavior that delivers value.
- Distinctive: line 13
Close consequential gaps: Ask at most a few high-leverage questions when the answer materially changes the outcome.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Idea to scope
Start with the user problem, not a screen or a package name. This is a thinking workflow; do not edit source or commit anything.
- Find the job. Identify the user, the moment the problem occurs, and how they currently work around it. If the repository exists, inspect only enough to avoid proposing something it already does.
- Challenge the premise. Name one smaller or simpler way to get the same result. Identify a plausible reason the requested feature might not help.
- Define a first slice. Write the smallest behavior that delivers value; include a real example and a deliberate list of non-goals. Do not convert possibilities into requirements.
- Close consequential gaps. Ask at most a few high-leverage questions when the answer materially changes the outcome. For ordinary decisions, propose a reversible default and mark it as an assumption.
- Set acceptance evidence. Describe how a person could observe success. Include failure or edge cases that would make a superficial demo misleading.
- Hand off. State scope, acceptance criteria, assumptions, rejected alternatives, and unresolved decisions. Invite
$implementation-planonly after scope is coherent.
Watch for
- Asking ten questions where a narrow assumption would suffice.
- Adding roles, dashboards, settings, and analytics before the first useful action works.
- Presenting invented user research as fact.
- Claiming agreement or approval that the user has not given.
Output
A one-paragraph problem statement, first slice, not now, acceptance evidence, and open decisions. No code or project state changes.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.