requirement-extraction
Skill2 starsChanged 6 months agoMITView on GitHub
Transform vague user inputs into structured, actionable requirements with explicit assumptions.
In this repository10 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- codebase-navigationSkill
- context-window-managementSkill
- dependency-assessmentSkill
- error-interpretationSkill
- human-escalationSkill
- incremental-verificationSkill
- multi-agent-collaborationSkill
- production-awarenessSkill
- safe-refactoringSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
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 84
Never assume silently: - If you fill in a gap, say so and ask for confirmation
- Distinctive: line 88
Default conservatively: - When in doubt, choose the simpler interpretation and note it as an assumption
≈ “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
Requirement Extraction
What This Skill Enables
An agent that can take ambiguous human input - "make the dashboard faster," "add authentication," "fix the search" - and systematically convert it into concrete, testable requirements before writing code. Agents without this skill build the wrong thing confidently.
Core Competencies
1. Signal Capture
Receive input without interpreting or filtering:
- Record the exact words the user used
- Note what was said AND what was left unsaid
- Identify the stated goal vs the implied constraints
- Distinguish between the problem description and a proposed solution
2. Ambiguity Detection
Flag vague language that needs clarification:
| Vague Input | What's Missing | Clarifying Question |
| "Make it faster" | Faster by how much? Which operation? | "What's the current latency, and what's the target?" |
| "Add user roles" | Which roles? What permissions? | "What actions should each role be able to perform?" |
| "Fix the bug" | Which bug? How to reproduce? | "Can you describe the steps to trigger this behavior?" |
| "It should be secure" | Against what threats? What data? | "What sensitive data does this handle, and who should access it?" |
| "Like Spotify does it" | Which specific feature/behavior? | "Can you describe the specific interaction you're referring to?" |
3. Assumption Surfacing
Make every implicit assumption explicit before proceeding:
STATED: "Add a login page"
ASSUMPTIONS I'M MAKING:
- Email + password authentication (not OAuth/SSO)
- Single user type (no admin vs regular distinction)
- Session-based auth (not token-based)
- Standard form with email and password fields
- Redirect to home page after successful login
- Show error message for invalid credentials
- No "remember me" or "forgot password" in v1
RISKS IF WRONG:
- OAuth requirement would change the entire auth architecture
- Multiple user types affect the data model and routing
→ Please confirm or correct these before I proceed.4. Requirement Structuring
Convert confirmed requirements into testable statements:
Format: WHEN [condition], the system MUST/SHOULD/MAY [behavior]
Examples:
WHEN a user submits valid credentials, the system MUST create a session and redirect to /dashboardWHEN a user submits invalid credentials, the system MUST display "Invalid email or password" without revealing which field was wrongWHEN a session expires, the system SHOULD redirect to /login with a "session expired" messageWHEN a logged-in user visits /login, the system MAY redirect to /dashboard
5. Scope Fencing
Define what's in and what's out:
IN SCOPE:
- Login form with email/password
- Session creation and validation
- Logout endpoint
- Protected route middleware
OUT OF SCOPE (for this iteration):
- Registration / signup
- Password reset
- OAuth / social login
- Multi-factor authentication
- Remember me functionalityBehavioral Rules
- Never assume silently - If you fill in a gap, say so and ask for confirmation
- Ask before building - One clarifying question saves hours of rework
- Separate problem from solution - "We need Redis" is a solution; "responses are slow" is the problem
- Quantify wherever possible - "Fast" means nothing; "<200ms p95 response time" is testable
- Default conservatively - When in doubt, choose the simpler interpretation and note it as an assumption
Failure Modes
| Failure | Symptom | Correction |
| Assuming requirements | Building features the user didn't ask for | Surface every assumption explicitly |
| Gold-plating | Adding OAuth when they asked for basic login | Stick to stated scope; suggest enhancements separately |
| Not asking follow-ups | Implementing based on first message alone | Probe for edge cases, error states, and constraints |
| Treating solutions as requirements | "Use Redis" → implementing Redis without understanding the actual need | Ask "what problem does this solve?" first |
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.