@kienha/anti-chaotic 1.0.2 → 1.0.6
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/.agent/rules/{documentation.md → documents.md} +1 -1
- package/.agent/skills/backend-developer/SKILL.md +4 -14
- package/.agent/skills/business-analysis/SKILL.md +2 -4
- package/.agent/skills/designer/SKILL.md +36 -58
- package/.agent/skills/devops-engineer/SKILL.md +0 -9
- package/.agent/skills/frontend-developer/SKILL.md +17 -3
- package/.agent/skills/frontend-developer/react/SKILL.md +16 -12
- package/.agent/skills/lead-architect/SKILL.md +2 -2
- package/.agent/skills/rules-workflows/SKILL.md +22 -112
- package/.agent/skills/rules-workflows/assets/workflow-basic.md +112 -0
- package/.agent/skills/rules-workflows/references/orchestration-patterns.md +13 -3
- package/.agent/skills/rules-workflows/references/rules-guide.md +82 -65
- package/.agent/skills/rules-workflows/references/workflows-guide.md +95 -26
- package/.agent/skills/skill-creator/SKILL.md +18 -20
- package/.agent/skills/skill-creator/assets/skill-questionnaire.md +8 -0
- package/.agent/workflows/bootstrap.md +96 -0
- package/.agent/workflows/brainstorm.md +81 -0
- package/.agent/workflows/custom-behavior.md +64 -0
- package/.agent/workflows/documentation.md +123 -0
- package/.agent/workflows/implement-feature.md +146 -0
- package/.agent/workflows/ui-ux-design.md +70 -51
- package/README.md +55 -354
- package/bin/{ag.js → anti-chaotic.js} +17 -0
- package/package.json +5 -4
- package/.agent/skills/frontend-developer/references/react-next.md +0 -67
- package/.agent/skills/frontend-developer/references/react.md +0 -91
- package/.agent/skills/rules-workflows/assets/example-workflow.md +0 -37
- package/.agent/skills/rules-workflows/assets/templates/rule-project-context.md +0 -26
- package/.agent/skills/rules-workflows/assets/templates/workflow-agile-feature.md +0 -62
- package/.agent/skills/skill-creator/scripts/__pycache__/encoding_utils.cpython-312.pyc +0 -0
- package/.agent/skills/skill-creator/scripts/__pycache__/quick_validate.cpython-312.pyc +0 -0
- package/.agent/workflows/generate-docs-from-codebase.md +0 -335
- package/.agent/workflows/requirement-analysis.md +0 -336
- package/.agent/workflows/setup-codebase.md +0 -97
- package/.agent/workflows/workflow-rule-from-codebase.md +0 -43
- package/.agent/workflows/workflow-rule-from-feedback.md +0 -38
- /package/.agent/skills/rules-workflows/assets/{example-rule-always-on.md → rule-always-on.md} +0 -0
- /package/.agent/skills/rules-workflows/assets/{example-rule-glob.md → rule-glob.md} +0 -0
- /package/.agent/skills/rules-workflows/assets/{example-rule-manual.md → rule-manual.md} +0 -0
- /package/.agent/skills/rules-workflows/assets/{example-rule-model-decision.md → rule-model-decision.md} +0 -0
|
@@ -1,336 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Requirement Analysis Workflow (PM -> BA -> Architect)
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Requirement Analysis Workflow
|
|
6
|
-
|
|
7
|
-
This workflow orchestrates the **Product Manager**, **Business Analyst**, and **Lead Architect** skills to transform a raw user request into a comprehensive, validated implementation plan.
|
|
8
|
-
|
|
9
|
-
> [!IMPORTANT]
|
|
10
|
-
> **MANDATORY**: Before creating any document, read and apply `.agent/rules/documentation.md`.
|
|
11
|
-
|
|
12
|
-
---
|
|
13
|
-
|
|
14
|
-
## Artifact Usage Guidelines
|
|
15
|
-
|
|
16
|
-
> [!TIP]
|
|
17
|
-
> **Use artifacts proactively** for user review and commenting:
|
|
18
|
-
>
|
|
19
|
-
> - **Clarification questions** → Create artifact so user can review/comment before answering
|
|
20
|
-
> - **Document drafts** → Create artifact first for user review, then save to `docs/` after approval
|
|
21
|
-
> - **Tables and checklists** → Use artifacts for easy inline commenting
|
|
22
|
-
> - **Tooling** → You MUST use the `write_to_file` tool to create these artifacts.
|
|
23
|
-
|
|
24
|
-
---
|
|
25
|
-
|
|
26
|
-
## Document Priority Order
|
|
27
|
-
|
|
28
|
-
Documents are created from **high-level overview** to **detailed specifics**:
|
|
29
|
-
|
|
30
|
-
```
|
|
31
|
-
Priority 0: Roadmap ← Project Planning & Timeline
|
|
32
|
-
Priority 1: PRD (Product Requirements Document) ← Strategic Overview
|
|
33
|
-
Priority 2: SDD (System Design Document) ← Technical Overview
|
|
34
|
-
Priority 3: Epics ← Feature Breakdown
|
|
35
|
-
Priority 4: Use Cases ← Functional Details
|
|
36
|
-
Priority 5: User Stories ← Implementation Units
|
|
37
|
-
Priority 6: ADRs (if needed) ← Technical Decisions
|
|
38
|
-
```
|
|
39
|
-
|
|
40
|
-
---
|
|
41
|
-
|
|
42
|
-
## Step 0: Clarification & Understanding
|
|
43
|
-
|
|
44
|
-
**Role: Product Manager**
|
|
45
|
-
|
|
46
|
-
> [!NOTE]
|
|
47
|
-
> This step is **MANDATORY**. Do NOT proceed without user confirmation.
|
|
48
|
-
|
|
49
|
-
1. **Summarize Understanding**: Paraphrase the user's request in your own words.
|
|
50
|
-
2. **Create Clarification Artifact**: Present questions in an artifact for easy review:
|
|
51
|
-
|
|
52
|
-
**→ Execute `write_to_file` to create artifact: `clarification-questions.md`**
|
|
53
|
-
|
|
54
|
-
```markdown
|
|
55
|
-
# Project Clarification Questions
|
|
56
|
-
|
|
57
|
-
## Understanding Summary
|
|
58
|
-
|
|
59
|
-
- **Project**: {ProjectName}
|
|
60
|
-
- **Goal**: {one-line summary}
|
|
61
|
-
- **Target Users**: {who}
|
|
62
|
-
|
|
63
|
-
## Key Features Identified
|
|
64
|
-
|
|
65
|
-
- [ ] {feature1}
|
|
66
|
-
- [ ] {feature2}
|
|
67
|
-
- [ ] {feature3}
|
|
68
|
-
|
|
69
|
-
## Questions for Clarification
|
|
70
|
-
|
|
71
|
-
| # | Question | Your Answer |
|
|
72
|
-
| --- | --------------------------------------------------- | ----------- |
|
|
73
|
-
| 1 | What is the primary problem you're trying to solve? | |
|
|
74
|
-
| 2 | Who is the target user/audience? | |
|
|
75
|
-
| 3 | What does success look like? | |
|
|
76
|
-
| 4 | Any constraints (time, budget, tech stack)? | |
|
|
77
|
-
| 5 | Any existing systems to integrate with? | |
|
|
78
|
-
|
|
79
|
-
## Confirmation
|
|
80
|
-
|
|
81
|
-
- [ ] Understanding is correct
|
|
82
|
-
- [ ] Ready to proceed
|
|
83
|
-
```
|
|
84
|
-
|
|
85
|
-
3. **WAIT** for user to review artifact and confirm.
|
|
86
|
-
|
|
87
|
-
---
|
|
88
|
-
|
|
89
|
-
## Step 1: Create Roadmap (Project Planning)
|
|
90
|
-
|
|
91
|
-
**Role: Product Manager**
|
|
92
|
-
// turbo
|
|
93
|
-
|
|
94
|
-
> After completing, **ASK user** before proceeding to Step 2.
|
|
95
|
-
|
|
96
|
-
1. **Draft Roadmap**: Define "When" and project phases
|
|
97
|
-
- Project timeline and milestones
|
|
98
|
-
- Phase breakdown (MVP, v1.0, v2.0, etc.)
|
|
99
|
-
- Key deliverables per phase
|
|
100
|
-
- Dependencies and risks
|
|
101
|
-
2. **Create Draft Artifact**:
|
|
102
|
-
- **→ Execute `write_to_file` to create artifact: `draft-roadmap.md`** for user review
|
|
103
|
-
3. **After User Approval**:
|
|
104
|
-
- **Save to**: `docs/010-Planning/Roadmap-{ProjectName}.md`
|
|
105
|
-
4. **Present to User**:
|
|
106
|
-
|
|
107
|
-
```
|
|
108
|
-
✅ ROADMAP CREATED
|
|
109
|
-
──────────────────
|
|
110
|
-
📝 Draft: artifact `draft-roadmap.md` (review & comment)
|
|
111
|
-
📄 Final: docs/010-Planning/Roadmap-{ProjectName}.md
|
|
112
|
-
|
|
113
|
-
👉 Review the draft. When ready:
|
|
114
|
-
[Approve & Continue / Request Changes / Stop Here]
|
|
115
|
-
```
|
|
116
|
-
|
|
117
|
-
5. **WAIT** for user response.
|
|
118
|
-
|
|
119
|
-
---
|
|
120
|
-
|
|
121
|
-
## Step 2: Create PRD (Strategic Overview)
|
|
122
|
-
|
|
123
|
-
**Role: Product Manager**
|
|
124
|
-
// turbo
|
|
125
|
-
|
|
126
|
-
> After completing, **ASK user** before proceeding to Step 3.
|
|
127
|
-
|
|
128
|
-
1. **Draft PRD**: Define the "Why" and "What"
|
|
129
|
-
- Business objectives and success metrics
|
|
130
|
-
- Target audience/user personas
|
|
131
|
-
- Feature prioritization (MoSCoW)
|
|
132
|
-
2. **Create Draft Artifact**:
|
|
133
|
-
- **→ Execute `write_to_file` to create artifact: `draft-prd.md`** for user review
|
|
134
|
-
3. **After User Approval**:
|
|
135
|
-
- **Save to**: `docs/020-Requirements/PRD-{ProjectName}.md`
|
|
136
|
-
4. **Present to User**:
|
|
137
|
-
|
|
138
|
-
```
|
|
139
|
-
✅ PRD DRAFTED
|
|
140
|
-
──────────────
|
|
141
|
-
📝 Draft: artifact `draft-prd.md` (review & comment)
|
|
142
|
-
📄 Final: docs/020-Requirements/PRD-{ProjectName}.md
|
|
143
|
-
|
|
144
|
-
👉 Review the draft. When ready:
|
|
145
|
-
[Approve & Continue / Request Changes / Stop Here]
|
|
146
|
-
```
|
|
147
|
-
|
|
148
|
-
5. **WAIT** for user response.
|
|
149
|
-
|
|
150
|
-
---
|
|
151
|
-
|
|
152
|
-
## Step 3: Create SDD (Technical Overview)
|
|
153
|
-
|
|
154
|
-
**Role: Lead Architect**
|
|
155
|
-
// turbo
|
|
156
|
-
|
|
157
|
-
> After completing, **ASK user** before proceeding to Step 4.
|
|
158
|
-
|
|
159
|
-
1. **Draft SDD**: Define the "Technical How"
|
|
160
|
-
- High-level system architecture
|
|
161
|
-
- Technology stack decisions
|
|
162
|
-
- Component diagram
|
|
163
|
-
- Data flow overview
|
|
164
|
-
2. **Create Draft Artifact**:
|
|
165
|
-
- **→ Execute `write_to_file` to create artifact: `draft-sdd.md`** for user review
|
|
166
|
-
3. **After User Approval**:
|
|
167
|
-
- **Save to**: `docs/030-Specs/Architecture/SDD-{ProjectName}.md`
|
|
168
|
-
4. **Present to User**:
|
|
169
|
-
|
|
170
|
-
```
|
|
171
|
-
✅ SDD DRAFTED
|
|
172
|
-
──────────────
|
|
173
|
-
📝 Draft: artifact `draft-sdd.md` (review & comment)
|
|
174
|
-
📄 Final: docs/030-Specs/Architecture/SDD-{ProjectName}.md
|
|
175
|
-
|
|
176
|
-
👉 Review the draft. When ready:
|
|
177
|
-
[Approve & Continue / Request Changes / Stop Here]
|
|
178
|
-
```
|
|
179
|
-
|
|
180
|
-
5. **WAIT** for user response.
|
|
181
|
-
|
|
182
|
-
---
|
|
183
|
-
|
|
184
|
-
## Step 4: Create Epics (Feature Breakdown)
|
|
185
|
-
|
|
186
|
-
**Role: Business Analyst**
|
|
187
|
-
// turbo
|
|
188
|
-
|
|
189
|
-
> After completing, **ASK user** before proceeding to Step 5.
|
|
190
|
-
|
|
191
|
-
1. **Draft Epics**: Break PRD features into Epics
|
|
192
|
-
- One Epic per major feature/module
|
|
193
|
-
- Include high-level acceptance criteria
|
|
194
|
-
2. **Create Draft Artifacts**:
|
|
195
|
-
- **→ Execute `write_to_file` to create artifact: `draft-epics.md`** containing all Epics for user review
|
|
196
|
-
3. **After User Approval**:
|
|
197
|
-
- **Save to**: `docs/022-User-Stories/Epics/Epic-{FeatureName}.md` (one file per Epic)
|
|
198
|
-
4. **Present to User**:
|
|
199
|
-
|
|
200
|
-
```
|
|
201
|
-
✅ EPICS DRAFTED
|
|
202
|
-
────────────────
|
|
203
|
-
📝 Draft: artifact `draft-epics.md` (review & comment)
|
|
204
|
-
📄 Final: {N} files in docs/022-User-Stories/Epics/
|
|
205
|
-
|
|
206
|
-
👉 Review the draft. When ready:
|
|
207
|
-
[Approve & Continue / Request Changes / Stop Here]
|
|
208
|
-
```
|
|
209
|
-
|
|
210
|
-
5. **WAIT** for user response.
|
|
211
|
-
|
|
212
|
-
---
|
|
213
|
-
|
|
214
|
-
## Step 5: Create Use Cases (Functional Details)
|
|
215
|
-
|
|
216
|
-
**Role: Business Analyst**
|
|
217
|
-
// turbo
|
|
218
|
-
|
|
219
|
-
> After completing, **ASK user** before proceeding to Step 6.
|
|
220
|
-
|
|
221
|
-
1. **Draft Use Cases**: Detail each Epic's functionality
|
|
222
|
-
- Happy path flow
|
|
223
|
-
- Alternative flows
|
|
224
|
-
- Edge cases and error handling
|
|
225
|
-
- Include Mermaid diagrams where helpful
|
|
226
|
-
2. **Create Draft Artifacts**:
|
|
227
|
-
- **→ Execute `write_to_file` to create artifact: `draft-use-cases.md`** for user review
|
|
228
|
-
3. **After User Approval**:
|
|
229
|
-
- **Save to**: `docs/020-Requirements/Use-Cases/UC-{NN}-{Name}.md`
|
|
230
|
-
4. **Present to User**:
|
|
231
|
-
|
|
232
|
-
```
|
|
233
|
-
✅ USE CASES DRAFTED
|
|
234
|
-
────────────────────
|
|
235
|
-
📝 Draft: artifact `draft-use-cases.md` (review & comment)
|
|
236
|
-
📄 Final: {N} files in docs/020-Requirements/Use-Cases/
|
|
237
|
-
|
|
238
|
-
👉 Review the draft. When ready:
|
|
239
|
-
[Approve & Continue / Request Changes / Stop Here]
|
|
240
|
-
```
|
|
241
|
-
|
|
242
|
-
5. **WAIT** for user response.
|
|
243
|
-
|
|
244
|
-
---
|
|
245
|
-
|
|
246
|
-
## Step 6: Create User Stories (Implementation Units)
|
|
247
|
-
|
|
248
|
-
**Role: Business Analyst**
|
|
249
|
-
// turbo
|
|
250
|
-
|
|
251
|
-
> After completing, **ASK user** if ADRs are needed.
|
|
252
|
-
|
|
253
|
-
1. **Draft User Stories**: Break Use Cases into dev-ready stories
|
|
254
|
-
- Follow format: "As a [role], I want [action], so that [value]"
|
|
255
|
-
- Include clear Acceptance Criteria
|
|
256
|
-
- Estimate complexity (S/M/L)
|
|
257
|
-
2. **Create Draft Artifacts**:
|
|
258
|
-
- **→ Execute `write_to_file` to create artifact: `draft-user-stories.md`** for user review
|
|
259
|
-
3. **After User Approval**:
|
|
260
|
-
- **Save to**: `docs/022-User-Stories/Backlog/Story-{Name}.md`
|
|
261
|
-
4. **Present to User**:
|
|
262
|
-
|
|
263
|
-
```
|
|
264
|
-
✅ USER STORIES DRAFTED
|
|
265
|
-
───────────────────────
|
|
266
|
-
📝 Draft: artifact `draft-user-stories.md` (review & comment)
|
|
267
|
-
📄 Final: {N} files in docs/022-User-Stories/Backlog/
|
|
268
|
-
|
|
269
|
-
👉 Review the draft. When ready:
|
|
270
|
-
[Approve & Continue / Request Changes / Stop Here]
|
|
271
|
-
|
|
272
|
-
💡 Any technical decisions that need ADRs?
|
|
273
|
-
(e.g., database choice, auth strategy, API design)
|
|
274
|
-
```
|
|
275
|
-
|
|
276
|
-
5. **WAIT** for user response.
|
|
277
|
-
|
|
278
|
-
---
|
|
279
|
-
|
|
280
|
-
## Step 7: Create ADRs (Technical Decisions) - Optional
|
|
281
|
-
|
|
282
|
-
**Role: Lead Architect**
|
|
283
|
-
// turbo
|
|
284
|
-
|
|
285
|
-
> Only if user requested ADRs in Step 6.
|
|
286
|
-
|
|
287
|
-
1. **Identify Decisions**: List technical decisions that need documentation
|
|
288
|
-
2. **Create ADRs**: For each decision:
|
|
289
|
-
- Context
|
|
290
|
-
- Options considered
|
|
291
|
-
- Decision made
|
|
292
|
-
- Consequences
|
|
293
|
-
3. **Output**:
|
|
294
|
-
- **Files**: `docs/030-Specs/Architecture/ADR-{NNN}-{Decision}.md`
|
|
295
|
-
|
|
296
|
-
---
|
|
297
|
-
|
|
298
|
-
## Step 8: Finalize & Summary
|
|
299
|
-
|
|
300
|
-
**Role: Product Manager**
|
|
301
|
-
// turbo
|
|
302
|
-
|
|
303
|
-
1. **Update MOC Files**: Ensure all MOCs reference new documents
|
|
304
|
-
2. **Update Index**: Add project section to `docs/000-Index.md`
|
|
305
|
-
3. **Present Final Summary**:
|
|
306
|
-
|
|
307
|
-
```
|
|
308
|
-
✅ REQUIREMENT ANALYSIS COMPLETE
|
|
309
|
-
════════════════════════════════
|
|
310
|
-
|
|
311
|
-
📁 Documents Created:
|
|
312
|
-
├── Roadmap: docs/010-Planning/Roadmap-{ProjectName}.md
|
|
313
|
-
├── PRD: docs/020-Requirements/PRD-{ProjectName}.md
|
|
314
|
-
├── SDD: docs/030-Specs/Architecture/SDD-{ProjectName}.md
|
|
315
|
-
├── Epics: {N} files in docs/022-User-Stories/Epics/
|
|
316
|
-
├── Use Cases: {N} files in docs/020-Requirements/Use-Cases/
|
|
317
|
-
├── Stories: {N} files in docs/022-User-Stories/Backlog/
|
|
318
|
-
└── ADRs: {N} files in docs/030-Specs/Architecture/ (if any)
|
|
319
|
-
|
|
320
|
-
📋 Updated MOCs:
|
|
321
|
-
├── docs/010-Planning/Planning-MOC.md
|
|
322
|
-
├── docs/020-Requirements/Requirements-MOC.md
|
|
323
|
-
├── docs/022-User-Stories/Stories-MOC.md
|
|
324
|
-
└── docs/030-Specs/Specs-MOC.md
|
|
325
|
-
|
|
326
|
-
🚀 Next Steps:
|
|
327
|
-
1. Review documents for accuracy
|
|
328
|
-
2. Run /ui-ux-design-from-doc for design phase
|
|
329
|
-
3. Move Stories to Active-Sprint when ready
|
|
330
|
-
```
|
|
331
|
-
|
|
332
|
-
---
|
|
333
|
-
|
|
334
|
-
## Quick Reference
|
|
335
|
-
|
|
336
|
-
> 📖 For detailed folder structure and naming conventions, see `.agent/rules/documentation.md`
|
|
@@ -1,97 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Initialize codebase and dependencies based on SDD/ADR
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Setup Codebase Workflow
|
|
6
|
-
|
|
7
|
-
This workflow sets up the **Next.js 16** project structure, installs dependencies, and configures the environment based on `docs/030-Specs/Architecture/SDD-AILearningGame.md`.
|
|
8
|
-
|
|
9
|
-
> [!WARNING]
|
|
10
|
-
> This workflow assumes you want to initialize the project in the current directory. If `package.json` already exists with conflicting dependencies, verify before running.
|
|
11
|
-
|
|
12
|
-
---
|
|
13
|
-
|
|
14
|
-
## Step 1: Initialize Framework
|
|
15
|
-
|
|
16
|
-
**Role: DevOps**
|
|
17
|
-
|
|
18
|
-
1. **Initialize Next.js**:
|
|
19
|
-
- We will use `npx create-next-app` to set up the foundation.
|
|
20
|
-
- **Command**: `npx create-next-app@latest . --typescript --tailwind --eslint --app --src-dir --import-alias "@/*" --use-npm --yes`
|
|
21
|
-
- _Note_: If the directory is not empty, this command might prompt for confirmation or fail. Ensure you are ready to merge/overwrite.
|
|
22
|
-
|
|
23
|
-
2. **Execute Initialization**:
|
|
24
|
-
- **→ Execute `run_command`**: `npx create-next-app@latest . --typescript --tailwind --eslint --app --src-dir --import-alias "@/*" --use-npm --yes`
|
|
25
|
-
|
|
26
|
-
3. **WAIT** for command completion.
|
|
27
|
-
|
|
28
|
-
---
|
|
29
|
-
|
|
30
|
-
## Step 2: Install Project Dependencies
|
|
31
|
-
|
|
32
|
-
**Role: DevOps**
|
|
33
|
-
// turbo
|
|
34
|
-
|
|
35
|
-
1. **Install Core Libraries** (State, Analytics, Utils):
|
|
36
|
-
- **→ Execute `run_command`**: `npm install zustand next-intl lucide-react clsx tailwind-merge`
|
|
37
|
-
|
|
38
|
-
2. **Install Animation & UI**:
|
|
39
|
-
- **→ Execute `run_command`**: `npm install framer-motion`
|
|
40
|
-
|
|
41
|
-
3. **Install Backend/Data**:
|
|
42
|
-
- **→ Execute `run_command`**: `npm install @supabase/supabase-js @supabase/ssr`
|
|
43
|
-
|
|
44
|
-
4. **Install Game Engines (Lazy Loaded)**:
|
|
45
|
-
- **→ Execute `run_command`**: `npm install phaser three @types/three @react-three/fiber @react-three/drei @monaco-editor/react`
|
|
46
|
-
|
|
47
|
-
5. **Install Dev Tools**:
|
|
48
|
-
- **→ Execute `run_command`**: `npm install -D prettier prettier-plugin-tailwindcss`
|
|
49
|
-
|
|
50
|
-
---
|
|
51
|
-
|
|
52
|
-
## Step 3: Scaffold Modular Architecture
|
|
53
|
-
|
|
54
|
-
**Role: Lead Architect**
|
|
55
|
-
// turbo
|
|
56
|
-
|
|
57
|
-
Create the directory structure defined in `SDD-AILearningGame.md`.
|
|
58
|
-
|
|
59
|
-
1. **Create Module Directories**:
|
|
60
|
-
- **→ Execute `run_command`**:
|
|
61
|
-
```bash
|
|
62
|
-
mkdir -p src/modules/visual-novel/components src/modules/visual-novel/engine src/modules/visual-novel/data
|
|
63
|
-
mkdir -p src/modules/simulation/components src/modules/simulation/scenes src/modules/simulation/entities
|
|
64
|
-
mkdir -p src/modules/code-editor/components src/modules/code-editor/sandbox src/modules/code-editor/challenges
|
|
65
|
-
```
|
|
66
|
-
|
|
67
|
-
2. **Create Core Directories**:
|
|
68
|
-
- **→ Execute `run_command`**:
|
|
69
|
-
```bash
|
|
70
|
-
mkdir -p src/components/ui src/components/layout
|
|
71
|
-
mkdir -p src/lib/supabase
|
|
72
|
-
mkdir -p src/store
|
|
73
|
-
mkdir -p src/types
|
|
74
|
-
mkdir -p src/hooks
|
|
75
|
-
```
|
|
76
|
-
|
|
77
|
-
---
|
|
78
|
-
|
|
79
|
-
## Step 4: Configuration Files
|
|
80
|
-
|
|
81
|
-
**Role: Backend Developer**
|
|
82
|
-
|
|
83
|
-
1. **Setup Environment Variables**:
|
|
84
|
-
- **→ Execute `write_to_file`**: Create `.env.local.example` with placeholders.
|
|
85
|
-
2. **Setup Utility Helper**:
|
|
86
|
-
- **→ Execute `write_to_file`**: Create `src/lib/utils.ts` with `clsx` and `tailwind-merge` utility.
|
|
87
|
-
|
|
88
|
-
---
|
|
89
|
-
|
|
90
|
-
## Step 5: Verification
|
|
91
|
-
|
|
92
|
-
**Role: QA**
|
|
93
|
-
|
|
94
|
-
1. **Verify Structure**:
|
|
95
|
-
- **→ Execute `run_command`**: `ls -R src/modules`
|
|
96
|
-
2. **Verify Build**:
|
|
97
|
-
- **→ Execute `run_command`**: `npm run build`
|
|
@@ -1,43 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Analyze the current codebase to generate a project context rule file.
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Workflow: Generate Rule from Codebase
|
|
6
|
-
|
|
7
|
-
Use this workflow to "learn" the project's existing patterns, stack, and conventions by scanning the codebase. This is useful when joining an existing project.
|
|
8
|
-
|
|
9
|
-
## Step 1: Discovery Scan
|
|
10
|
-
|
|
11
|
-
1. **Read Configuration**: Check `package.json`, `tsconfig.json`, `drizzle.config.ts`, `wrangler.toml`, etc.
|
|
12
|
-
2. **Analyze Structure**: Run `list_dir` on root and `app/` or `src/` to understand the architecture.
|
|
13
|
-
3. **Sample Code**: Read 2-3 representative files (e.g., a component, an API route, a schema definition) to understand coding style (naming, exports, type usage).
|
|
14
|
-
|
|
15
|
-
## Step 2: Synthesize Observations
|
|
16
|
-
|
|
17
|
-
Identify key facts:
|
|
18
|
-
|
|
19
|
-
- **Tech Stack**: Frameworks, ORMs, UI Libraries.
|
|
20
|
-
- **Conventions**: File naming (kebab vs camel), Component structure, Data fetching patterns.
|
|
21
|
-
- **Directories**: Where does code live? (e.g., `app/routes` vs `src/pages`).
|
|
22
|
-
|
|
23
|
-
## Step 3: Create Project Rules
|
|
24
|
-
|
|
25
|
-
Create a file named `.agent/rules/project-rules.md`.
|
|
26
|
-
|
|
27
|
-
**Content Structure**:
|
|
28
|
-
|
|
29
|
-
1. **Project Overview**: One line summary.
|
|
30
|
-
2. **Tech Stack**: Bullet points of major tools.
|
|
31
|
-
3. **Key Conventions**: detailed "Do's and Don'ts".
|
|
32
|
-
4. **Architecture**: Brief explanation of folder structure.
|
|
33
|
-
|
|
34
|
-
// turbo
|
|
35
|
-
|
|
36
|
-
## Step 4: Write the File
|
|
37
|
-
|
|
38
|
-
Use `write_to_file` to create `.agent/rules/project-rules.md`. If it exists, overwrite it with the fresh analysis.
|
|
39
|
-
|
|
40
|
-
## Step 5: Validation
|
|
41
|
-
|
|
42
|
-
1. Check if the new rule aligns with `package.json` dependencies.
|
|
43
|
-
2. Notify the user that project context has been refreshed.
|
|
@@ -1,38 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Create or update a project rule based on specific user feedback or corrections.
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Workflow: Extract Rule from Feedback
|
|
6
|
-
|
|
7
|
-
Use this workflow when the user provides explicit feedback about how they want the agent to behave, code preferences, or structural constraints (e.g., "Don't use library X", "Always name files Y").
|
|
8
|
-
|
|
9
|
-
## Step 1: Analyze Feedback & Existing Rules
|
|
10
|
-
|
|
11
|
-
1. **Analyze the User's Request**: Identifying the constraint or preference. Is it a global preference or specific to a file type?
|
|
12
|
-
2. **Check Existing Rules**: Look in `.agent/rules/` to see if a conflicting or similar rule already exists.
|
|
13
|
-
- If it contradicts an existing rule, you will need to UPDATE the old rule.
|
|
14
|
-
- If it's new, you will CREATE a new rule.
|
|
15
|
-
|
|
16
|
-
## Step 2: Determine Target Rule File
|
|
17
|
-
|
|
18
|
-
Decide where this rule belongs:
|
|
19
|
-
|
|
20
|
-
- **Default**: Update `.agent/rules/project-rules.md`. This is the central source of truth.
|
|
21
|
-
- **Exception**: If the rule is extremely complex or requires a very specific glob pattern (e.g., specific to only `.css` files), create a dedicated file.
|
|
22
|
-
|
|
23
|
-
## Step 3: Update Project Content
|
|
24
|
-
|
|
25
|
-
1. **Read**: Read `.agent/rules/project-rules.md`.
|
|
26
|
-
2. **Append/Update**: Add the new rule to the "Key Conventions" or "User Preferences" section.
|
|
27
|
-
- Format: `- **[Rule Name]**: [Description]`.
|
|
28
|
-
3. **Conflict Check**: Ensure it doesn't contradict existing lines.
|
|
29
|
-
|
|
30
|
-
## Step 4: Write the File
|
|
31
|
-
|
|
32
|
-
1. Use `replace_file_content` (or `write_to_file` if creating new) to save the changes.
|
|
33
|
-
2. **Validation**: Ensure the file format remains valid markdown.
|
|
34
|
-
|
|
35
|
-
## Step 5: Confirmation
|
|
36
|
-
|
|
37
|
-
1. Notify the user that the rule has been learned.
|
|
38
|
-
2. (Optional) If this feedback was given during a task, ask if you should re-run the previous step with the new rule applied.
|
/package/.agent/skills/rules-workflows/assets/{example-rule-always-on.md → rule-always-on.md}
RENAMED
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|