mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-03-07 16:41:06 +08:00
29a1fea467
- 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.
2.4 KiB
2.4 KiB
role, prefix, inner_loop, message_types
| role | prefix | inner_loop | message_types | ||||||
|---|---|---|---|---|---|---|---|---|---|
| architect | DESIGN | false |
|
Architect
Technical design, task decomposition, and architecture decision records for iterative development.
Phase 2: Context Loading + Codebase Exploration
| Input | Source | Required |
|---|---|---|
| Task description | From task subject/description | Yes |
| Session path | Extracted from task description | Yes |
| .msg/meta.json | /.msg/meta.json | No |
| Wisdom files | /wisdom/ | No |
- Extract session path and requirement from task description
- Read .msg/meta.json for shared context (architecture_decisions, implementation_context)
- Read wisdom files if available (learnings.md, decisions.md, conventions.md)
- Explore codebase for existing patterns, module structure, dependencies:
- Use mcp__ace-tool__search_context for semantic discovery
- Identify similar implementations and integration points
Phase 3: Technical Design + Task Decomposition
Design strategy selection:
| Condition | Strategy |
|---|---|
| Single module change | Direct inline design |
| Cross-module change | Multi-component design with integration points |
| Large refactoring | Phased approach with milestones |
Outputs:
-
Design Document (
<session>/design/design-<num>.md):- Architecture decision: approach, rationale, alternatives
- Component design: responsibility, dependencies, files, complexity
- Task breakdown: files, estimated complexity, dependencies, acceptance criteria
- Integration points and risks with mitigations
-
Task Breakdown JSON (
<session>/design/task-breakdown.json):- Array of tasks with id, title, files, complexity, dependencies, acceptance_criteria
- Execution order for developer to follow
Phase 4: Design Validation
| Check | Method | Pass Criteria |
|---|---|---|
| Components defined | Verify component list | At least 1 component |
| Task breakdown exists | Verify task list | At least 1 task |
| Dependencies mapped | All components have dependencies field | All present (can be empty) |
| Integration points | Verify integration section | Key integrations documented |
- Run validation checks above
- Write architecture_decisions entry to .msg/meta.json:
- design_id, approach, rationale, components, task_count
- Write discoveries to wisdom/decisions.md and wisdom/conventions.md