srs-to-delivery-plan — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited srs-to-delivery-plan (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Convert a Software Requirements Specification (SRS) into a structured delivery plan:
SRS → EPICS → STORIES → TASKS → SPRINT PLAN
This system combines:
Each STORY must:
Avoid horizontal slices like:
Instead:
Requires:
Always maximize AFK stories.
Ask the user for:
If not available → ask for it.
Do NOT proceed without understanding the SRS.
Extract:
Summarize briefly before proceeding.
Group features into high-level capabilities.
For each EPIC:
Break each EPIC into STORIES.
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.
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 |
Present:
Ask:
Iterate until user approves.
Create issues in this order:
Use the issue templates from template.md for EPIC, STORY, and TASK formatting.
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.
After STORIES are created, organize them into sprints.
# 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)Before finishing, ensure:
If user asks, also provide:
Stories:
This skill transforms a static SRS into a complete execution-ready system.
See template.md for all issue templates.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.