requirements-discovery
Skill2 starsChanged 15 days agoMITView on GitHub
Examines raw stakeholder input (transcripts, briefs, emails, feature ideas) into epics and candidate user stories published to the tracker; when scope exceeds a single session, opens a decision map and resolves one decision per session.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- z-Zihan/Evirtheir own version, first seen Oct 13, 2026
- kid0317/crewai_mas_demotheir own version, first seen Oct 8, 2026
- OneDro1d/dark-factorytheir own version, first seen Oct 8, 2026
- breeze-lyf/skillstheir own version, first seen Jun 5, 2026
- hkarpinen/agent-skillstheir own version, first seen Apr 15, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- kid0317/crewai_mas_demo★ 164same name
- z-Zihan/Evir★ 11same name
- OneDro1d/dark-factory★ 4same name
- breeze-lyf/skills★ 1same name
- hkarpinen/agent-skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository65 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .claude/CLAUDE.mdCLAUDE.md
- ask-mattSkill
- codebase-designSkill
- code-reviewSkill
- diagnosing-bugsSkill
- domain-modelingSkill
- grillingSkill
- grill-meSkill
- grill-with-docsSkill
- handoffSkill
- implementSkill
- implement-specSkill
- improve-codebase-architectureSkill
- prototypeSkill
- prSkill
- researchSkill
- retroSkill
- setup-matt-pocock-skillsSkill
- tddSkill
- teachSkill
- to-questionnaireSkill
- to-specSkill
- to-ticketsSkill
- triageSkill
- wait-whatSkill
- wayfinderSkill
- wizardSkill
- writing-for-agentsSkill
- ask-mattSkill
- codebase-designSkill
- code-reviewSkill
- diagnosing-bugsSkill
- domain-modelingSkill
- grillingSkill
- grill-meSkill
- grill-with-docsSkill
- handoffSkill
- implementSkill
- implement-specSkill
- improve-codebase-architectureSkill
- prototypeSkill
- prSkill
- researchSkill
- retroSkill
- setup-matt-pocock-skillsSkill
- tddSkill
- teachSkill
- to-questionnaireSkill
- to-specSkill
- to-ticketsSkill
- triageSkill
- wait-whatSkill
- wayfinderSkill
- wizardSkill
- writing-for-agentsSkill
- ask-refinementSkill
- bootstrap-contextSkill
- configure-refinementSkill
- meeting-minutesSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
2 rules. 0 are common, 0 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 45
When the argument is a spec with Status: open map:
- Very specific: line 47
Read the full spec and pending decisions in issues/.
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Discovery
Convert unstructured stakeholder input into traceable requirements through socratic examination. You are not a transcriber: capture what was stated and what was implied, flag ambiguities, and produce candidate stories that /refine-story carries to sprint planning. What the input does not support does not enter; what it hints at enters as a grounded inference; what it leaves open becomes a question.
Input: $ARGUMENTS
Before starting
Read docs/agents/refinement.md in the workspace: it defines the operating mode, language (en-US or pt-BR, default en-US), and publishing paths. If missing, request /configure-refinement and stop. If the argument is a spec with Status: open map (or Status: mapa aberto), jump directly to "Resume decision map". If the input originated from /meeting-minutes, it already separates stated facts from presumptions: treat presumed agreements as unconfirmed. Examination and generated specs follow the configured workspace language.
Steps
- Load and triage. Read the input,
CONTEXT.md, and invoke the Skill tool forrequirements-rigor. Scan for anti-patterns (readANTI-PATTERNS.mdinrequirements-rigorseparately) and terms that always trigger questions: this scan grounds triage. Classify by counting excerpts, not text volume: USABLE (every excerpt structures a requirement), PARTIALLY USABLE (at least one excerpt structures a requirement and at least one does not), UNUSABLE (no excerpt structures a requirement). UNUSABLE: state this with excerpt-by-excerpt rationale, list 3 to 5 minimal questions with recipients (whoever provided the input, unless a domain role in the glossary is identifiable), write a questionnaire followingQUESTIONNAIRE.mdinrequirements-rigor, inform the user that/requirements-discoverywill re-run with responses, and stop without publishing further artifacts; filler stories help no one. PARTIAL: proceed, and the final artifact opens with a list of unused excerpts and what is missing in each. Completed when: classification is stated in a single line, followed by excerpt-by-excerpt rationale when not USABLE. - Breadth-first mapping. Before generating any story, scan the full input: business domains with confidence ratings (High, Medium, Low; Low marks where discovery requires a follow-up conversation), stakeholders with type (business, technical, end-user) and what each advocates, epics with complexity S, M, L, or XL justified in a single line. An excerpt that structures a requirement becomes an epic and is sized now, naming the open questions that could move the size; partial processing holds the excerpts that structure no requirement at all, not the ones whose numbers are still open, because an empty epics table hides exactly the work the examination is about to size. The converse holds with equal force: an excerpt you marked as structuring no requirement never becomes an epic, however sizable it looks, and the complexity is one letter, with the open questions named beside it rather than a range of letters standing in for the decision. When input is second-hand, the note-taker enters the stakeholders table with type "source". Two voices in opposing positions on the same requirement: add
[CONFLICT], recording both positions without resolving unilaterally. A requirement stated by a single voice receives[VALIDATE WITH TEAM]where confirmation is critical: unmet role needs, scope decisions made by non-decision-makers; do not mark everything when two voices address disjoint topics. Business needs and technical constraints originate from different stakeholders and carry different weight: distinguish them. Completed when: each input excerpt is mapped to a domain and epic, or listed as unexploited. - Search for facts before asking. Check glossary, previous stories in
.scratch/, workspace documents, and in code mode, the codebase: does the mentioned integration already exist? Is the threshold already implemented? A found fact becomes a recommended answer with cited source. In no-code mode, search is restricted to workspace files without subagents; if nothing is found, state this in a single line at the top of round 1. Completed when: each candidate question is marked as answered by a source or open. - Decide scope size. Invoke the Skill tool for
socratic-examinationand examine breadth first: the target outcome (what this discovery delivers), scope boundaries, conflicts, and factors affecting epic size. SLAs, channels, and edge cases represent depth and are deferred to step 5. If at the end of this round the frontier fits in a single session, proceed to step 5. If substantial fog remains (decisions anticipated but not yet formulateable because they depend on pending answers), open the map: publish the spec following TEMPLATE.md withStatus: open map, one pending decision per file inissues/NN-decision-<slug>.mdfor each formulateable question, markingBlocked by:when dependent on another, and unformulateable fog in "Not yet specified". The distinction between a decision and fog is whether you can formulate the question with precision right now, not whether you can answer it. Mapping the fog is the goal of one session: stop and inform the user that/requirements-discovery <spec-path>resolves one decision per session. Completed when: either the question frontier fits in a single session, or the spec with an open map and pending decision files exists. - Examine. Continue rounds of
socratic-examinationin depth, epic by epic: roles, capabilities, outcomes, edge cases suggested by input, dependencies. Domain terms resolved are added toCONTEXT.mdimmediately. A fact that no attendee knows receives[TO CONFIRM: whom](or[A CONFIRMAR: quem]) and leaves the frontier. Completed when: the frontier is empty, or the user requests closing. - Synthesize. Write the discovery spec following TEMPLATE.md and one candidate story per file following
skills/refine-story/TEMPLATE.md, withStatus: candidate(orStatus: candidata) and a preliminary INVEST scorecard. A story failing INVEST does not become a clean card: it remains a candidate with[INVEST-FAIL]and resolution guidance. Include undeclared dependencies: integrations, external services, and architectural decisions required for stories to be implementable, each paired with the blocked story and required action. Every line in candidate stories matches input or a valid[INFERENCE: base]; unbacked additions are gold plating and must be removed. Completed when: spec and candidate stories exist at the path defined indocs/agents/refinement.md, with final disclaimer. - Route open items. Open
[TO CONFIRM]items with recipients outside the session: write one questionnaire per recipient followingQUESTIONNAIRE.mdinrequirements-rigor, alongside the spec. Completed when: no open question remains without a recipient or questionnaire. - Report. Epics created, candidate story count, open conflicts, and next steps:
/refine-storyper story, or/requirements-discovery <spec-path>if map is open.
Resume decision map
When the argument is a spec with Status: open map:
- Read the full spec and pending decisions in
issues/. A decision is unblocked when it is open and all decisions inBlocked by:are resolved. Completed when: you know which decisions are unblocked. - Select the decision: named by the user, or the first unblocked by number. Mark
Status: in examinationin the file before starting, preventing concurrent sessions from picking it. Completed when: file status is updated. - Resolve it with
socratic-examination, one decision per session. Research-type decisions are resolved by reading external sources with citations, without examination rounds. Record the answer directly in the file under## Answer, markStatus: resolved, and add a line with summary and path in the "Examination decisions" section of the spec. Completed when: decision is resolved and linked from spec. - The answer may clear surrounding fog: newly formulateable items leave "Not yet specified" and become new pending decisions; items outside the scope move to "Out of scope". Any decision invalidated by the answer is closed with a one-line rationale. Completed when: no pending decision contradicts the answer and fog is reassessed.
- With no pending decisions open: update spec to
Status: in progressand proceed to step 5 of main steps, in the same session if context permits, otherwise in the next session using the same command. Completed when: spec leaves open map status, or you report how many decisions remain.
Pending decision format:
# Decision NN: <question in one sentence>
Status: <open | in examination | resolved | closed>
Blocked by: <NN, NN or none>
Type: <examination | research>
## Question
<what must be decided and why it blocks progress>
## Answer
<upon resolution: decision, who decided, date>Final notice
Published artifacts only. A triage that stops the workflow and an examination round publish nothing, so they carry no notice: the notice qualifies an artifact someone may circulate.
⚠️ This output is an analytical draft. It requires human review before entering a sprint. Validate: technical feasibility, compliance, and unmapped dependencies.
In a pt-BR workspace:
⚠️ Este output é um rascunho analítico. Requer revisão humana antes de entrar em sprint. Valide: viabilidade técnica, compliance e dependências não mapeadas.
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.

