一键导入
epic-breakdown-skill
Epic 拆解專家。將 Epic 拆解為可執行的 Tasks,遵循 INVEST/DEEP 原則,支援 2-4 並行 workers,包含 contract 定義和整合測試。調用 ba-analyst-skill 進行需求分析,確保 task 品質。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Epic 拆解專家。將 Epic 拆解為可執行的 Tasks,遵循 INVEST/DEEP 原則,支援 2-4 並行 workers,包含 contract 定義和整合測試。調用 ba-analyst-skill 進行需求分析,確保 task 品質。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
預設的系統化開發工作流 (SDD)。當用戶明確要求開發新功能、修復複雜問題、進行需求梳理、架構設計、任務規劃、程式碼實現、spec review / optimization,或在 project review / live demo 前盤點真實整合風險時使用。若工作同時需要處理 review rejection、retro finding、known issue、tech debt、change-request follow-up、或其他 continuous-improvement 請求,並且要判斷它應該 `continue active spec`、走 `CR against completed spec`、先進 issue log,還是真的需要 `new spec`,也應使用此 skill。若工作同時需要規劃需求到任務的主流程,並在 implementation / closeout 前安排 folder-level `TESTS.md` row-level 更新、workspace `.agents/specs/TESTS.md` reconciliation / rollup refresh、test evidence 回寫,或明確決定何時 handoff 給 `test-registry-manager`,也應使用此 skill。直接的 `TESTS.md` catalog cleanup / duplicate-ID / stale-row / mapping reconciliation 本身仍屬於 `test-registry-manager`。
把這個 skill 當成 spec 工作的前門與路由入口,並在需要 branch-spec authoring / resume / improvement classification 時指向本目錄的 `WORKFLOW.md`。當使用者要建立新 spec、續做做到一半的 spec、根據 `NEXT_STEPS.md` 詢問下一步、盤點或更新 `SPECS.md`、建立或整理 `RTM.md`,或遇到 review rejection、retro finding、tech debt、known issue、test gap、CR follow-up 等 continuous-improvement 請求而不確定應該併回既有 owner、走 CR overlay、先進 issue log,還是真的需要開新 spec 時使用。把 project-level system architecture / `.agents/steering/{product,tech,structure}` / architecture review / 架構 HTML 導向 `system-architect`,把 AI/security/privacy/PII/log/regulatory compliance inventory / internal-audit gap table 導向 `iso-ai-security-auditor`,把 `ISSUE_LOG.md` 治理導向 `issue-log-manager`,把 `TESTS.md` 治理導向 `test-registry-manager`,把 `SPECS.md` registry sync 導向 `spec-registry-manager`,並在真正需要 local dev / UAT / E2E runtime allocation 時轉交 `local-infra-registry-governance`。不要用在單純 folder-level `TESTS.md` 維護、單純 `SPECS.md` 更新、單純 compliance legal advice/certification verdict、或單純 local env 操作這些已明確屬於下游 skill 的情況。
負責掃描專案內的所有 Specs 文件,進行規格盤點與狀態更新,並生成或維護全局規格註冊表 (`SPECS.md`)。當使用者要求「盤點 spec」、「更新 SPECS.md」、「建立規格目錄」,或需要管理 completed spec 的 change request、cross-spec 影響、external contract 依賴治理、continuous-improvement fragmentation 風險摘要、以及跨 spec 的 live-demo readiness / false-green review 風險摘要時使用。這個 skill 不負責 live local infra runtime registry,也不直接重做 runtime 驗證。
管理 `TESTS.md` 與 test traceability 的專用 skill。當使用者要更新、盤點、刷新、reconcile、audit、clean up folder-level `TESTS.md` 或 workspace `.agents/specs/TESTS.md`,補 `Test ID`、`Owner`、`Canonical Command`、`Evidence Ref`、`Task / Spec Trace`、`Requirement / AC Trace`,處理 duplicate test IDs、stale rows、`unmapped_to_spec`、missing evidence,或在 spec closeout 前刷新測試治理時,都應優先使用此 skill,即使使用者沒有明說 skill 名稱。若工作同時涉及 open CR、review-pending baseline change、或需要重新判定 critical test evidence freshness,也應使用此 skill。不要用在新 spec authoring、`SPECS.md` registry sync、`RTM.md` authoring、最終 readiness verdict、或 local env / runtime work。
為 git 管控的專案建立跨 AI agent 的 hybrid bridge:repo-local `skills` 用 symlink / Junction 避免重複,`specs` 可選擇 sync 或 symlink,其餘 `.claude`、`.kiro`、`.codex` 內的設定 / 權限檔維持 real-directory + sync workflow。當使用者提到「設定 cross-agents symlinks」「初始化 agents 設定」「skills 不要重複」「保留 Claude/Codex 權限檔」「specs 要可切換 sync 或 symlink」「CLAUDE.md symlink」或要整理 cross-agent `.gitignore` 規則時使用此 skill。
Perform code review using Code Review System CLI tools. Use when agents need to analyze code, generate improvements, create reports, perform architecture analysis, inspect bounded context, query GraphRAG state, govern local GraphRAG artifacts, or produce generic producer-side routing handoff artifacts. Supports file-level and project-level reviews.
基于 SOC 职业分类
| name | epic-breakdown-skill |
| description | Epic 拆解專家。將 Epic 拆解為可執行的 Tasks,遵循 INVEST/DEEP 原則,支援 2-4 並行 workers,包含 contract 定義和整合測試。調用 ba-analyst-skill 進行需求分析,確保 task 品質。 |
Epic Breakdown Agent - 將 Epic 拆解為可執行 Tasks 的專家
若在拆解過程中產生 deferred / emergent slices,應流向 workspace backlog mechanism(先 summary-mode,必要時再抽出
PRODUCT_BACKLOG.md),而不是混入 spec-level truth 或 runtime readiness 結論。
Contract Definition (index 0)
Implementation Tasks (index 1-4)
Integration Tests (index 5)
QC Review (index 6)
# 調用 ba-analyst-skill 分析 Epic
kiro-skill ba-analyst-skill \
--input "Epic: {title}\nContext: {business_context}\nAC: {acceptance_criteria}"
輸出:
基於 BA 分析結果,拆解為 tasks:
Contract Task:
{
"title": "Define {component} API contracts",
"role_needed": "Coder",
"payload_context": {
"description": "Define REST API contracts with OpenAPI spec",
"acceptance_criteria": "All endpoints, schemas, error codes documented",
"technical_notes": "Use OpenAPI 3.0, include examples",
"test_requirements": "Contract tests for all endpoints"
},
"depends_on": [],
"estimated_effort": "S"
}
Implementation Tasks (2-4 並行):
{
"title": "Implement {feature} endpoint",
"role_needed": "Coder",
"payload_context": {
"description": "Implement POST /endpoint with validation",
"acceptance_criteria": "Endpoint works per contract, tests pass",
"technical_notes": "Use TDD workflow, follow contract",
"test_requirements": "Unit + integration tests, >80% coverage"
},
"depends_on": ["0"],
"estimated_effort": "M"
}
Integration Test:
{
"title": "Integration tests for {epic}",
"role_needed": "QA_Engineer",
"payload_context": {
"description": "E2E tests for complete flow",
"acceptance_criteria": "All scenarios covered, tests pass",
"technical_notes": "Use test database, clean up after",
"test_requirements": "Happy path + error cases"
},
"depends_on": ["1", "2", "3", "4"],
"estimated_effort": "M"
}
QC Review:
{
"title": "QC review for {epic}",
"role_needed": "QC_Reviewer",
"payload_context": {
"description": "Review code quality, security, coverage",
"acceptance_criteria": "Standards met, >80% coverage, no vulnerabilities",
"technical_notes": "Check OWASP Top 10, code standards",
"test_requirements": "All tests passing"
},
"depends_on": ["5"],
"estimated_effort": "S"
}
生成 DAG:
Contract (0)
├─> Impl 1 (1)
├─> Impl 2 (2)
├─> Impl 3 (3)
└─> Impl 4 (4)
└─> Integration (5)
└─> QC (6)
[
{ "title": "...", "depends_on": [] },
{ "title": "...", "depends_on": ["0"] },
{ "title": "...", "depends_on": ["0"] },
{ "title": "...", "depends_on": ["1", "2"] },
{ "title": "...", "depends_on": ["3"] }
]
// internal/breakdown/llm.go
func BreakdownEpic(epic *ent.Epic) ([]Task, error) {
// 1. 準備 prompt
prompt := fmt.Sprintf(`
Epic: %s
Context: %s
Acceptance Criteria: %s
Use epic-breakdown-skill to break down into tasks.
Follow INVEST/DEEP principles.
Include contract definition, 2-4 parallel implementations, integration tests, QC review.
Return JSON array only.
`, epic.Title, epic.BusinessContext, epic.AcceptanceCriteria)
// 2. 調用 LLM (kiro-skill)
result := kiroSkill.Execute("epic-breakdown-skill", prompt)
// 3. Parse JSON
var tasks []Task
json.Unmarshal(result, &tasks)
return tasks, nil
}
kiro-skill epic-breakdown-skill \
--epic-title "User Authentication" \
--business-context "Secure auth with JWT" \
--acceptance-criteria "Register, login, logout"
Title: User Authentication System
Business Context: Implement secure user authentication with JWT tokens for the web application
Acceptance Criteria:
- Users can register with email/password
- Users can login and receive JWT token
- Users can logout and invalidate token
- Protected endpoints require valid token
[
{
"title": "Define authentication API contracts",
"role_needed": "Coder",
"payload_context": {
"description": "Define REST API contracts for /register, /login, /logout, /verify endpoints with OpenAPI 3.0 spec",
"acceptance_criteria": "OpenAPI spec complete with all endpoints, request/response schemas, error codes, and examples",
"technical_notes": "Use JWT for tokens (HS256), bcrypt for passwords (cost 12), include rate limiting specs",
"test_requirements": "Contract tests for all endpoints using Pact or similar"
},
"depends_on": [],
"estimated_effort": "S"
},
{
"title": "Implement user registration endpoint",
"role_needed": "Coder",
"payload_context": {
"description": "Implement POST /api/v1/auth/register with email validation, password hashing, and user creation in PostgreSQL",
"acceptance_criteria": "Users can register with valid email/password, passwords hashed with bcrypt, duplicate emails rejected with 409, validation errors return 400",
"technical_notes": "Use bcrypt cost 12, validate email format (RFC 5322), min password length 8, store in users table",
"test_requirements": "Unit tests for validation logic, integration tests for DB operations, >80% coverage"
},
"depends_on": ["0"],
"estimated_effort": "M"
},
{
"title": "Implement login endpoint with JWT generation",
"role_needed": "Coder",
"payload_context": {
"description": "Implement POST /api/v1/auth/login with credential verification and JWT token generation",
"acceptance_criteria": "Valid credentials return 200 with JWT token, invalid credentials return 401, token includes user_id and expires in 24h",
"technical_notes": "JWT with HS256, secret from env, include user_id in claims, set exp claim to 24h from now",
"test_requirements": "Unit tests for token generation, integration tests for auth flow, test token expiry"
},
"depends_on": ["0"],
"estimated_effort": "M"
},
{
"title": "Implement logout with token blacklist",
"role_needed": "Coder",
"payload_context": {
"description": "Implement POST /api/v1/auth/logout with token blacklist in Redis, and middleware to check blacklist",
"acceptance_criteria": "Logged out tokens are rejected with 401, blacklist entries expire after token TTL, middleware checks blacklist on protected routes",
"technical_notes": "Use Redis SET with TTL matching JWT exp claim, middleware extracts token and checks Redis before validating",
"test_requirements": "Integration tests for logout flow, test blacklist expiry, test middleware rejection"
},
"depends_on": ["0"],
"estimated_effort": "M"
},
{
"title": "Implement token verification middleware",
"role_needed": "Coder",
"payload_context": {
"description": "Implement middleware to verify JWT tokens on protected endpoints, check signature, expiry, and blacklist",
"acceptance_criteria": "Valid tokens allow access, expired/invalid/blacklisted tokens return 401, middleware can be applied to any route",
"technical_notes": "Extract token from Authorization header (Bearer scheme), verify signature and claims, check Redis blacklist",
"test_requirements": "Unit tests for token validation, integration tests with protected endpoints"
},
"depends_on": ["0"],
"estimated_effort": "S"
},
{
"title": "Integration tests for complete auth flow",
"role_needed": "QA_Engineer",
"payload_context": {
"description": "E2E tests for complete authentication flow: register → login → access protected endpoint → logout → verify token invalid",
"acceptance_criteria": "All auth scenarios covered: success paths, error cases (invalid credentials, expired token, blacklisted token), edge cases (malformed token, missing header)",
"technical_notes": "Use test database and Redis, clean up after each test, use real HTTP requests",
"test_requirements": "Cover happy path, all error cases, security edge cases, >90% scenario coverage"
},
"depends_on": ["1", "2", "3", "4"],
"estimated_effort": "M"
},
{
"title": "QC review for authentication system",
"role_needed": "QC_Reviewer",
"payload_context": {
"description": "Review code quality, security practices, test coverage, and OWASP compliance for authentication system",
"acceptance_criteria": "Code follows Go standards, OWASP Top 10 addressed (especially A01:Broken Access Control, A02:Cryptographic Failures, A07:Identification and Authentication Failures), test coverage >80%, no high/critical vulnerabilities",
"technical_notes": "Check for: SQL injection, XSS, password security (bcrypt cost, no plaintext), JWT security (strong secret, proper validation), rate limiting, input validation",
"test_requirements": "All tests passing, security scan clean (gosec, trivy), coverage report >80%"
},
"depends_on": ["5"],
"estimated_effort": "S"
}
]