메뉴
Convert a SRS into EPICS, user stories, tasks, and a sprint plan using vertical slicing (tracer bullet) principles. Use when breaking down a SRS into implementable work and planning execution.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Orchestrate a plan → review → implement delivery loop across three PLUGGABLE agent roles — planner, reviewer, implementer — where any agent can fill any role in any order. One agent drafts an artifact (SRS / design / per-task plan), a second adversarially reviews it through a shared markdown thread until convergence (Final ACK), and a third implements; the orchestrator (the agent running this skill) relays handoffs, monitors the review thread, and reviews the resulting PR. Use when the user asks to "run the planner / reviewer / implementer loop", "tri-agent loop", "plan-review-implement", "use X to plan, Y to review, Z to implement" (any permutation, e.g. Claude plans, Codex reviews, Cursor implements), or wants the docs-first / Codex-reviewed / Cursor-implemented workflow from feedback_planner_reviewer_codex_loop generalized to arbitrary agents.
Interview the user relentlessly about a plan, design, or approach until every branch of the decision tree is explicit and defensible. Turns the agent from order-taker into peer programmer — one who pushes back, names hidden assumptions, recommends instead of just asking, and refuses to start implementation while a load-bearing decision is still in the user's head. Use when the user says "grill me", "stress-test this plan", "interview me on this design", "challenge my approach", "are there gaps in my plan?", or wants a peer-review pass before committing to a direction.
Compact the current conversation into a structured handoff document (saved to the OS temp directory) so a fresh agent can continue the work without losing context. Use when the user invokes /handoff, says "create a handoff doc", "write a handoff document", "compact this for another agent", "pass off to another session", "what will the next session focus on", or generally wants to checkpoint the conversation state before a context-window break. Always references existing artifacts (design docs, plans, PRs, commits, memory entries) by path/URL — never duplicates their content. Includes a mandatory "suggested skills" section. Redacts API keys, passwords, PII.
Harness two AI agents (typically Claude + OpenAI Codex, or two Claudes, or an agent + human reviewer) into a Reviewer / Implementor pair that collaborate asynchronously through a shared markdown thread. One agent reviews / critiques / asks pointed questions; the other implements / responds / drives the code changes; the file mediates. Use when the user says "pair another agent on this", "harness Codex on this", "review this with Codex", "open a Codex thread", "respond to Codex", "open a peer review", "monitor this review file", names a *-review-thread.md or *-dialogue-thread.md, or wants to coordinate structured async back-and-forth between two AI agents on a code or design question. Seeds the file from a template if missing, appends a numbered Claude response under its own section header, arms a file-mtime monitor so each peer append triggers a fresh read + response, drives the pyramid-principle response shape (position first, justification second), detects consensus markers like "Final ACK" / "No further ob
Convert the current plan, spec, design doc, or conversation context into a single self-contained, share-able HTML file with rich visual structure (tables, SVG diagrams, code blocks, responsive layout, in-page navigation). Supports four output shapes — editorial, technical-doc, dashboard, and slide-deck. Use when the user invokes /html-output, asks to "export as HTML", "render this as HTML", "structure your response as HTML" (Karpathy-style), "make a web version", "share this as a link", "present this as slides / a slideshow / a deck", or wants a long plan or spec converted from markdown into something visually scannable or presentable.
Software Requirements Specification documentation following IEEE 830 standard. Use when generating formal SRS documents or compiling gathered requirements into structured documentation.
| name | srs-to-delivery-plan |
| description | Convert a SRS into EPICS, user stories, tasks, and a sprint plan using vertical slicing (tracer bullet) principles. Use when breaking down a SRS into implementable work and planning execution. |
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:
Keep tasks as a checklist inside the STORY issue.
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.