universal-dev-standards 4.0.0 → 4.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bin/uds.js +75 -0
- package/bundled/core/ai-friendly-architecture.md +542 -0
- package/bundled/core/refactoring-standards.md +342 -120
- package/bundled/locales/zh-CN/README.md +210 -509
- package/bundled/locales/zh-CN/core/ai-friendly-architecture.md +306 -0
- package/bundled/locales/zh-CN/core/refactoring-standards.md +10 -9
- package/bundled/locales/zh-CN/docs/AI-AGENT-ROADMAP.md +82 -22
- package/bundled/locales/zh-CN/integrations/gemini-cli/GEMINI.md +35 -3
- package/bundled/locales/zh-CN/integrations/github-copilot/COPILOT-CHAT-REFERENCE.md +89 -3
- package/bundled/locales/zh-CN/integrations/github-copilot/skills-mapping.md +8 -4
- package/bundled/locales/zh-CN/skills/claude-code/commands/refactor.md +178 -0
- package/bundled/locales/zh-CN/skills/claude-code/refactoring-assistant/SKILL.md +243 -97
- package/bundled/locales/zh-TW/README.md +211 -490
- package/bundled/locales/zh-TW/core/ai-friendly-architecture.md +306 -0
- package/bundled/locales/zh-TW/core/refactoring-standards.md +347 -125
- package/bundled/locales/zh-TW/docs/AI-AGENT-ROADMAP.md +82 -22
- package/bundled/locales/zh-TW/integrations/gemini-cli/GEMINI.md +35 -3
- package/bundled/locales/zh-TW/integrations/github-copilot/COPILOT-CHAT-REFERENCE.md +89 -3
- package/bundled/locales/zh-TW/integrations/github-copilot/skills-mapping.md +8 -4
- package/bundled/locales/zh-TW/skills/claude-code/commands/refactor.md +178 -0
- package/bundled/locales/zh-TW/skills/claude-code/refactoring-assistant/SKILL.md +198 -52
- package/bundled/skills/claude-code/README.md +8 -0
- package/bundled/skills/claude-code/agents/README.md +305 -0
- package/bundled/skills/claude-code/agents/code-architect.md +259 -0
- package/bundled/skills/claude-code/agents/doc-writer.md +406 -0
- package/bundled/skills/claude-code/agents/reviewer.md +353 -0
- package/bundled/skills/claude-code/agents/spec-analyst.md +374 -0
- package/bundled/skills/claude-code/agents/test-specialist.md +364 -0
- package/bundled/skills/claude-code/commands/refactor.md +173 -0
- package/bundled/skills/claude-code/refactoring-assistant/SKILL.md +161 -63
- package/bundled/skills/claude-code/workflows/README.md +303 -0
- package/bundled/skills/claude-code/workflows/code-review.workflow.yaml +186 -0
- package/bundled/skills/claude-code/workflows/feature-dev.workflow.yaml +174 -0
- package/bundled/skills/claude-code/workflows/integrated-flow.workflow.yaml +238 -0
- package/bundled/skills/claude-code/workflows/large-codebase-analysis.workflow.yaml +226 -0
- package/package.json +11 -1
- package/src/commands/agent.js +417 -0
- package/src/commands/ai-context.js +552 -0
- package/src/commands/check.js +3 -3
- package/src/commands/init.js +6 -3
- package/src/commands/workflow.js +425 -0
- package/src/config/ai-agent-paths.js +217 -13
- package/src/core/constants.js +514 -0
- package/src/core/errors.js +398 -0
- package/src/core/manifest.js +473 -0
- package/src/core/paths.js +398 -0
- package/src/prompts/init.js +7 -5
- package/src/utils/agent-adapter.js +320 -0
- package/src/utils/agents-installer.js +393 -0
- package/src/utils/context-chunker.js +467 -0
- package/src/utils/copier.js +59 -99
- package/src/utils/hasher.js +2 -16
- package/src/utils/integration-generator.js +28 -52
- package/src/utils/workflows-installer.js +545 -0
- package/standards-registry.json +174 -24
|
@@ -0,0 +1,186 @@
|
|
|
1
|
+
# Code Review Workflow
|
|
2
|
+
# Comprehensive code review process
|
|
3
|
+
#
|
|
4
|
+
# This workflow guides a thorough code review process,
|
|
5
|
+
# ensuring quality, security, and maintainability.
|
|
6
|
+
|
|
7
|
+
name: code-review
|
|
8
|
+
version: 1.0.0
|
|
9
|
+
description: |
|
|
10
|
+
Comprehensive code review workflow for PRs and code changes.
|
|
11
|
+
Use for thorough review before merging to main branch.
|
|
12
|
+
Keywords: code review, PR review, pull request, 程式碼審查, PR 審查.
|
|
13
|
+
|
|
14
|
+
metadata:
|
|
15
|
+
author: universal-dev-standards
|
|
16
|
+
category: review
|
|
17
|
+
difficulty: intermediate
|
|
18
|
+
estimated_steps: 4
|
|
19
|
+
related_skills:
|
|
20
|
+
- code-review-assistant
|
|
21
|
+
- testing-guide
|
|
22
|
+
- checkin-assistant
|
|
23
|
+
|
|
24
|
+
prerequisites:
|
|
25
|
+
- Pull request created
|
|
26
|
+
- CI checks passing (or reasons documented)
|
|
27
|
+
- PR description complete
|
|
28
|
+
|
|
29
|
+
steps:
|
|
30
|
+
# Step 1: Context Understanding
|
|
31
|
+
- id: understand
|
|
32
|
+
name: Understand Context
|
|
33
|
+
type: agent
|
|
34
|
+
agent: spec-analyst
|
|
35
|
+
description: |
|
|
36
|
+
Understand the purpose and scope of the changes.
|
|
37
|
+
Review PR description, linked issues, and specs.
|
|
38
|
+
inputs:
|
|
39
|
+
- pr_description
|
|
40
|
+
- linked_issues
|
|
41
|
+
- diff_summary
|
|
42
|
+
outputs:
|
|
43
|
+
- context_summary
|
|
44
|
+
- review_focus_areas
|
|
45
|
+
questions:
|
|
46
|
+
- What problem does this solve?
|
|
47
|
+
- What is the expected behavior?
|
|
48
|
+
- What are the risks?
|
|
49
|
+
|
|
50
|
+
# Step 2: Code Quality Review
|
|
51
|
+
- id: quality-review
|
|
52
|
+
name: Code Quality Review
|
|
53
|
+
type: agent
|
|
54
|
+
agent: reviewer
|
|
55
|
+
description: |
|
|
56
|
+
Review code for quality, maintainability, and best practices.
|
|
57
|
+
Focus on readability, design patterns, and conventions.
|
|
58
|
+
inputs:
|
|
59
|
+
- code_changes
|
|
60
|
+
- context_summary
|
|
61
|
+
outputs:
|
|
62
|
+
- quality_report
|
|
63
|
+
- suggestions
|
|
64
|
+
checklist:
|
|
65
|
+
- Code follows project style guide
|
|
66
|
+
- Functions are appropriately sized
|
|
67
|
+
- No code duplication
|
|
68
|
+
- Error handling is appropriate
|
|
69
|
+
- Naming is clear and consistent
|
|
70
|
+
- Comments are helpful (not redundant)
|
|
71
|
+
severity_levels:
|
|
72
|
+
blocking: Must fix before merge
|
|
73
|
+
important: Should fix
|
|
74
|
+
suggestion: Nice to have
|
|
75
|
+
note: Informational
|
|
76
|
+
|
|
77
|
+
# Step 3: Security & Testing Review
|
|
78
|
+
- id: security-review
|
|
79
|
+
name: Security & Testing Review
|
|
80
|
+
type: agent
|
|
81
|
+
agent: test-specialist
|
|
82
|
+
description: |
|
|
83
|
+
Review for security vulnerabilities and test coverage.
|
|
84
|
+
Ensure changes are properly tested.
|
|
85
|
+
inputs:
|
|
86
|
+
- code_changes
|
|
87
|
+
- existing_tests
|
|
88
|
+
outputs:
|
|
89
|
+
- security_report
|
|
90
|
+
- coverage_assessment
|
|
91
|
+
security_checks:
|
|
92
|
+
- No hardcoded secrets
|
|
93
|
+
- Input validation present
|
|
94
|
+
- No SQL injection vulnerabilities
|
|
95
|
+
- No XSS vulnerabilities
|
|
96
|
+
- Proper authentication/authorization
|
|
97
|
+
- Dependencies are safe
|
|
98
|
+
testing_checks:
|
|
99
|
+
- New code has tests
|
|
100
|
+
- Edge cases covered
|
|
101
|
+
- Tests are meaningful (not just coverage)
|
|
102
|
+
- No flaky tests introduced
|
|
103
|
+
|
|
104
|
+
# Step 4: Final Decision
|
|
105
|
+
- id: decision
|
|
106
|
+
name: Review Decision
|
|
107
|
+
type: manual
|
|
108
|
+
description: |
|
|
109
|
+
Make final review decision based on findings.
|
|
110
|
+
Approve, request changes, or discuss.
|
|
111
|
+
inputs:
|
|
112
|
+
- quality_report
|
|
113
|
+
- security_report
|
|
114
|
+
- coverage_assessment
|
|
115
|
+
outputs:
|
|
116
|
+
- review_decision
|
|
117
|
+
- feedback_comments
|
|
118
|
+
decisions:
|
|
119
|
+
approve:
|
|
120
|
+
condition: No blocking issues
|
|
121
|
+
action: Approve PR
|
|
122
|
+
request_changes:
|
|
123
|
+
condition: Blocking issues found
|
|
124
|
+
action: Request changes with clear feedback
|
|
125
|
+
comment:
|
|
126
|
+
condition: Need clarification
|
|
127
|
+
action: Add comments and discuss
|
|
128
|
+
instructions: |
|
|
129
|
+
When providing feedback:
|
|
130
|
+
1. Use appropriate prefixes (BLOCKING, IMPORTANT, SUGGESTION)
|
|
131
|
+
2. Be specific about location and issue
|
|
132
|
+
3. Suggest solutions when possible
|
|
133
|
+
4. Be respectful and constructive
|
|
134
|
+
5. Acknowledge good practices
|
|
135
|
+
|
|
136
|
+
outputs:
|
|
137
|
+
- name: review_summary
|
|
138
|
+
description: Summary of review findings
|
|
139
|
+
format: markdown
|
|
140
|
+
|
|
141
|
+
- name: action_items
|
|
142
|
+
description: List of changes requested
|
|
143
|
+
format: checklist
|
|
144
|
+
|
|
145
|
+
- name: decision
|
|
146
|
+
description: Final review decision
|
|
147
|
+
format: status
|
|
148
|
+
|
|
149
|
+
# Review comment templates
|
|
150
|
+
comment_templates:
|
|
151
|
+
blocking: |
|
|
152
|
+
❗ BLOCKING: [Issue description]
|
|
153
|
+
|
|
154
|
+
[Why this is a problem]
|
|
155
|
+
|
|
156
|
+
Suggested fix:
|
|
157
|
+
```
|
|
158
|
+
[code suggestion]
|
|
159
|
+
```
|
|
160
|
+
|
|
161
|
+
important: |
|
|
162
|
+
⚠️ IMPORTANT: [Issue description]
|
|
163
|
+
|
|
164
|
+
[Why this should be addressed]
|
|
165
|
+
|
|
166
|
+
suggestion: |
|
|
167
|
+
💡 SUGGESTION: [Improvement idea]
|
|
168
|
+
|
|
169
|
+
[Rationale and benefits]
|
|
170
|
+
|
|
171
|
+
question: |
|
|
172
|
+
❓ QUESTION: [Your question]
|
|
173
|
+
|
|
174
|
+
[Context for the question]
|
|
175
|
+
|
|
176
|
+
note: |
|
|
177
|
+
📝 NOTE: [Observation]
|
|
178
|
+
|
|
179
|
+
[Additional context]
|
|
180
|
+
|
|
181
|
+
completion_criteria:
|
|
182
|
+
- All critical issues addressed or waived
|
|
183
|
+
- Security review completed
|
|
184
|
+
- Test coverage acceptable
|
|
185
|
+
- Review decision documented
|
|
186
|
+
- Feedback provided constructively
|
|
@@ -0,0 +1,174 @@
|
|
|
1
|
+
# Feature Development Workflow
|
|
2
|
+
# Standard workflow for developing new features
|
|
3
|
+
#
|
|
4
|
+
# This workflow guides the development of new features from requirements
|
|
5
|
+
# through implementation and review.
|
|
6
|
+
|
|
7
|
+
name: feature-dev
|
|
8
|
+
version: 1.0.0
|
|
9
|
+
description: |
|
|
10
|
+
Standard feature development workflow from requirements to deployment.
|
|
11
|
+
Use for typical feature work with balanced rigor and efficiency.
|
|
12
|
+
Keywords: feature, development, implementation, 功能開發, 開發流程.
|
|
13
|
+
|
|
14
|
+
metadata:
|
|
15
|
+
author: universal-dev-standards
|
|
16
|
+
category: development
|
|
17
|
+
difficulty: intermediate
|
|
18
|
+
estimated_steps: 6
|
|
19
|
+
related_skills:
|
|
20
|
+
- spec-driven-dev
|
|
21
|
+
- testing-guide
|
|
22
|
+
- code-review-assistant
|
|
23
|
+
|
|
24
|
+
prerequisites:
|
|
25
|
+
- User story or feature request defined
|
|
26
|
+
- Git branch created (feature/xxx)
|
|
27
|
+
- Development environment ready
|
|
28
|
+
|
|
29
|
+
steps:
|
|
30
|
+
# Step 1: Requirements Analysis
|
|
31
|
+
- id: analyze
|
|
32
|
+
name: Analyze Requirements
|
|
33
|
+
type: agent
|
|
34
|
+
agent: spec-analyst
|
|
35
|
+
description: |
|
|
36
|
+
Analyze the feature request and clarify requirements.
|
|
37
|
+
Identify acceptance criteria and potential challenges.
|
|
38
|
+
inputs:
|
|
39
|
+
- feature_request
|
|
40
|
+
- existing_codebase_context
|
|
41
|
+
outputs:
|
|
42
|
+
- requirements_analysis
|
|
43
|
+
- acceptance_criteria
|
|
44
|
+
- technical_considerations
|
|
45
|
+
checklist:
|
|
46
|
+
- Requirements understood
|
|
47
|
+
- Questions clarified
|
|
48
|
+
- Scope defined
|
|
49
|
+
|
|
50
|
+
# Step 2: Architecture Design
|
|
51
|
+
- id: design
|
|
52
|
+
name: Design Architecture
|
|
53
|
+
type: agent
|
|
54
|
+
agent: code-architect
|
|
55
|
+
description: |
|
|
56
|
+
Design the technical architecture for the feature.
|
|
57
|
+
Identify components, interfaces, and data flow.
|
|
58
|
+
inputs:
|
|
59
|
+
- requirements_analysis
|
|
60
|
+
- existing_architecture
|
|
61
|
+
outputs:
|
|
62
|
+
- architecture_design
|
|
63
|
+
- component_list
|
|
64
|
+
- api_contracts
|
|
65
|
+
considerations:
|
|
66
|
+
- Reuse existing components where possible
|
|
67
|
+
- Follow project patterns and conventions
|
|
68
|
+
- Consider performance and scalability
|
|
69
|
+
|
|
70
|
+
# Step 3: Test Planning
|
|
71
|
+
- id: test-plan
|
|
72
|
+
name: Plan Tests
|
|
73
|
+
type: agent
|
|
74
|
+
agent: test-specialist
|
|
75
|
+
description: |
|
|
76
|
+
Define testing strategy for the feature.
|
|
77
|
+
Identify test cases at different levels.
|
|
78
|
+
inputs:
|
|
79
|
+
- acceptance_criteria
|
|
80
|
+
- architecture_design
|
|
81
|
+
outputs:
|
|
82
|
+
- test_plan
|
|
83
|
+
- test_cases
|
|
84
|
+
test_levels:
|
|
85
|
+
- unit: Core logic functions
|
|
86
|
+
- integration: Component interactions
|
|
87
|
+
- e2e: Critical user paths
|
|
88
|
+
|
|
89
|
+
# Step 4: Implementation
|
|
90
|
+
- id: implement
|
|
91
|
+
name: Implement Feature
|
|
92
|
+
type: manual
|
|
93
|
+
description: |
|
|
94
|
+
Implement the feature following the design and test plan.
|
|
95
|
+
Use TDD approach where appropriate.
|
|
96
|
+
inputs:
|
|
97
|
+
- architecture_design
|
|
98
|
+
- test_plan
|
|
99
|
+
outputs:
|
|
100
|
+
- implementation_code
|
|
101
|
+
- tests
|
|
102
|
+
instructions: |
|
|
103
|
+
Implementation guidelines:
|
|
104
|
+
1. Start with tests (TDD recommended)
|
|
105
|
+
2. Implement core functionality first
|
|
106
|
+
3. Add edge case handling
|
|
107
|
+
4. Run tests frequently
|
|
108
|
+
5. Commit in logical chunks
|
|
109
|
+
checklist:
|
|
110
|
+
- Core functionality implemented
|
|
111
|
+
- Unit tests written and passing
|
|
112
|
+
- Integration tests passing
|
|
113
|
+
- No linting errors
|
|
114
|
+
- Code committed
|
|
115
|
+
|
|
116
|
+
# Step 5: Self Review
|
|
117
|
+
- id: self-review
|
|
118
|
+
name: Self Code Review
|
|
119
|
+
type: agent
|
|
120
|
+
agent: reviewer
|
|
121
|
+
description: |
|
|
122
|
+
Perform self-review before requesting peer review.
|
|
123
|
+
Check for common issues and improvements.
|
|
124
|
+
inputs:
|
|
125
|
+
- implementation_code
|
|
126
|
+
- tests
|
|
127
|
+
outputs:
|
|
128
|
+
- self_review_report
|
|
129
|
+
- improvement_suggestions
|
|
130
|
+
focus_areas:
|
|
131
|
+
- Code quality and style
|
|
132
|
+
- Test coverage
|
|
133
|
+
- Security considerations
|
|
134
|
+
- Performance implications
|
|
135
|
+
|
|
136
|
+
# Step 6: Documentation
|
|
137
|
+
- id: document
|
|
138
|
+
name: Update Documentation
|
|
139
|
+
type: agent
|
|
140
|
+
agent: doc-writer
|
|
141
|
+
description: |
|
|
142
|
+
Update relevant documentation for the new feature.
|
|
143
|
+
Include API docs, user guides, and changelog.
|
|
144
|
+
inputs:
|
|
145
|
+
- implementation_code
|
|
146
|
+
- architecture_design
|
|
147
|
+
outputs:
|
|
148
|
+
- updated_docs
|
|
149
|
+
- changelog_entry
|
|
150
|
+
documentation_types:
|
|
151
|
+
- API documentation
|
|
152
|
+
- User-facing documentation
|
|
153
|
+
- CHANGELOG entry
|
|
154
|
+
- README updates (if needed)
|
|
155
|
+
|
|
156
|
+
outputs:
|
|
157
|
+
- name: feature_branch
|
|
158
|
+
description: Git branch with implemented feature
|
|
159
|
+
format: git-branch
|
|
160
|
+
|
|
161
|
+
- name: test_suite
|
|
162
|
+
description: Tests for the feature
|
|
163
|
+
format: varies
|
|
164
|
+
|
|
165
|
+
- name: documentation
|
|
166
|
+
description: Updated documentation
|
|
167
|
+
format: markdown
|
|
168
|
+
|
|
169
|
+
completion_criteria:
|
|
170
|
+
- All acceptance criteria met
|
|
171
|
+
- Tests passing
|
|
172
|
+
- Self-review completed
|
|
173
|
+
- Documentation updated
|
|
174
|
+
- Ready for peer review/PR
|
|
@@ -0,0 +1,238 @@
|
|
|
1
|
+
# Integrated Development Flow Workflow
|
|
2
|
+
# Complete ATDD → SDD → BDD → TDD development cycle
|
|
3
|
+
#
|
|
4
|
+
# This workflow orchestrates the full software development lifecycle,
|
|
5
|
+
# integrating acceptance testing, specification, behavior, and test-driven approaches.
|
|
6
|
+
|
|
7
|
+
name: integrated-flow
|
|
8
|
+
version: 1.0.0
|
|
9
|
+
description: |
|
|
10
|
+
Complete development workflow integrating ATDD, SDD, BDD, and TDD methodologies.
|
|
11
|
+
Use for comprehensive feature development with full traceability from requirements to tests.
|
|
12
|
+
Keywords: ATDD, SDD, BDD, TDD, integrated, full-cycle, 整合流程, 完整開發.
|
|
13
|
+
|
|
14
|
+
metadata:
|
|
15
|
+
author: universal-dev-standards
|
|
16
|
+
category: development
|
|
17
|
+
difficulty: advanced
|
|
18
|
+
estimated_steps: 8
|
|
19
|
+
related_skills:
|
|
20
|
+
- atdd-assistant
|
|
21
|
+
- spec-driven-dev
|
|
22
|
+
- bdd-assistant
|
|
23
|
+
- tdd-assistant
|
|
24
|
+
|
|
25
|
+
prerequisites:
|
|
26
|
+
- Project initialized with UDS standards
|
|
27
|
+
- Git repository configured
|
|
28
|
+
- Test framework set up
|
|
29
|
+
- AI tool with Task support (recommended)
|
|
30
|
+
|
|
31
|
+
# Workflow execution steps
|
|
32
|
+
steps:
|
|
33
|
+
# Phase 1: ATDD - Acceptance Test-Driven Development
|
|
34
|
+
- id: specification-workshop
|
|
35
|
+
name: Specification Workshop
|
|
36
|
+
phase: ATDD
|
|
37
|
+
type: agent
|
|
38
|
+
agent: spec-analyst
|
|
39
|
+
description: |
|
|
40
|
+
Conduct specification workshop to define acceptance criteria.
|
|
41
|
+
Involves stakeholder collaboration to clarify requirements.
|
|
42
|
+
inputs:
|
|
43
|
+
- user_story
|
|
44
|
+
- business_context
|
|
45
|
+
outputs:
|
|
46
|
+
- acceptance_criteria
|
|
47
|
+
- test_scenarios
|
|
48
|
+
checklist:
|
|
49
|
+
- Stakeholders identified
|
|
50
|
+
- User story clarified
|
|
51
|
+
- Acceptance criteria in Given-When-Then format
|
|
52
|
+
- Edge cases documented
|
|
53
|
+
|
|
54
|
+
# Phase 2: SDD - Spec-Driven Development
|
|
55
|
+
- id: spec-proposal
|
|
56
|
+
name: Specification Proposal
|
|
57
|
+
phase: SDD
|
|
58
|
+
type: agent
|
|
59
|
+
agent: spec-analyst
|
|
60
|
+
description: |
|
|
61
|
+
Draft formal specification document based on acceptance criteria.
|
|
62
|
+
Include technical design, API contracts, and data models.
|
|
63
|
+
inputs:
|
|
64
|
+
- acceptance_criteria
|
|
65
|
+
- test_scenarios
|
|
66
|
+
outputs:
|
|
67
|
+
- spec_document
|
|
68
|
+
template: |
|
|
69
|
+
# SPEC-XXX: [Feature Name]
|
|
70
|
+
|
|
71
|
+
## Summary
|
|
72
|
+
[Brief description]
|
|
73
|
+
|
|
74
|
+
## Acceptance Criteria
|
|
75
|
+
[From workshop]
|
|
76
|
+
|
|
77
|
+
## Technical Design
|
|
78
|
+
[Architecture, components]
|
|
79
|
+
|
|
80
|
+
## API Contract
|
|
81
|
+
[Endpoints, data structures]
|
|
82
|
+
|
|
83
|
+
## Risks & Mitigations
|
|
84
|
+
[Identified risks]
|
|
85
|
+
|
|
86
|
+
- id: spec-review
|
|
87
|
+
name: Specification Review
|
|
88
|
+
phase: SDD
|
|
89
|
+
type: manual
|
|
90
|
+
description: |
|
|
91
|
+
Review and approve specification document.
|
|
92
|
+
Ensure technical feasibility and alignment with requirements.
|
|
93
|
+
inputs:
|
|
94
|
+
- spec_document
|
|
95
|
+
outputs:
|
|
96
|
+
- approved_spec
|
|
97
|
+
instructions: |
|
|
98
|
+
Review the specification document:
|
|
99
|
+
1. Verify technical accuracy
|
|
100
|
+
2. Check acceptance criteria completeness
|
|
101
|
+
3. Assess risks and mitigations
|
|
102
|
+
4. Approve or request changes
|
|
103
|
+
checklist:
|
|
104
|
+
- Technical design is sound
|
|
105
|
+
- Acceptance criteria are testable
|
|
106
|
+
- Risks are acceptable
|
|
107
|
+
- Stakeholders approved
|
|
108
|
+
|
|
109
|
+
# Phase 3: BDD - Behavior-Driven Development
|
|
110
|
+
- id: discovery
|
|
111
|
+
name: BDD Discovery
|
|
112
|
+
phase: BDD
|
|
113
|
+
type: agent
|
|
114
|
+
agent: test-specialist
|
|
115
|
+
description: |
|
|
116
|
+
Discover and formulate BDD scenarios from approved spec.
|
|
117
|
+
Generate Gherkin feature files.
|
|
118
|
+
inputs:
|
|
119
|
+
- approved_spec
|
|
120
|
+
outputs:
|
|
121
|
+
- feature_files
|
|
122
|
+
- scenario_outlines
|
|
123
|
+
example_output: |
|
|
124
|
+
Feature: User Authentication
|
|
125
|
+
As a user
|
|
126
|
+
I want to log in with my credentials
|
|
127
|
+
So that I can access my account
|
|
128
|
+
|
|
129
|
+
Scenario: Successful login
|
|
130
|
+
Given I am on the login page
|
|
131
|
+
When I enter valid credentials
|
|
132
|
+
Then I should be redirected to dashboard
|
|
133
|
+
|
|
134
|
+
- id: formulation
|
|
135
|
+
name: BDD Formulation
|
|
136
|
+
phase: BDD
|
|
137
|
+
type: manual
|
|
138
|
+
description: |
|
|
139
|
+
Review and refine BDD scenarios with stakeholders.
|
|
140
|
+
Ensure scenarios are clear and testable.
|
|
141
|
+
inputs:
|
|
142
|
+
- feature_files
|
|
143
|
+
outputs:
|
|
144
|
+
- refined_features
|
|
145
|
+
checklist:
|
|
146
|
+
- Scenarios cover all acceptance criteria
|
|
147
|
+
- Language is clear to all stakeholders
|
|
148
|
+
- Examples are realistic
|
|
149
|
+
- Edge cases included
|
|
150
|
+
|
|
151
|
+
# Phase 4: TDD - Test-Driven Development
|
|
152
|
+
- id: tdd-red
|
|
153
|
+
name: TDD Red Phase
|
|
154
|
+
phase: TDD
|
|
155
|
+
type: agent
|
|
156
|
+
agent: test-specialist
|
|
157
|
+
description: |
|
|
158
|
+
Write failing tests based on BDD scenarios.
|
|
159
|
+
Tests should be minimal and focused.
|
|
160
|
+
inputs:
|
|
161
|
+
- refined_features
|
|
162
|
+
outputs:
|
|
163
|
+
- failing_tests
|
|
164
|
+
instructions: |
|
|
165
|
+
For each BDD scenario:
|
|
166
|
+
1. Write unit test that captures behavior
|
|
167
|
+
2. Run test to verify it fails
|
|
168
|
+
3. Document test purpose
|
|
169
|
+
|
|
170
|
+
- id: tdd-green
|
|
171
|
+
name: TDD Green Phase
|
|
172
|
+
phase: TDD
|
|
173
|
+
type: manual
|
|
174
|
+
description: |
|
|
175
|
+
Implement minimum code to make tests pass.
|
|
176
|
+
Focus on functionality, not optimization.
|
|
177
|
+
inputs:
|
|
178
|
+
- failing_tests
|
|
179
|
+
outputs:
|
|
180
|
+
- passing_implementation
|
|
181
|
+
instructions: |
|
|
182
|
+
Implementation guidelines:
|
|
183
|
+
1. Write minimum code to pass tests
|
|
184
|
+
2. Do not optimize yet
|
|
185
|
+
3. Commit when tests pass
|
|
186
|
+
checklist:
|
|
187
|
+
- All tests pass
|
|
188
|
+
- No extra functionality added
|
|
189
|
+
- Code committed
|
|
190
|
+
|
|
191
|
+
- id: tdd-refactor
|
|
192
|
+
name: TDD Refactor Phase
|
|
193
|
+
phase: TDD
|
|
194
|
+
type: agent
|
|
195
|
+
agent: reviewer
|
|
196
|
+
description: |
|
|
197
|
+
Refactor implementation while maintaining passing tests.
|
|
198
|
+
Review code quality and suggest improvements.
|
|
199
|
+
inputs:
|
|
200
|
+
- passing_implementation
|
|
201
|
+
outputs:
|
|
202
|
+
- refactored_code
|
|
203
|
+
- review_report
|
|
204
|
+
checklist:
|
|
205
|
+
- Code follows project standards
|
|
206
|
+
- No code duplication
|
|
207
|
+
- Tests still pass
|
|
208
|
+
- Documentation updated
|
|
209
|
+
|
|
210
|
+
# Final outputs
|
|
211
|
+
outputs:
|
|
212
|
+
- name: spec_document
|
|
213
|
+
description: Approved specification document
|
|
214
|
+
format: markdown
|
|
215
|
+
path: specs/SPEC-XXX.md
|
|
216
|
+
|
|
217
|
+
- name: feature_files
|
|
218
|
+
description: BDD feature files
|
|
219
|
+
format: gherkin
|
|
220
|
+
path: features/
|
|
221
|
+
|
|
222
|
+
- name: test_suite
|
|
223
|
+
description: TDD test files
|
|
224
|
+
format: varies
|
|
225
|
+
path: tests/
|
|
226
|
+
|
|
227
|
+
- name: implementation
|
|
228
|
+
description: Refactored implementation
|
|
229
|
+
format: varies
|
|
230
|
+
path: src/
|
|
231
|
+
|
|
232
|
+
# Workflow completion criteria
|
|
233
|
+
completion_criteria:
|
|
234
|
+
- All acceptance criteria met
|
|
235
|
+
- All tests passing
|
|
236
|
+
- Code reviewed and approved
|
|
237
|
+
- Documentation updated
|
|
238
|
+
- Spec archived with links to implementation
|