Rijul1204 SRS to Delivery Plan
Convert a Software Requirements Specification (SRS) into a structured delivery plan:
SRS → EPICS → STORIES → TASKS → SPRINT PLAN
This system combines:
- Product thinking (EPICS)
- Vertical slicing (STORIES)
- Execution clarity (TASKS)
- Delivery planning (SPRINTS)
Core Principles
Vertical Slice (Tracer Bullet)
Each STORY must:
- Deliver a thin but complete end-to-end flow
- Cut through ALL layers (DB → API → UI → integration → tests)
- Be independently testable and demoable
- Provide real user value
Avoid horizontal slices like:
- "Build database schema"
- "Create API layer"
Instead:
- "User can create account and log in"
HITL vs AFK
HITL (Human-in-the-loop)
Requires:
- Product decisions
- Architecture discussions
- UX validation
AFK
- Can be implemented and merged independently
- No external decision required
Always maximize AFK stories.
PROCESS
Step 1 — Locate the SRS
Ask the user for:
- GitHub issue number OR
- URL OR
- Raw SRS document
If not available → ask for it.
Do NOT proceed without understanding the SRS.
Step 2 — Understand the System
Extract:
- Core features
- User stories
- Key flows
- System boundaries
- Constraints (tech, product, compliance)
Summarize briefly before proceeding.
Step 3 — Create EPICS
Group features into high-level capabilities.
EPIC Rules
- Represents a major deliverable
- Takes ~1–3 weeks
- Contains multiple STORIES
- Focus on outcomes, not implementation
Output Format
For each EPIC:
- Title
- Description
- Covered SRS sections
Step 4 — Create STORIES (Vertical Slices)
Break each EPIC into STORIES.
STORY Rules
- End-to-end functionality
- Demoable independently
- Small (ideally 1–2 days)
- User-value focused
STORY Fields
- Title
- Type: HITL / AFK
- Blocked by
- User stories covered (from SRS)
Step 5 — Create TASKS
Break STORIES into TASKS. Each task must be a self-contained work packet with enough detail that the implementer (human or AI agent) can execute without further clarification.
TASK Rules
- Technical units of work
- 2–8 hours each
- Can be layer-specific
- NOT user-facing
- Must be independently executable with full context
Required TASK Fields
Every task MUST include ALL of the following:
| Field | Description |
|---|---|
| Context | Why this task exists. What story/feature it enables. What came before it and what comes after |
| Problem Statement | The specific technical gap this task fills. What doesn't exist or work yet |
| Scope | Exactly what files/modules are touched. What is IN scope and what is explicitly OUT of scope |
| Definition of Done | Concrete, binary checklist — when is this task finished? No ambiguity |
| Acceptance Criteria | Behavioral criteria from the user/product perspective that this task must satisfy |
| Testing Plan | What tests to write or run. Unit tests, integration tests, manual verification steps |
| Validation | How to verify the task is complete — specific commands to run, pages to check, DB queries to inspect |
| Key Files | Existing files to read/modify, with brief explanation of what each provides |
| Implementation Notes | Patterns to follow, functions to reuse, gotchas to avoid. Reference existing code by path |
| Framework Integration | (Required if task adds a third-party library) SSR compatibility, Next.js config flags, React version requirements, required wrappers or polyfills. Read the library's framework docs and document findings here |
TASK Examples
- Define DB schema
- Implement API endpoint
- Build UI component
- Write integration test
Step 6 — Quiz the User (MANDATORY)
Present:
EPICS
STORIES (grouped by EPIC)
TASKS (optional preview)
Ask:
- Is EPIC grouping correct?
- Are stories too big or too small?
- Any missing flows?
- Are dependencies valid?
- Are HITL vs AFK classifications correct?
- Should any stories be split or merged?
Iterate until user approves.
Step 7 — Create GitHub Issues
Create issues in this order:
- EPICS
- STORIES
- (Optional) TASK issues
Use the issue templates from template.md for EPIC, STORY, and TASK formatting.
TASK Handling
Two options:
Option A (default)
Keep tasks as a checklist inside the STORY issue.
Option B (advanced teams)
Create sub-issues per task. Use the TASK template from template.md.
Step 8 — Sprint Planning
After STORIES are created, organize them into sprints.
Sprint Rules
- Duration: 1 week (recommended)
- Prioritize:
- Unblocking stories
- Core flows
- First usable system
- Balance workload based on capacity
Sprint Output Format
# Sprint Plan
## Sprint 1
Goal: First working end-to-end flow
Stories:
- #12 User signup & login (AFK)
- #13 Basic dashboard (AFK)
- #14 First data capture (HITL)
---
## Sprint 2
Goal: Core functionality expansion
Stories:
- #15 Data processing (AFK)
- #16 Task extraction (AFK)
Prioritization Strategy
- Foundations (auth, schema, infra)
- First usable loop
- Feature expansion
- Optimization & scale
Rules to Enforce
- Do NOT skip vertical slicing
- Do NOT create horizontal-only stories
- Do NOT over-bundle stories
- Prefer many small stories over few large ones
- Always validate with user before creating issues
- Always maintain dependency correctness
Final Output Checklist
Before finishing, ensure:
- EPICS clearly defined
- STORIES follow vertical slicing
- TASKS are actionable
- Dependencies are valid
- HITL vs AFK correctly assigned
- Sprint plan is realistic
- User has approved structure
Optional Enhancements
If user asks, also provide:
- Jira version
- Linear version
- Confluence documentation
- Roadmap view (monthly)
- Team allocation plan
Example (Reference)
EPIC: Memory System
Stories:
- Save journal entry (AFK)
- Extract structured memory (AFK)
- Link memory to entities (HITL)
This skill transforms a static SRS into a complete execution-ready system.
See template.md for all issue templates.