Skill requirements
A comprehensive Claude Code plugin that automates the complete Software Development Lifecycle with 20 role-specific agents, 12 knowledge skills, and 8 commands, all guided by principles.
npx -y skills add saitarrun/sdlc-ai-workflow --skill skill-requirementsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
This skill should be used when the user asks to "write requirements", "create user stories", "define acceptance criteria", "decompose a feature", "analyze an issue", "write a PRD", "create user stories", "acceptance criteria", "roadmap", "feature spec", or discusses "INVEST" criteria, "ambiguity", or "story estimation".
SKILL.md
2.7 KB, as published. Nobody here has run it
Skill: Requirements & User Stories (INVEST)
INVEST Criteria — Making Stories Actionable
A well-written user story is INVEST-compliant:
- Independent: Story doesn't depend on another story (can be built in any order)
- Negotiable: Details can be discussed and refined (not cast in stone)
- Valuable: Delivers value to the end user (not just internal plumbing)
- Estimable: Engineer can estimate size (2-13 story points)
- Small: Fits in a single sprint (1-2 weeks max)
- Testable: Acceptance criteria are clear and provable
Story Format
## User Story: [Feature Name]
As a [role/persona]
I want to [action/capability]
So that [business value/outcome]
### Acceptance Criteria
- Given [precondition]
When [action]
Then [observable result]
### Edge Cases & Questions
- Q: What happens if [scenario]?
- Q: Should we support [case]?
### Definition of Done
- [ ] Code written and reviewed
- [ ] Acceptance criteria tests pass
- [ ] Documentation updated
- [ ] Performance tested (if relevant)
- [ ] Security review passed (if relevant)
Story Estimation
- Small (2-3 pts): Can be done in a day, low complexity, well-understood
- Medium (5 pts): Takes 2-3 days, some unknowns, requires design
- Large (8 pts): Takes full sprint, many unknowns, high risk
- Too Large (13+ pts): Break into smaller stories
Common Pitfalls
| Pitfall | Bad Example | Good Example |
|---|---|---|
| Not independent | "Add payment form" depends on "Add payment backend" | "Add payment form UI" + "Add payment API" (can be mocked) |
| Not valuable | "Refactor database layer" | "Enable payments via Stripe" |
| Not testable | "Code should be fast" | "Page load <2 seconds on 3G" |
| Too large | "Build entire user profile system" | "User can upload profile photo" |
| Unclear | "Handle edge cases" | "Given missing email, show validation error" |
Ambiguity Detection
Always ask these questions before starting work:
- Scope: Are there other features needed first? Any dependencies?
- Success: How do we know this is done? What's the test?
- Users: Who specifically benefits? All users or subset?
- Edge Cases: What happens if user has no data? Empty input? Slow connection?
- Performance: Are there speed requirements?
- Integration: Does this affect other features? APIs? Databases?