القائمة
Break a technical specification into user stories with coverage validation. Use after generate-spec.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/llipe/dev-tasks --skill activity-generate-storiesيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | activity-generate-stories |
| description | Break a technical specification into user stories with coverage validation. Use after generate-spec. |
Create structured, implementation-ready User Stories from a Technical Specification with built-in coverage validation against the PRD. Use this skill after the specification is approved. Invoked by the product-engineer agent in Feature Mode.
RFC 2119 Notice: The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119.
Create structured, implementation-ready User Stories from a Technical Specification, then validate that all PRD requirements are covered. Each user story MUST provide value independently, fit into a single Pull Request, and contain the detail needed for implementation.
This activity combines story generation and coverage validation into a single pass.
This activity assumes the following documents already exist:
prd-[feature-name].md — Feature requirementsspecification-[prd-name].md — Technical specificationThe user stories document MUST include a Changelog table as the first section after the document title. The changelog tracks the version history of the document.
1.01.1, 1.2, …).2.0).@username, developer-agent, planner-agent).## Changelog
| Version | Date | Summary | Author |
| ------- | ---------- | --------------- | ------------------ |
| 1.0 | YYYY-MM-DD | Initial version | @user / agent-name |
Each User Story MUST include:
### Story [ID]: [Title]
**Priority:** [Critical/High/Medium/Low]
**Estimated Size:** [XS/S/M/L]
**Dependencies:** [List any dependent stories or systems]
#### User Story
As a [user role],
I want [goal/capability],
So that [business value/benefit].
#### Context
[Why this story matters, how it fits the larger feature.]
#### Acceptance Criteria
- [ ] [Criterion 1: Specific, testable condition]
- [ ] [Criterion 2]
- [ ] [Criterion 3]
#### Business Rules
- [Business rule 1]
- [Business rule 2]
#### Technical Notes
- [Key technical decisions or patterns to follow]
- [Reference to Technical Guidelines sections]
- [Integration points]
#### Testing Requirements
- **Unit Tests:** [Specific scenarios]
- **Integration Tests:** [Cross-component scenarios]
- **Manual/UI Testing:** [User-visible checks and access path]
- **Edge-Case Matrix:** [Boundary, error, empty-state, concurrency/idempotency cases]
- **Acceptance-Criteria Mapping:** [AC -> test case IDs or commands]
- **Execution Commands:** [Canonical scripts, prefer `pnpm run <script>`]
#### Migration Requirements (When Data Model Changes)
- Migration artifact: [required by default; add explicit opt-out rationale if omitted]
- Rollback/impact notes: [required]
- Apply step: [requires explicit user confirmation before running]
- Verification after apply: [required]
#### Implementation Steps
1. [Step 1]
2. [Step 2]
3. [Step 3]
#### Files to Create/Modify
- `path/to/file1.ts` - Brief description
- `path/to/file1.test.ts` - Unit tests
#### Definition of Done Checklist
- [ ] Code implemented per technical guidelines
- [ ] Unit/integration/manual/edge-case tests written and passing
- [ ] Quality gates passing (`lint`, `format:check`, `typecheck`, `test`, `audit`)
- [ ] Code reviewed and approved
- [ ] Acceptance criteria verified
- [ ] Acceptance criteria explicitly mapped to test evidence
- [ ] Migration lifecycle complete (or documented opt-out) when schema/data-model changes exist
- [ ] Pull Request created and merged
pnpm over npm.npm only when pnpm is unavailable or the project is explicitly npm-locked.lint, lint:fixformat, format:checktypechecktest, test:unit, test:integration, test:e2eauditvalidate (aggregate quality gate)Good User Stories:
Poor User Stories:
You SHOULD consider these factors when sequencing:
Before finalizing stories, you MUST validate coverage against the PRD.
You MUST include a summary coverage report at the end of the stories document:
## Coverage Validation
### Summary
- **Total PRD Requirements:** [#]
- **Total User Stories:** [#]
- **Coverage:** [X%]
- **Status:** [Complete / Gaps Identified]
### Requirement Mapping
| PRD Requirement | Story ID(s) | Status |
| --------------- | ------------ | ---------- |
| [Req 1] | S-001 | ✅ Covered |
| [Req 2] | S-002, S-003 | ✅ Covered |
| [Uncovered Req] | — | ❌ GAP |
### Gaps (if any)
- **Gap [#]:** [Requirement not covered] — **Recommendation:** [Create new story / Modify existing story]
### Non-Goals Validation
- [ ] [Out-of-scope item 1] — Confirmed NOT in any story
- [ ] [Out-of-scope item 2] — Confirmed NOT in any story
If gaps are found, you MUST propose additional stories or modifications to close them before presenting for review.
.md)/workstream/user-stories-[prd-name].md