mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-03-10 17:11:04 +08:00
- Introduced a comprehensive template for generating epics and stories in Phase 5, including an index and individual epic files. - Created a product brief template for Phase 2 to summarize product vision, goals, and target users. - Developed a requirements PRD template for Phase 3, outlining functional and non-functional requirements, along with traceability matrices. feat: Implement tech debt roles for assessment, execution, planning, scanning, validation, and analysis - Added roles for tech debt assessment, executor, planner, scanner, validator, and analyst, each with defined phases and processes for managing technical debt. - Each role includes structured input requirements, processing strategies, and output formats to ensure consistency and clarity in tech debt management.
4.5 KiB
4.5 KiB
Pipeline Definitions
1. Pipeline Selection Criteria
| Keywords | Pipeline |
|---|---|
| spec, design, document, requirements | spec-only |
| implement, build, fix, code | impl-only |
| full, lifecycle, end-to-end | full-lifecycle |
| frontend, UI, react, vue | fe-only or fullstack |
| Ambiguous / unclear | AskUserQuestion |
2. Spec-Only Pipeline
6 tasks, 3 discussion rounds
RESEARCH-001(+D1) -> DRAFT-001 -> DRAFT-002(+D2) -> DRAFT-003 -> DRAFT-004 -> QUALITY-001(+D3)
| Task | Role | Description | Discuss |
|---|---|---|---|
| RESEARCH-001 | analyst | Research domain, competitors, constraints | D1: scope alignment |
| DRAFT-001 | writer | Product brief, self-validate | - |
| DRAFT-002 | writer | Requirements PRD | D2: requirements review |
| DRAFT-003 | writer | Architecture design, self-validate | - |
| DRAFT-004 | writer | Epics & stories, self-validate | - |
| QUALITY-001 | reviewer | Quality gate scoring | D3: readiness decision |
Checkpoint: After QUALITY-001 -- pause for user approval before any implementation.
3. Impl-Only Pipeline
4 tasks, 0 discussion rounds
PLAN-001 -> IMPL-001 -> TEST-001 + REVIEW-001
| Task | Role | Description |
|---|---|---|
| PLAN-001 | planner | Break down into implementation steps, assess complexity |
| IMPL-001 | implementer | Execute implementation plan |
| TEST-001 | tester | Validate against acceptance criteria |
| REVIEW-001 | reviewer | Code review |
TEST-001 and REVIEW-001 run in parallel after IMPL-001 completes.
4. Full-Lifecycle Pipeline
10 tasks = spec-only (6) + impl (4)
[Spec pipeline] -> PLAN-001(blockedBy: QUALITY-001) -> IMPL-001 -> TEST-001 + REVIEW-001
PLAN-001 is blocked until QUALITY-001 passes and user approves the checkpoint.
5. Frontend Pipelines
| Pipeline | Description |
|---|---|
fe-only |
Frontend implementation only: PLAN-001 -> IMPL-001 (fe-implementer) -> TEST-001 + REVIEW-001 |
fullstack |
Backend + frontend: PLAN-001 -> IMPL-001 (backend) + IMPL-002 (frontend) -> TEST-001 + REVIEW-001 |
full-lifecycle-fe |
Full spec pipeline -> fullstack impl pipeline |
6. Conditional Routing
PLAN-001 outputs a complexity assessment that determines the impl topology.
| Complexity | Modules | Route |
|---|---|---|
| Low | 1-2 | PLAN-001 -> IMPL-001 -> TEST + REVIEW |
| Medium | 3-4 | PLAN-001 -> ORCH-001 -> IMPL-{1..N} (parallel) -> TEST + REVIEW |
| High | 5+ | PLAN-001 -> ARCH-001 -> ORCH-001 -> IMPL-{1..N} -> TEST + REVIEW |
- ORCH-001 (orchestrator): Coordinates parallel IMPL tasks, manages dependencies
- ARCH-001 (architect): Detailed architecture decisions before orchestration
7. Task Metadata Registry
| Task ID | Role | Phase | Depends On | Discuss | Priority |
|---|---|---|---|---|---|
| RESEARCH-001 | analyst | research | - | D1 | P0 |
| DRAFT-001 | writer | product-brief | RESEARCH-001 | - | P0 |
| DRAFT-002 | writer | requirements | DRAFT-001 | D2 | P0 |
| DRAFT-003 | writer | architecture | DRAFT-002 | - | P0 |
| DRAFT-004 | writer | epics | DRAFT-003 | - | P0 |
| QUALITY-001 | reviewer | readiness | DRAFT-004 | D3 | P0 |
| PLAN-001 | planner | planning | QUALITY-001 (or user input) | - | P0 |
| ARCH-001 | architect | arch-detail | PLAN-001 | - | P1 |
| ORCH-001 | orchestrator | orchestration | PLAN-001 or ARCH-001 | - | P1 |
| IMPL-001 | implementer | implementation | PLAN-001 or ORCH-001 | - | P0 |
| IMPL-{N} | implementer | implementation | ORCH-001 | - | P0 |
| TEST-001 | tester | validation | IMPL-* | - | P0 |
| REVIEW-001 | reviewer | review | IMPL-* | - | P0 |
8. Dynamic Specialist Injection
When task content or user request matches trigger keywords, inject a specialist task.
| Trigger Keywords | Specialist Role | Task Prefix | Priority | Insert After |
|---|---|---|---|---|
| security, vulnerability, OWASP | security-expert | SECURITY-* | P0 | PLAN |
| performance, optimization, latency | performance-optimizer | PERF-* | P1 | IMPL |
| data, pipeline, ETL, migration | data-engineer | DATA-* | P0 | parallel with IMPL |
| devops, CI/CD, deployment, infra | devops-engineer | DEVOPS-* | P1 | IMPL |
| ML, model, training, inference | ml-engineer | ML-* | P0 | parallel with IMPL |
Injection rules:
- Specialist tasks inherit the session context and wisdom
- They publish state_update on completion like any other task
- P0 specialists block downstream tasks; P1 run in parallel