agentic-code 0.5.1 → 0.6.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/.agents/context-maps/{task-rule-matrix.yaml → task-skills-matrix.yaml} +98 -110
- package/.agents/{rules/core/ai-development-guide.md → skills/ai-development-guide/SKILL.md} +9 -2
- package/.agents/{rules/language/general/rules.md → skills/coding-rules/SKILL.md} +14 -2
- package/.agents/{rules/language/typescript/rules.md → skills/coding-rules/references/typescript.md} +18 -54
- package/.agents/{rules/core/documentation-criteria.md → skills/documentation-criteria/SKILL.md} +8 -1
- package/.agents/{rules/contextual/architecture/implementation-approach.md → skills/implementation-approach/SKILL.md} +8 -1
- package/.agents/{rules/core/integration-e2e-testing.md → skills/integration-e2e-testing/SKILL.md} +7 -0
- package/.agents/{rules/core/metacognition.md → skills/metacognition/SKILL.md} +10 -3
- package/.agents/{rules/language/general/testing.md → skills/testing/SKILL.md} +17 -32
- package/.agents/skills/testing/references/typescript.md +134 -0
- package/.agents/{rules/core/testing-strategy.md → skills/testing-strategy/SKILL.md} +7 -0
- package/.agents/tasks/acceptance-test-generation.md +38 -38
- package/.agents/tasks/code-review.md +6 -6
- package/.agents/tasks/implementation.md +34 -34
- package/.agents/tasks/integration-test-review.md +8 -8
- package/.agents/tasks/prd-creation.md +20 -20
- package/.agents/tasks/quality-assurance.md +26 -26
- package/.agents/tasks/task-analysis.md +20 -20
- package/.agents/tasks/technical-design.md +26 -26
- package/.agents/tasks/technical-document-review.md +8 -8
- package/.agents/tasks/work-planning.md +39 -39
- package/.agents/workflows/agentic-coding.md +30 -30
- package/AGENTS.md +20 -32
- package/README.md +18 -16
- package/bin/cli.js +6 -17
- package/bin/install-codex-skills.js +127 -0
- package/package.json +9 -12
- package/.agents/rules/language/typescript/testing.md +0 -284
- package/scripts/setup.js +0 -82
|
@@ -1,11 +1,11 @@
|
|
|
1
|
-
# Task-
|
|
2
|
-
# Maps tasks to relevant
|
|
3
|
-
# Used by task-analysis.md to recommend appropriate
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
# Core
|
|
7
|
-
|
|
8
|
-
path: ".agents/
|
|
1
|
+
# Task-Skill Mapping Matrix
|
|
2
|
+
# Maps tasks to relevant skills based on metadata and tags
|
|
3
|
+
# Used by task-analysis.md to recommend appropriate skills for each task type
|
|
4
|
+
|
|
5
|
+
skills:
|
|
6
|
+
# Core Skills
|
|
7
|
+
metacognition:
|
|
8
|
+
path: ".agents/skills/metacognition/SKILL.md"
|
|
9
9
|
tags: [self-assessment, reflection, decision-checkpoint, quality-control]
|
|
10
10
|
when_to_load:
|
|
11
11
|
- "Task type changes (e.g., from design to implementation)"
|
|
@@ -17,8 +17,8 @@ rules:
|
|
|
17
17
|
priority: always
|
|
18
18
|
description: "Self-assessment and reflection protocols for maintaining quality"
|
|
19
19
|
|
|
20
|
-
|
|
21
|
-
path: ".agents/
|
|
20
|
+
ai-development-guide:
|
|
21
|
+
path: ".agents/skills/ai-development-guide/SKILL.md"
|
|
22
22
|
tags: [anti-patterns, debugging, best-practices, rule-of-three, technical-debt, impact-analysis, unused-code, code-deletion, implementation-completeness]
|
|
23
23
|
when_to_load:
|
|
24
24
|
- "Starting new implementation"
|
|
@@ -31,8 +31,8 @@ rules:
|
|
|
31
31
|
priority: high
|
|
32
32
|
description: "Anti-patterns, debugging techniques, development best practices, and implementation completeness assurance"
|
|
33
33
|
|
|
34
|
-
|
|
35
|
-
path: ".agents/
|
|
34
|
+
documentation-criteria:
|
|
35
|
+
path: ".agents/skills/documentation-criteria/SKILL.md"
|
|
36
36
|
tags: [documentation, adr, design-doc, decision-matrix, scale-assessment]
|
|
37
37
|
when_to_load:
|
|
38
38
|
- "Task scale assessment (Small/Medium/Large)"
|
|
@@ -44,8 +44,8 @@ rules:
|
|
|
44
44
|
priority: medium
|
|
45
45
|
description: "Criteria for when and how to create documentation"
|
|
46
46
|
|
|
47
|
-
|
|
48
|
-
path: ".agents/
|
|
47
|
+
testing-strategy:
|
|
48
|
+
path: ".agents/skills/testing-strategy/SKILL.md"
|
|
49
49
|
tags: [testing, roi-calculation, test-selection, budget-enforcement, behavior-first]
|
|
50
50
|
when_to_load:
|
|
51
51
|
- "Generating acceptance tests from design documents"
|
|
@@ -57,8 +57,8 @@ rules:
|
|
|
57
57
|
priority: high
|
|
58
58
|
description: "ROI-based test selection framework with behavior-first filtering and budget enforcement"
|
|
59
59
|
|
|
60
|
-
|
|
61
|
-
path: ".agents/
|
|
60
|
+
integration-e2e-testing:
|
|
61
|
+
path: ".agents/skills/integration-e2e-testing/SKILL.md"
|
|
62
62
|
tags: [testing, integration-test, e2e-test, behavior-first, mock-boundary, test-review]
|
|
63
63
|
when_to_load:
|
|
64
64
|
- "Generating integration/E2E test skeletons"
|
|
@@ -69,180 +69,168 @@ rules:
|
|
|
69
69
|
priority: high
|
|
70
70
|
description: "Integration and E2E test design, implementation rules, and review criteria"
|
|
71
71
|
|
|
72
|
-
#
|
|
73
|
-
|
|
74
|
-
path: ".agents/
|
|
75
|
-
tags: [
|
|
72
|
+
# Architecture Skills
|
|
73
|
+
implementation-approach:
|
|
74
|
+
path: ".agents/skills/implementation-approach/SKILL.md"
|
|
75
|
+
tags: [strategy-selection, task-decomposition, verification-levels, integration-points]
|
|
76
|
+
when_to_load:
|
|
77
|
+
- "Medium/Large scale tasks (3+ files)"
|
|
78
|
+
- "Implementation strategy selection"
|
|
79
|
+
- "Task breakdown and planning"
|
|
80
|
+
- "Choosing between vertical/horizontal slicing"
|
|
81
|
+
typical_tasks: [planning, design, implementation]
|
|
82
|
+
size: medium
|
|
83
|
+
priority: conditional
|
|
84
|
+
description: "Strategy selection for implementation approaches (vertical/horizontal slicing)"
|
|
85
|
+
|
|
86
|
+
# Development Skills (with language-specific references)
|
|
87
|
+
coding-rules:
|
|
88
|
+
path: ".agents/skills/coding-rules/SKILL.md"
|
|
89
|
+
references:
|
|
90
|
+
typescript: ".agents/skills/coding-rules/references/typescript.md"
|
|
91
|
+
tags: [implementation, coding-style, error-handling, refactoring, clean-code, solid-principles]
|
|
76
92
|
when_to_load:
|
|
77
93
|
- "Writing or modifying code"
|
|
78
94
|
- "Code review"
|
|
79
95
|
- "Refactoring existing code"
|
|
80
96
|
- "Implementing new features"
|
|
81
97
|
typical_tasks: [implementation, refactoring]
|
|
82
|
-
size:
|
|
98
|
+
size: medium
|
|
83
99
|
priority: high
|
|
84
|
-
description: "
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
- "Type/static safety (for typed languages)"
|
|
92
|
-
- "Async/concurrent programming patterns"
|
|
93
|
-
- "Function composition over classes"
|
|
94
|
-
|
|
95
|
-
language/testing:
|
|
96
|
-
path: ".agents/rules/language/testing.md"
|
|
97
|
-
tags: [testing, tdd, quality-assurance, coverage, unit-tests, integration-tests, verify-phase, test-skeleton]
|
|
100
|
+
description: "Coding standards and best practices (includes language-specific references)"
|
|
101
|
+
|
|
102
|
+
testing:
|
|
103
|
+
path: ".agents/skills/testing/SKILL.md"
|
|
104
|
+
references:
|
|
105
|
+
typescript: ".agents/skills/testing/references/typescript.md"
|
|
106
|
+
tags: [testing, tdd, quality-assurance, coverage, unit-tests, integration-tests, verify-phase]
|
|
98
107
|
when_to_load:
|
|
99
108
|
- "Writing tests"
|
|
100
109
|
- "Bug fixing (test-first)"
|
|
101
110
|
- "Quality checks"
|
|
102
111
|
- "Refactoring (ensuring safety)"
|
|
103
112
|
- "VERIFY phase execution (mandatory)"
|
|
104
|
-
- "Test skeleton generation from acceptance criteria"
|
|
105
113
|
typical_tasks: [implementation, debugging, quality-check, test_generation]
|
|
106
114
|
size: medium
|
|
107
115
|
priority: always
|
|
108
|
-
description: "Testing standards
|
|
109
|
-
universal_concepts:
|
|
110
|
-
- "Red-Green-Refactor cycle"
|
|
111
|
-
- "Test independence"
|
|
112
|
-
- "AAA pattern (Arrange-Act-Assert)"
|
|
113
|
-
- "Coverage requirements (70%+)"
|
|
114
|
-
- "Mock/stub patterns"
|
|
115
|
-
- "Unit vs Integration testing"
|
|
116
|
-
- "Test-first development"
|
|
117
|
-
|
|
118
|
-
contextual/architecture/implementation-approach:
|
|
119
|
-
path: ".agents/rules/contextual/architecture/implementation-approach.md"
|
|
120
|
-
tags: [strategy-selection, task-decomposition, verification-levels, integration-points]
|
|
121
|
-
when_to_load:
|
|
122
|
-
- "Medium/Large scale tasks (3+ files)"
|
|
123
|
-
- "Implementation strategy selection"
|
|
124
|
-
- "Task breakdown and planning"
|
|
125
|
-
- "Choosing between vertical/horizontal slicing"
|
|
126
|
-
typical_tasks: [planning, design, implementation]
|
|
127
|
-
size: medium
|
|
128
|
-
priority: conditional
|
|
129
|
-
description: "Strategy selection for implementation approaches (vertical/horizontal slicing)"
|
|
116
|
+
description: "Testing standards and TDD practices (includes language-specific references)"
|
|
130
117
|
|
|
131
118
|
|
|
132
|
-
# Task Type to
|
|
119
|
+
# Task Type to Skill Mapping
|
|
133
120
|
task_mappings:
|
|
134
121
|
prd_creation:
|
|
135
122
|
required:
|
|
136
|
-
- "
|
|
123
|
+
- "documentation-criteria"
|
|
137
124
|
recommended:
|
|
138
|
-
- "
|
|
125
|
+
- "metacognition"
|
|
139
126
|
|
|
140
127
|
implementation:
|
|
141
128
|
required:
|
|
142
|
-
- "
|
|
143
|
-
- "
|
|
144
|
-
- "
|
|
129
|
+
- "coding-rules"
|
|
130
|
+
- "testing" # TDD is mandatory
|
|
131
|
+
- "ai-development-guide"
|
|
145
132
|
recommended:
|
|
146
|
-
- "
|
|
133
|
+
- "metacognition"
|
|
147
134
|
conditional:
|
|
148
|
-
- "
|
|
135
|
+
- "implementation-approach" # For Medium/Large scale
|
|
149
136
|
|
|
150
137
|
debugging:
|
|
151
138
|
required:
|
|
152
|
-
- "
|
|
153
|
-
- "
|
|
139
|
+
- "ai-development-guide"
|
|
140
|
+
- "testing"
|
|
154
141
|
recommended:
|
|
155
|
-
- "
|
|
156
|
-
- "
|
|
142
|
+
- "coding-rules"
|
|
143
|
+
- "metacognition"
|
|
157
144
|
|
|
158
145
|
design:
|
|
159
146
|
required:
|
|
160
|
-
- "
|
|
147
|
+
- "documentation-criteria"
|
|
161
148
|
conditional:
|
|
162
|
-
- "
|
|
149
|
+
- "implementation-approach" # Required for Medium/Large scale (3+ files)
|
|
163
150
|
|
|
164
151
|
documentation:
|
|
165
152
|
required:
|
|
166
|
-
- "
|
|
153
|
+
- "documentation-criteria"
|
|
167
154
|
|
|
168
155
|
refactoring:
|
|
169
156
|
required:
|
|
170
|
-
- "
|
|
171
|
-
- "
|
|
172
|
-
- "
|
|
157
|
+
- "coding-rules"
|
|
158
|
+
- "testing"
|
|
159
|
+
- "ai-development-guide"
|
|
173
160
|
recommended:
|
|
174
|
-
- "
|
|
161
|
+
- "metacognition"
|
|
175
162
|
|
|
176
163
|
research:
|
|
177
164
|
recommended:
|
|
178
|
-
- "
|
|
165
|
+
- "metacognition"
|
|
179
166
|
|
|
180
167
|
test_generation:
|
|
181
168
|
required:
|
|
182
|
-
- "
|
|
183
|
-
- "
|
|
184
|
-
- "
|
|
185
|
-
- "
|
|
169
|
+
- "testing"
|
|
170
|
+
- "documentation-criteria"
|
|
171
|
+
- "testing-strategy"
|
|
172
|
+
- "integration-e2e-testing"
|
|
186
173
|
recommended:
|
|
187
|
-
- "
|
|
174
|
+
- "metacognition"
|
|
188
175
|
|
|
189
176
|
integration_test_review:
|
|
190
177
|
required:
|
|
191
|
-
- "
|
|
192
|
-
- "
|
|
178
|
+
- "testing"
|
|
179
|
+
- "integration-e2e-testing"
|
|
193
180
|
recommended:
|
|
194
|
-
- "
|
|
181
|
+
- "metacognition"
|
|
195
182
|
description: "Review integration and E2E test implementations"
|
|
196
183
|
|
|
197
184
|
code_review:
|
|
198
185
|
required:
|
|
199
|
-
- "
|
|
200
|
-
- "
|
|
186
|
+
- "coding-rules"
|
|
187
|
+
- "ai-development-guide"
|
|
201
188
|
recommended:
|
|
202
|
-
- "
|
|
189
|
+
- "metacognition"
|
|
203
190
|
description: "Review implementation against Design Doc compliance"
|
|
204
191
|
|
|
205
192
|
technical_document_review:
|
|
206
193
|
required:
|
|
207
|
-
- "
|
|
194
|
+
- "documentation-criteria"
|
|
208
195
|
conditional:
|
|
209
|
-
- "
|
|
210
|
-
- "
|
|
196
|
+
- "testing-strategy"
|
|
197
|
+
- "coding-rules"
|
|
211
198
|
recommended:
|
|
212
|
-
- "
|
|
199
|
+
- "metacognition"
|
|
213
200
|
description: "Review technical documents (Design Docs, ADRs)"
|
|
214
201
|
|
|
215
|
-
# Scale-based
|
|
202
|
+
# Scale-based Skill Loading
|
|
216
203
|
scale_mappings:
|
|
217
204
|
small: # 1-2 files
|
|
218
205
|
load_immediately:
|
|
219
|
-
- "
|
|
206
|
+
- "coding-rules"
|
|
220
207
|
load_on_demand: []
|
|
221
208
|
|
|
222
209
|
medium: # 3-5 files
|
|
223
210
|
load_immediately:
|
|
224
|
-
- "
|
|
225
|
-
- "
|
|
226
|
-
- "
|
|
227
|
-
- "
|
|
211
|
+
- "coding-rules"
|
|
212
|
+
- "testing" # TDD is mandatory
|
|
213
|
+
- "documentation-criteria"
|
|
214
|
+
- "implementation-approach" # Required for approach selection
|
|
228
215
|
load_on_demand:
|
|
229
|
-
- "
|
|
216
|
+
- "ai-development-guide"
|
|
230
217
|
|
|
231
218
|
large: # 6+ files
|
|
232
219
|
load_immediately:
|
|
233
|
-
- "
|
|
234
|
-
- "
|
|
220
|
+
- "documentation-criteria"
|
|
221
|
+
- "implementation-approach"
|
|
235
222
|
load_on_demand:
|
|
236
|
-
- "
|
|
237
|
-
- "
|
|
238
|
-
- "
|
|
223
|
+
- "coding-rules"
|
|
224
|
+
- "testing"
|
|
225
|
+
- "ai-development-guide"
|
|
239
226
|
|
|
240
|
-
# Metadata for
|
|
227
|
+
# Metadata for skill selection algorithm
|
|
241
228
|
selection_rules:
|
|
242
|
-
- "Always load
|
|
243
|
-
- "Load
|
|
244
|
-
- "Load
|
|
229
|
+
- "Always load metacognition at session start"
|
|
230
|
+
- "Load coding-rules when any code modification is involved"
|
|
231
|
+
- "Load testing for ALL implementation tasks (TDD mandatory)"
|
|
245
232
|
- "Load implementation-approach for Medium/Large scale (3+ files)"
|
|
246
233
|
- "Execute ALL quality check commands in VERIFY phase with 0 errors"
|
|
247
234
|
- "Progressive loading: start with minimum, add as needed"
|
|
248
|
-
- "Unload task-specific
|
|
235
|
+
- "Unload task-specific skills after task completion"
|
|
236
|
+
- "For TypeScript projects, also read references/typescript.md in coding-rules and testing skills"
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ai-development-guide
|
|
3
|
+
description: |
|
|
4
|
+
Technical anti-pattern detection, fail-fast design principles, debugging techniques, and implementation completeness guidelines.
|
|
5
|
+
Use when: implementing features, reviewing code quality, debugging errors, refactoring code, or detecting code smells.
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# AI Developer Guide
|
|
2
9
|
|
|
3
10
|
## Technical Anti-patterns (Red Flag Patterns)
|
|
@@ -253,7 +260,7 @@ Complete these stages sequentially before any implementation:
|
|
|
253
260
|
|
|
254
261
|
**Critical**: Do not implement until all 3 stages are documented
|
|
255
262
|
|
|
256
|
-
**Relationship to Pattern 5**: This process provides the structured methodology to avoid "Insufficient Existing Code Investigation"
|
|
263
|
+
**Relationship to Pattern 5**: This process provides the structured methodology to avoid "Insufficient Existing Code Investigation"
|
|
257
264
|
|
|
258
265
|
### Unused Code Deletion
|
|
259
266
|
|
|
@@ -269,4 +276,4 @@ In use? No → Delete
|
|
|
269
276
|
Yes → Fix/Extend
|
|
270
277
|
```
|
|
271
278
|
|
|
272
|
-
**Principle**: Prefer clean implementation over patching broken code
|
|
279
|
+
**Principle**: Prefer clean implementation over patching broken code
|
|
@@ -1,4 +1,16 @@
|
|
|
1
|
-
|
|
1
|
+
---
|
|
2
|
+
name: coding-rules
|
|
3
|
+
description: |
|
|
4
|
+
Coding principles for maintainability, readability, and quality.
|
|
5
|
+
Use when: implementing features, refactoring code, reviewing code quality, or establishing coding standards.
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Development Rules
|
|
9
|
+
|
|
10
|
+
## Language-Specific References
|
|
11
|
+
|
|
12
|
+
For language-specific rules, also read:
|
|
13
|
+
- **TypeScript**: [references/typescript.md](references/typescript.md)
|
|
2
14
|
|
|
3
15
|
## Basic Principles
|
|
4
16
|
|
|
@@ -114,4 +126,4 @@ Never include sensitive information in logs:
|
|
|
114
126
|
- Write small, focused modules/functions
|
|
115
127
|
- Minimize dependencies between modules
|
|
116
128
|
- Use clear interfaces between components
|
|
117
|
-
- Follow single responsibility principle
|
|
129
|
+
- Follow single responsibility principle
|
package/.agents/{rules/language/typescript/rules.md → skills/coding-rules/references/typescript.md}
RENAMED
|
@@ -1,15 +1,4 @@
|
|
|
1
|
-
# TypeScript
|
|
2
|
-
|
|
3
|
-
## Basic Principles
|
|
4
|
-
|
|
5
|
-
✅ **Aggressive Refactoring**
|
|
6
|
-
❌ **Unused "Just in Case" Code** - YAGNI principle
|
|
7
|
-
|
|
8
|
-
## Comment Writing Rules
|
|
9
|
-
- **Function Description Focus**: Describe what the code "does"
|
|
10
|
-
- **No Historical Information**: Do not record development history
|
|
11
|
-
- **Timeless**: Write only content that remains valid whenever read
|
|
12
|
-
- **Conciseness**: Keep explanations to necessary minimum
|
|
1
|
+
# TypeScript-Specific Rules
|
|
13
2
|
|
|
14
3
|
## Type Safety
|
|
15
4
|
|
|
@@ -25,7 +14,7 @@
|
|
|
25
14
|
```typescript
|
|
26
15
|
// Safely validate external input
|
|
27
16
|
function isUser(value: unknown): value is User {
|
|
28
|
-
return typeof value === 'object' && value !== null &&
|
|
17
|
+
return typeof value === 'object' && value !== null &&
|
|
29
18
|
'id' in value && 'name' in value
|
|
30
19
|
}
|
|
31
20
|
// Usage: if (isUser(data)) { /* data is typed as User */ }
|
|
@@ -75,7 +64,7 @@ Input Layer (`unknown`) → Type Guard → Business Layer (Type Guaranteed) →
|
|
|
75
64
|
**Class Usage Criteria**
|
|
76
65
|
- **Recommended: Implementation with Functions and Interfaces**
|
|
77
66
|
- Rationale: Improves testability and flexibility of function composition
|
|
78
|
-
- **Classes Allowed**:
|
|
67
|
+
- **Classes Allowed**:
|
|
79
68
|
- Framework requirements (NestJS Controller/Service, TypeORM Entity, etc.)
|
|
80
69
|
- Custom error class definitions
|
|
81
70
|
- When state and business logic are tightly coupled (e.g., ShoppingCart, Session, StateMachine)
|
|
@@ -89,22 +78,20 @@ Input Layer (`unknown`) → Type Guard → Business Layer (Type Guaranteed) →
|
|
|
89
78
|
```
|
|
90
79
|
|
|
91
80
|
**Function Design**
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
```
|
|
81
|
+
```typescript
|
|
82
|
+
// ✅ Object parameter
|
|
83
|
+
function createUser({ name, email, role }: CreateUserParams) {}
|
|
84
|
+
// ❌ Multiple parameters
|
|
85
|
+
function createUser(name: string, email: string, role: string) {}
|
|
86
|
+
```
|
|
99
87
|
|
|
100
88
|
**Dependency Injection**
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
```
|
|
89
|
+
```typescript
|
|
90
|
+
// ✅ Receive dependency as parameter
|
|
91
|
+
function createService(repository: Repository) { return {...} }
|
|
92
|
+
// ❌ Direct import dependency
|
|
93
|
+
import { userRepository } from './infrastructure/repository'
|
|
94
|
+
```
|
|
108
95
|
|
|
109
96
|
**Asynchronous Processing**
|
|
110
97
|
- Promise Handling: Always use `async/await`
|
|
@@ -116,16 +103,8 @@ Input Layer (`unknown`) → Type Guard → Business Layer (Type Guaranteed) →
|
|
|
116
103
|
- Types in `PascalCase`, variables/functions in `camelCase`
|
|
117
104
|
- Imports use absolute paths (`src/`)
|
|
118
105
|
|
|
119
|
-
**Clean Code Principles**
|
|
120
|
-
- ✅ Delete unused code immediately
|
|
121
|
-
- ✅ Delete debug `console.log()`
|
|
122
|
-
- ❌ Commented-out code (manage history with version control)
|
|
123
|
-
- ✅ Comments explain "why" (not "what")
|
|
124
|
-
|
|
125
106
|
## Error Handling
|
|
126
107
|
|
|
127
|
-
**Absolute Rule**: Error suppression prohibited. All errors must have log output and appropriate handling.
|
|
128
|
-
|
|
129
108
|
**Result Type Pattern**: Express errors with types for explicit handling
|
|
130
109
|
```typescript
|
|
131
110
|
type Result<T, E> = { ok: true; value: T } | { ok: false; error: E }
|
|
@@ -148,31 +127,16 @@ export class AppError extends Error {
|
|
|
148
127
|
// Purpose-specific: ValidationError(400), BusinessRuleError(400), DatabaseError(500), ExternalServiceError(502)
|
|
149
128
|
```
|
|
150
129
|
|
|
151
|
-
**Layer-Specific Error Handling**
|
|
152
|
-
- API Layer: Convert to HTTP response, log output excluding sensitive information
|
|
153
|
-
- Service Layer: Detect business rule violations, propagate AppError as-is
|
|
154
|
-
- Repository Layer: Convert technical errors to domain errors
|
|
155
|
-
|
|
156
|
-
**Structured Logging and Sensitive Information Protection**
|
|
157
|
-
Never include sensitive information (password, token, apiKey, secret, creditCard) in logs
|
|
158
|
-
|
|
159
130
|
**Asynchronous Error Handling**
|
|
160
131
|
- Global handler setup mandatory: `unhandledRejection`, `uncaughtException`
|
|
161
132
|
- Use try-catch with all async/await
|
|
162
133
|
- Always log and re-throw errors
|
|
163
134
|
|
|
164
|
-
## Refactoring
|
|
165
|
-
|
|
166
|
-
**Basic Policy**
|
|
167
|
-
- Small Steps: Maintain always-working state through gradual improvements
|
|
168
|
-
- Safe Changes: Minimize the scope of changes at once
|
|
169
|
-
- Behavior Guarantee: Ensure existing behavior remains unchanged while proceeding
|
|
170
|
-
|
|
171
|
-
**Implementation Procedure**: Understand Current State → Gradual Changes → Behavior Verification → Final Validation
|
|
135
|
+
## Refactoring Priority
|
|
172
136
|
|
|
173
|
-
|
|
137
|
+
Duplicate Code Removal > Large Function Division > Complex Conditional Branch Simplification > **Type Safety Improvement**
|
|
174
138
|
|
|
175
139
|
## Performance Optimization
|
|
176
140
|
|
|
177
141
|
- Streaming Processing: Process large datasets with streams
|
|
178
|
-
- Memory Leak Prevention: Explicitly release unnecessary objects
|
|
142
|
+
- Memory Leak Prevention: Explicitly release unnecessary objects
|
package/.agents/{rules/core/documentation-criteria.md → skills/documentation-criteria/SKILL.md}
RENAMED
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: documentation-criteria
|
|
3
|
+
description: |
|
|
4
|
+
Documentation creation criteria including PRD, ADR, Design Doc, and Work Plan requirements with templates.
|
|
5
|
+
Use when: creating technical documents, determining which documents are required, reviewing document quality, or planning feature implementation.
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Documentation Creation Criteria
|
|
2
9
|
|
|
3
10
|
## Creation Decision Matrix
|
|
@@ -181,4 +188,4 @@ Required diagrams for each document (using mermaid notation):
|
|
|
181
188
|
1. **At creation**: Identify common technical areas (logging, error handling, async processing, etc.), reference existing common ADRs
|
|
182
189
|
2. **When missing**: Consider creating necessary common ADRs
|
|
183
190
|
3. **Design Doc**: Specify common ADRs in "Prerequisite ADRs" section
|
|
184
|
-
4. **Compliance check**: Verify design aligns with common ADR decisions
|
|
191
|
+
4. **Compliance check**: Verify design aligns with common ADR decisions
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: implementation-approach
|
|
3
|
+
description: |
|
|
4
|
+
Implementation strategy selection framework with meta-cognitive approach, verification levels, and integration point definitions.
|
|
5
|
+
Use when: planning implementation strategy, selecting development approach (vertical/horizontal/hybrid), or defining verification criteria.
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Implementation Strategy Selection Framework (Meta-cognitive Approach)
|
|
2
9
|
|
|
3
10
|
An implementation strategy selection framework based on meta-cognitive thinking. Derives optimal implementation approaches through a systematic decision process from understanding existing implementations to constraint compatibility.
|
|
@@ -199,4 +206,4 @@ Define integration points according to selected strategy:
|
|
|
199
206
|
3. **Apply 5 Whys**: Pursue root causes to grasp essence
|
|
200
207
|
4. **Multi-perspective Evaluation**: Comprehensively evaluate from each Step 1-4 perspective
|
|
201
208
|
5. **Creative Thinking**: Consider sequential application of multiple strategies and designs leveraging project-specific constraints
|
|
202
|
-
6. **Clarify Decision Rationale**: Make strategy selection rationale explicit in design documents
|
|
209
|
+
6. **Clarify Decision Rationale**: Make strategy selection rationale explicit in design documents
|
package/.agents/{rules/core/integration-e2e-testing.md → skills/integration-e2e-testing/SKILL.md}
RENAMED
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: integration-e2e-testing
|
|
3
|
+
description: |
|
|
4
|
+
Integration and E2E test design principles, behavior verification rules, mock boundaries, and review criteria.
|
|
5
|
+
Use when: designing integration tests, E2E tests, writing test skeletons, or reviewing test implementation quality.
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Integration Test & E2E Test Design/Implementation Rules
|
|
2
9
|
|
|
3
10
|
## Test Types and Limits
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: metacognition
|
|
3
|
+
description: |
|
|
4
|
+
Self-assessment checkpoints and protocol for AI agents.
|
|
5
|
+
Use when: task type changes, after completing tasks, encountering errors, before starting new features, or switching between phases.
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Metacognition Protocol
|
|
2
9
|
|
|
3
10
|
## Purpose
|
|
@@ -8,7 +15,7 @@ Self-assessment checkpoints.
|
|
|
8
15
|
|
|
9
16
|
**BLOCKING METACOGNITION REQUIRED at:**
|
|
10
17
|
- [CHECKPOINT] Task type changes → CANNOT proceed without assessment
|
|
11
|
-
- [CHECKPOINT] After completing ANY task from
|
|
18
|
+
- [CHECKPOINT] After completing ANY task from Work Plan document → MUST evaluate before next task
|
|
12
19
|
- [CHECKPOINT] When encountering error or unexpected result → ASSESS approach immediately
|
|
13
20
|
- [CHECKPOINT] Before writing first line of new feature → VALIDATE approach first
|
|
14
21
|
- [CHECKPOINT] When switching between major phases → CONFIRM all gates passed
|
|
@@ -71,7 +78,7 @@ Note: Context management is user's responsibility. Ask for guidance if unsure.
|
|
|
71
78
|
**GATE: CANNOT start coding if ANY unchecked**
|
|
72
79
|
|
|
73
80
|
### During Execution [PROGRESS GATES]
|
|
74
|
-
☐ [VERIFY] Following
|
|
81
|
+
☐ [VERIFY] Following Work Plan from `docs/plans/`
|
|
75
82
|
☐ [VERIFY] Making measurable progress (list completed items)
|
|
76
83
|
☐ [EVALUATE] Additional rules needed? (load IMMEDIATELY if yes)
|
|
77
84
|
☐ [EVALUATE] Blocked for >10 minutes? (MUST ask for help)
|
|
@@ -150,4 +157,4 @@ Remember:
|
|
|
150
157
|
- Regular reflection improves quality
|
|
151
158
|
- It's okay to pause and think
|
|
152
159
|
- Ask for help when genuinely stuck
|
|
153
|
-
- Perfect is the enemy of good
|
|
160
|
+
- Perfect is the enemy of good
|
|
@@ -1,4 +1,16 @@
|
|
|
1
|
-
|
|
1
|
+
---
|
|
2
|
+
name: testing
|
|
3
|
+
description: |
|
|
4
|
+
Testing principles including TDD process, test quality criteria, coverage standards, and mock usage guidelines.
|
|
5
|
+
Use when: writing tests, designing test strategies, reviewing test quality, or establishing testing standards.
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Testing Rules
|
|
9
|
+
|
|
10
|
+
## Language-Specific References
|
|
11
|
+
|
|
12
|
+
For language-specific rules, also read:
|
|
13
|
+
- **TypeScript/Vitest**: [references/typescript.md](references/typescript.md)
|
|
2
14
|
|
|
3
15
|
## TDD Process [MANDATORY for all code changes]
|
|
4
16
|
|
|
@@ -29,6 +41,8 @@
|
|
|
29
41
|
- Pure configuration files
|
|
30
42
|
- Documentation only
|
|
31
43
|
- Emergency fixes (but add tests immediately after)
|
|
44
|
+
- Exploratory spikes (discard or rewrite with tests before merging)
|
|
45
|
+
- Build/deployment scripts (unless they contain business logic)
|
|
32
46
|
|
|
33
47
|
## Basic Testing Policy
|
|
34
48
|
|
|
@@ -83,26 +97,6 @@
|
|
|
83
97
|
- Unit test coverage sufficient
|
|
84
98
|
- Smoke tests for integration points
|
|
85
99
|
|
|
86
|
-
**Verification Pattern**:
|
|
87
|
-
1. **Establish Baseline**
|
|
88
|
-
- Test and document existing feature behavior
|
|
89
|
-
- Capture performance metrics
|
|
90
|
-
- Record expected outputs
|
|
91
|
-
|
|
92
|
-
2. **Apply Changes**
|
|
93
|
-
- Deploy or enable new feature
|
|
94
|
-
- Maintain feature flags for rollback capability
|
|
95
|
-
|
|
96
|
-
3. **Verify Existing Features**
|
|
97
|
-
- Confirm existing features still function correctly
|
|
98
|
-
- Compare against baseline metrics
|
|
99
|
-
- Validate no unexpected side effects
|
|
100
|
-
|
|
101
|
-
4. **Measure Performance** (NOT long-term stability tests)
|
|
102
|
-
- Response times within acceptable limits (project-specific)
|
|
103
|
-
- Resource usage remains stable
|
|
104
|
-
- No memory leaks or degradation
|
|
105
|
-
|
|
106
100
|
**Success Criteria**:
|
|
107
101
|
- Zero breaking changes in existing workflows
|
|
108
102
|
- Performance degradation within project-defined acceptable limits
|
|
@@ -110,10 +104,6 @@
|
|
|
110
104
|
- All integration points maintain expected contracts
|
|
111
105
|
- Backward compatibility preserved where required
|
|
112
106
|
|
|
113
|
-
**Documentation Requirements**:
|
|
114
|
-
- Map all integration points in Design Doc
|
|
115
|
-
- Document test coverage for each impact level
|
|
116
|
-
|
|
117
107
|
## Test Design Principles
|
|
118
108
|
|
|
119
109
|
### Test Case Structure
|
|
@@ -205,6 +195,7 @@
|
|
|
205
195
|
|
|
206
196
|
1. **Boundary coverage**: Include empty/zero/max/error cases with happy paths
|
|
207
197
|
2. **Literal expectations**: Use literal values in assertions, not computed expressions
|
|
198
|
+
- Expected value ≠ mock return value (implementation processes data)
|
|
208
199
|
3. **Result verification**: Assert return values and state, not call order
|
|
209
200
|
4. **Meaningful assertions**: Every test must have at least one assertion
|
|
210
201
|
5. **Mock external I/O only**: Mock DB/API/filesystem, use real internal utilities
|
|
@@ -245,13 +236,7 @@ Your project MUST have mechanisms to verify:
|
|
|
245
236
|
- Type checking passes
|
|
246
237
|
- No type errors or warnings
|
|
247
238
|
|
|
248
|
-
### Implementation Guidelines
|
|
249
|
-
- **Identify Your Tools**: Use your project's existing quality tools (test runners, linters, formatters, type checkers)
|
|
250
|
-
- **Zero Error Policy**: ALL quality checks must pass with 0 errors before task completion
|
|
251
|
-
- **Document Execution**: Note which quality checks were run and their results
|
|
252
|
-
- **Project-Specific**: Adapt to your specific language, framework, and tooling setup
|
|
253
|
-
|
|
254
239
|
### ENFORCEMENT
|
|
255
240
|
- Cannot proceed with task completion if ANY quality check fails
|
|
256
241
|
- Must fix all errors and warnings before marking task complete
|
|
257
|
-
- If your project lacks certain quality tools, establish them or document the gap
|
|
242
|
+
- If your project lacks certain quality tools, establish them or document the gap
|