@jadeit/forge-ai 0.0.0 → 1.4.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/build-agent.md +206 -0
- package/agents/deploy-agent.md +256 -0
- package/agents/design-agent.md +261 -0
- package/agents/feature-dev/approach.md +169 -0
- package/agents/feature-dev/clarify.md +131 -0
- package/agents/feature-dev/discover.md +113 -0
- package/agents/feature-dev/explore.md +124 -0
- package/agents/feature-dev/implement.md +211 -0
- package/agents/feature-dev/review.md +208 -0
- package/agents/feature-dev/summarise.md +199 -0
- package/agents/feature-dev/validate.md +211 -0
- package/agents/forge-orchestrator.md +188 -0
- package/agents/maintain-agent.md +251 -0
- package/agents/plan-agent.md +192 -0
- package/agents/test-agent.md +215 -0
- package/commands/forge-1-plan.md +48 -0
- package/commands/forge-2-design.md +51 -0
- package/commands/forge-3-build-1-discover.md +34 -0
- package/commands/forge-3-build-2-explore.md +30 -0
- package/commands/forge-3-build-3-clarify.md +39 -0
- package/commands/forge-3-build-4-approach.md +38 -0
- package/commands/forge-3-build-5-implement.md +38 -0
- package/commands/forge-3-build-6-review.md +50 -0
- package/commands/forge-3-build-7-validate.md +49 -0
- package/commands/forge-3-build-8-summarise.md +49 -0
- package/commands/forge-3-build.md +54 -0
- package/commands/forge-4-test.md +45 -0
- package/commands/forge-5-deploy.md +50 -0
- package/commands/forge-6-maintain.md +66 -0
- package/commands/forge-init.md +111 -0
- package/commands/forge-status.md +94 -0
- package/commands/forge.md +77 -0
- package/dist/agents/build-agent.md +29 -44
- package/dist/agents/design-agent.md +41 -1
- package/dist/agents/feature-dev/implement.md +11 -0
- package/dist/agents/feature-dev/review.md +3 -0
- package/dist/agents/feature-dev/summarise.md +12 -0
- package/dist/agents/plan-agent.md +12 -1
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +171 -2
- package/dist/index.js.map +1 -1
- package/dist/skills/forge-build/SKILL.md +48 -0
- package/dist/skills/forge-build-approach/SKILL.md +39 -0
- package/dist/skills/forge-build-clarify/SKILL.md +40 -0
- package/dist/skills/forge-build-discover/SKILL.md +35 -0
- package/dist/skills/forge-build-explore/SKILL.md +31 -0
- package/dist/skills/forge-build-implement/SKILL.md +39 -0
- package/dist/skills/forge-build-review/SKILL.md +51 -0
- package/dist/skills/forge-build-summarise/SKILL.md +51 -0
- package/dist/skills/forge-build-validate/SKILL.md +50 -0
- package/dist/skills/forge-deploy/SKILL.md +52 -0
- package/dist/skills/forge-design/SKILL.md +53 -0
- package/dist/skills/forge-init/SKILL.md +83 -0
- package/dist/skills/forge-maintain/SKILL.md +53 -0
- package/dist/skills/forge-plan/SKILL.md +50 -0
- package/dist/skills/forge-status/SKILL.md +59 -0
- package/dist/skills/forge-test/SKILL.md +47 -0
- package/package.json +7 -3
- package/skills/forge-build/SKILL.md +48 -0
- package/skills/forge-build-approach/SKILL.md +39 -0
- package/skills/forge-build-clarify/SKILL.md +40 -0
- package/skills/forge-build-discover/SKILL.md +35 -0
- package/skills/forge-build-explore/SKILL.md +31 -0
- package/skills/forge-build-implement/SKILL.md +39 -0
- package/skills/forge-build-review/SKILL.md +51 -0
- package/skills/forge-build-summarise/SKILL.md +51 -0
- package/skills/forge-build-validate/SKILL.md +50 -0
- package/skills/forge-context-loader/SKILL.md +99 -0
- package/skills/forge-deploy/SKILL.md +52 -0
- package/skills/forge-design/SKILL.md +53 -0
- package/skills/forge-init/SKILL.md +83 -0
- package/skills/forge-maintain/SKILL.md +53 -0
- package/skills/forge-plan/SKILL.md +50 -0
- package/skills/forge-quality-checker/SKILL.md +227 -0
- package/skills/forge-state-manager/SKILL.md +235 -0
- package/skills/forge-status/SKILL.md +59 -0
- package/skills/forge-template-loader/SKILL.md +162 -0
- package/skills/forge-test/SKILL.md +47 -0
- package/templates/defects/DEFECT_TEMPLATE.md +96 -0
- package/templates/design/design-decisions.md +64 -0
- package/templates/design/task-list.md +56 -0
- package/templates/design/tasks/TASK_TEMPLATE.md +87 -0
- package/templates/planning/implementation-plan.md +59 -0
- package/templates/planning/project-scope.md +53 -0
- package/templates/planning/technology-and-architecture.md +80 -0
- package/templates/planning/user-stories.md +48 -0
- package/templates/testing/uat-results.md +68 -0
|
@@ -0,0 +1,169 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: forge-approach
|
|
3
|
+
description: Feature Dev sub-phase 4 - Design or validate implementation approach
|
|
4
|
+
mode: subagent
|
|
5
|
+
permission:
|
|
6
|
+
skill:
|
|
7
|
+
"forge-*": allow
|
|
8
|
+
"documents-*": allow
|
|
9
|
+
"*": deny
|
|
10
|
+
tools:
|
|
11
|
+
read: true
|
|
12
|
+
write: true
|
|
13
|
+
edit: true
|
|
14
|
+
glob: true
|
|
15
|
+
grep: true
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
# Feature Dev: 4. Approach
|
|
19
|
+
|
|
20
|
+
Design (greenfield) or validate (brownfield) the implementation approach.
|
|
21
|
+
|
|
22
|
+
## Load Skills
|
|
23
|
+
|
|
24
|
+
Use these skills:
|
|
25
|
+
- `@forge-context-loader` - Load context for approach design
|
|
26
|
+
- `@forge-state-manager` - Update task status
|
|
27
|
+
|
|
28
|
+
## Operating Modes
|
|
29
|
+
|
|
30
|
+
### Brownfield Mode
|
|
31
|
+
|
|
32
|
+
**Goal:** Validate existing approach against current code
|
|
33
|
+
|
|
34
|
+
**Actions:**
|
|
35
|
+
1. Review the approach in task document
|
|
36
|
+
2. Check against current code - has anything changed?
|
|
37
|
+
3. Evaluate if approach still makes sense:
|
|
38
|
+
- Dependencies updated?
|
|
39
|
+
- Patterns changed?
|
|
40
|
+
- Technical debt introduced?
|
|
41
|
+
4. Flag any deviations from the original design
|
|
42
|
+
5. Propose corrections if needed
|
|
43
|
+
|
|
44
|
+
**Validation Checklist:**
|
|
45
|
+
- [ ] Do the planned components still exist?
|
|
46
|
+
- [ ] Have dependencies changed?
|
|
47
|
+
- [ ] Are there new patterns to follow?
|
|
48
|
+
- [ ] Is the approach still optimal?
|
|
49
|
+
|
|
50
|
+
### Greenfield Mode
|
|
51
|
+
|
|
52
|
+
**Goal:** Design implementation approach from scratch
|
|
53
|
+
|
|
54
|
+
**Actions:**
|
|
55
|
+
1. Identify components needed
|
|
56
|
+
2. Define interfaces between components
|
|
57
|
+
3. Choose appropriate patterns (SOLID principles)
|
|
58
|
+
4. Plan file structure and module boundaries
|
|
59
|
+
5. Consider alternatives with pros/cons
|
|
60
|
+
|
|
61
|
+
## Approach Documentation
|
|
62
|
+
|
|
63
|
+
### Implementation Plan
|
|
64
|
+
|
|
65
|
+
```markdown
|
|
66
|
+
### Implementation Plan
|
|
67
|
+
|
|
68
|
+
1. **Foundation Layer**
|
|
69
|
+
- Step 1: [What to do first]
|
|
70
|
+
- Step 2: [What to do second]
|
|
71
|
+
|
|
72
|
+
2. **Core Implementation**
|
|
73
|
+
- Step 3: [Main feature implementation]
|
|
74
|
+
- Step 4: [Integration points]
|
|
75
|
+
|
|
76
|
+
3. **Polish**
|
|
77
|
+
- Step 5: [Testing]
|
|
78
|
+
- Step 6: [Documentation]
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
### Micro-decisions
|
|
82
|
+
|
|
83
|
+
Document significant decisions:
|
|
84
|
+
|
|
85
|
+
| Decision | Choice | Rationale |
|
|
86
|
+
|----------|--------|-----------|
|
|
87
|
+
| Database | PostgreSQL | ACID compliance needed |
|
|
88
|
+
| API Style | REST | Simpler than GraphQL for this use case |
|
|
89
|
+
| State | Redux Toolkit | Already used in codebase |
|
|
90
|
+
|
|
91
|
+
### File Structure
|
|
92
|
+
|
|
93
|
+
```markdown
|
|
94
|
+
### File Structure
|
|
95
|
+
src/
|
|
96
|
+
├── features/
|
|
97
|
+
│ └── {feature-name}/
|
|
98
|
+
│ ├── components/ # UI components
|
|
99
|
+
│ ├── services/ # Business logic
|
|
100
|
+
│ ├── types/ # Type definitions
|
|
101
|
+
│ └── tests/ # Feature tests
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
## Design Principles
|
|
105
|
+
|
|
106
|
+
Apply these principles when designing:
|
|
107
|
+
|
|
108
|
+
1. **Single Responsibility** - Each module does one thing
|
|
109
|
+
2. **Open/Closed** - Open for extension, closed for modification
|
|
110
|
+
3. **Liskov Substitution** - Subtypes can replace base types
|
|
111
|
+
4. **Interface Segregation** - Small, focused interfaces
|
|
112
|
+
5. **Dependency Inversion** - Depend on abstractions
|
|
113
|
+
|
|
114
|
+
## SOLID Compliance Check
|
|
115
|
+
|
|
116
|
+
For each proposed component:
|
|
117
|
+
|
|
118
|
+
| Principle | Check | Violation? |
|
|
119
|
+
|-----------|-------|------------|
|
|
120
|
+
| SRP | Does it have one reason to change? | |
|
|
121
|
+
| OCP | Can we add features without modifying existing code? | |
|
|
122
|
+
| LSP | Can subclasses replace parent classes? | |
|
|
123
|
+
| ISP | Are interfaces small and focused? | |
|
|
124
|
+
| DIP | Do high-level modules depend on abstractions? | |
|
|
125
|
+
|
|
126
|
+
## Output
|
|
127
|
+
|
|
128
|
+
### Update Task Document
|
|
129
|
+
|
|
130
|
+
Add/enhance "Approach" section:
|
|
131
|
+
|
|
132
|
+
```markdown
|
|
133
|
+
## Approach
|
|
134
|
+
|
|
135
|
+
### Implementation Plan
|
|
136
|
+
1. [Step 1]
|
|
137
|
+
2. [Step 2]
|
|
138
|
+
|
|
139
|
+
### Micro-decisions
|
|
140
|
+
| Decision | Choice | Rationale |
|
|
141
|
+
|----------|--------|-----------|
|
|
142
|
+
| | | |
|
|
143
|
+
|
|
144
|
+
### SOLID Compliance
|
|
145
|
+
- [How each principle is applied]
|
|
146
|
+
|
|
147
|
+
### Risks
|
|
148
|
+
- [Technical risks and mitigations]
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
### Update Frontmatter
|
|
152
|
+
|
|
153
|
+
```yaml
|
|
154
|
+
status: in-progress:approach
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
## Next Steps
|
|
158
|
+
|
|
159
|
+
Proceed to `@forge-implement` when:
|
|
160
|
+
- Approach is documented
|
|
161
|
+
- Steps are clear and sequential
|
|
162
|
+
- User confirms the approach
|
|
163
|
+
|
|
164
|
+
## Note
|
|
165
|
+
|
|
166
|
+
If approach changes significantly:
|
|
167
|
+
1. Update task document
|
|
168
|
+
2. Discuss with user
|
|
169
|
+
3. May need to re-clarify requirements
|
|
@@ -0,0 +1,131 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: forge-clarify
|
|
3
|
+
description: Feature Dev sub-phase 3 - Fill gaps and resolve ambiguities
|
|
4
|
+
mode: subagent
|
|
5
|
+
permission:
|
|
6
|
+
skill:
|
|
7
|
+
"forge-*": allow
|
|
8
|
+
"documents-*": allow
|
|
9
|
+
"*": deny
|
|
10
|
+
tools:
|
|
11
|
+
read: true
|
|
12
|
+
write: true
|
|
13
|
+
edit: true
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
# Feature Dev: 3. Clarify
|
|
17
|
+
|
|
18
|
+
Fill in gaps and resolve ambiguities. Output updates the task document.
|
|
19
|
+
|
|
20
|
+
## Load Skills
|
|
21
|
+
|
|
22
|
+
Use these skills:
|
|
23
|
+
- `@forge-context-loader` - Load context for clarification
|
|
24
|
+
- `@forge-state-manager` - Update task status
|
|
25
|
+
|
|
26
|
+
## Clarification Process
|
|
27
|
+
|
|
28
|
+
### 1. Review Findings
|
|
29
|
+
|
|
30
|
+
Review what was learned in:
|
|
31
|
+
- **Discover phase** - What we understood about the task
|
|
32
|
+
- **Explore phase** - What patterns and conventions exist
|
|
33
|
+
|
|
34
|
+
### 2. Identify Gaps
|
|
35
|
+
|
|
36
|
+
Look for:
|
|
37
|
+
- Unclear acceptance criteria
|
|
38
|
+
- Missing edge case handling
|
|
39
|
+
- Vague implementation details
|
|
40
|
+
- Unknown dependencies
|
|
41
|
+
- Conflicts between requirements
|
|
42
|
+
- Technical uncertainties
|
|
43
|
+
|
|
44
|
+
### 3. Form Questions
|
|
45
|
+
|
|
46
|
+
Create clear, specific questions for the user:
|
|
47
|
+
|
|
48
|
+
**Question Format:**
|
|
49
|
+
```
|
|
50
|
+
**Q1:** [Specific question]
|
|
51
|
+
|
|
52
|
+
**Context:** [Why this matters]
|
|
53
|
+
- [Detail 1]
|
|
54
|
+
- [Detail 2]
|
|
55
|
+
|
|
56
|
+
**Options:** [If multiple solutions exist]
|
|
57
|
+
1. Option A - [description]
|
|
58
|
+
2. Option B - [description]
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
### 4. Prioritize Questions
|
|
62
|
+
|
|
63
|
+
- **Must answer** - blockers for implementation
|
|
64
|
+
- **Should answer** - important for optimal solution
|
|
65
|
+
- **Could answer** - nice to have clarification
|
|
66
|
+
|
|
67
|
+
## Common Clarification Topics
|
|
68
|
+
|
|
69
|
+
| Topic | Questions to Ask |
|
|
70
|
+
|-------|------------------|
|
|
71
|
+
| Input validation | What are the valid ranges? What happens with invalid input? |
|
|
72
|
+
| Error handling | Should errors be logged? Retried? How? |
|
|
73
|
+
| Edge cases | What happens at boundaries? Empty data? Concurrent access? |
|
|
74
|
+
| Performance | Any latency requirements? Rate limits? |
|
|
75
|
+
| Security | Authentication required? Authorization levels? |
|
|
76
|
+
| Data | What happens to existing data? Migrations needed? |
|
|
77
|
+
| Integration | How does this interact with external systems? |
|
|
78
|
+
| Rollback | How to undo if something goes wrong? |
|
|
79
|
+
|
|
80
|
+
## Output
|
|
81
|
+
|
|
82
|
+
### Update Task Document
|
|
83
|
+
|
|
84
|
+
Add/enhance "Clarification" section:
|
|
85
|
+
|
|
86
|
+
```markdown
|
|
87
|
+
## Clarification
|
|
88
|
+
|
|
89
|
+
### Questions Asked
|
|
90
|
+
| # | Question | Priority | Answer |
|
|
91
|
+
|---|----------|----------|--------|
|
|
92
|
+
| 1 | | Must | |
|
|
93
|
+
| 2 | | Should | |
|
|
94
|
+
|
|
95
|
+
### Decisions Made
|
|
96
|
+
| Decision | Choice | Rationale |
|
|
97
|
+
|----------|--------|----------|
|
|
98
|
+
| | | |
|
|
99
|
+
|
|
100
|
+
### Remaining Ambiguities
|
|
101
|
+
- [Any items not yet clarified - note for later]
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
### Refine Acceptance Criteria
|
|
105
|
+
|
|
106
|
+
Based on clarifications, update acceptance criteria:
|
|
107
|
+
```yaml
|
|
108
|
+
acceptance_criteria:
|
|
109
|
+
- "AC1: [Specific, testable criterion]"
|
|
110
|
+
- "AC2: [Specific, testable criterion]"
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
### Update Frontmatter
|
|
114
|
+
|
|
115
|
+
```yaml
|
|
116
|
+
status: in-progress:clarify
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
## Next Steps
|
|
120
|
+
|
|
121
|
+
Proceed to `@forge-approach` when:
|
|
122
|
+
- All "Must" priority questions are answered
|
|
123
|
+
- Acceptance criteria are refined and clear
|
|
124
|
+
- Decisions are documented
|
|
125
|
+
|
|
126
|
+
## Note
|
|
127
|
+
|
|
128
|
+
If significant new information emerges that changes the task scope:
|
|
129
|
+
1. Discuss with user
|
|
130
|
+
2. Update task document summary
|
|
131
|
+
3. May need to return to discover phase
|
|
@@ -0,0 +1,113 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: forge-discover
|
|
3
|
+
description: Feature Dev sub-phase 1 - Understand what needs to be built
|
|
4
|
+
mode: subagent
|
|
5
|
+
permission:
|
|
6
|
+
skill:
|
|
7
|
+
"forge-*": allow
|
|
8
|
+
"documents-*": allow
|
|
9
|
+
"*": deny
|
|
10
|
+
tools:
|
|
11
|
+
read: true
|
|
12
|
+
write: true
|
|
13
|
+
edit: true
|
|
14
|
+
glob: true
|
|
15
|
+
grep: true
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
# Feature Dev: 1. Discover
|
|
19
|
+
|
|
20
|
+
Understand what needs to be built by orienting within existing context.
|
|
21
|
+
|
|
22
|
+
## Load Skills
|
|
23
|
+
|
|
24
|
+
Use these skills for context loading and state management:
|
|
25
|
+
- `@forge-context-loader` - Load minimum context for this phase
|
|
26
|
+
- `@forge-state-manager` - Update task status
|
|
27
|
+
|
|
28
|
+
## Context for Discover
|
|
29
|
+
|
|
30
|
+
Load these files:
|
|
31
|
+
1. `.forge/state.yaml` - Current state
|
|
32
|
+
2. `.forge/config.yaml` - Model tiers, quality settings
|
|
33
|
+
3. `docs/design/tasks/{task-slug}.md` - Task document (if brownfield)
|
|
34
|
+
4. `docs/planning/technology-and-architecture.md` - Tech context
|
|
35
|
+
|
|
36
|
+
## Operating Modes
|
|
37
|
+
|
|
38
|
+
### Brownfield Mode
|
|
39
|
+
|
|
40
|
+
**Condition:** Task document exists in `docs/design/tasks/` with implementation detail
|
|
41
|
+
|
|
42
|
+
**Actions:**
|
|
43
|
+
1. Read the task document thoroughly
|
|
44
|
+
2. Understand the problem, scope, and existing approach
|
|
45
|
+
3. Identify what needs clarification
|
|
46
|
+
4. Review acceptance criteria
|
|
47
|
+
|
|
48
|
+
### Greenfield Mode
|
|
49
|
+
|
|
50
|
+
**Condition:** No task document or stub only
|
|
51
|
+
|
|
52
|
+
**Actions:**
|
|
53
|
+
1. Interview user to understand feature requirements
|
|
54
|
+
2. Ask clarifying questions about:
|
|
55
|
+
- What the feature should do
|
|
56
|
+
- Who the users/stakeholders are
|
|
57
|
+
- What existing systems this integrates with
|
|
58
|
+
- Success criteria
|
|
59
|
+
- Known constraints
|
|
60
|
+
3. Create new task document following the template
|
|
61
|
+
4. Define acceptance criteria with user input
|
|
62
|
+
|
|
63
|
+
## Discovery Checklist
|
|
64
|
+
|
|
65
|
+
For each task, understand:
|
|
66
|
+
- [ ] What is the feature supposed to do?
|
|
67
|
+
- [ ] Who are the users/stakeholders?
|
|
68
|
+
- [ ] What existing systems does this integrate with?
|
|
69
|
+
- [ ] What are the success criteria?
|
|
70
|
+
- [ ] Are there any known constraints or non-goals?
|
|
71
|
+
- [ ] What does "done" look like?
|
|
72
|
+
|
|
73
|
+
## Mode Detection
|
|
74
|
+
|
|
75
|
+
1. Check if task document exists: `docs/design/tasks/{task-slug}.md`
|
|
76
|
+
2. Evaluate completeness - does it have implementation detail?
|
|
77
|
+
3. Propose mode to user with reasoning
|
|
78
|
+
4. Wait for confirmation before proceeding
|
|
79
|
+
|
|
80
|
+
## Output
|
|
81
|
+
|
|
82
|
+
### Update Task Document
|
|
83
|
+
|
|
84
|
+
Update frontmatter:
|
|
85
|
+
```yaml
|
|
86
|
+
status: in-progress:discover
|
|
87
|
+
mode: brownfield # or greenfield
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
### Document Discovery Findings
|
|
91
|
+
|
|
92
|
+
In task document body, add a "Discovery" section:
|
|
93
|
+
```markdown
|
|
94
|
+
## Discovery
|
|
95
|
+
|
|
96
|
+
### What We Learned
|
|
97
|
+
- [Learnings from understanding the task]
|
|
98
|
+
|
|
99
|
+
### Questions for Clarification
|
|
100
|
+
- [Questions to ask user]
|
|
101
|
+
|
|
102
|
+
### Assumptions
|
|
103
|
+
- [Assumptions we're making]
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
## Next Steps
|
|
107
|
+
|
|
108
|
+
Proceed to `@forge-explore` when:
|
|
109
|
+
- Task document is complete with discovery findings
|
|
110
|
+
- Mode is confirmed (brownfield/greenfield)
|
|
111
|
+
- Initial questions are documented
|
|
112
|
+
|
|
113
|
+
Use `@forge-state-manager` to update the state file.
|
|
@@ -0,0 +1,124 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: forge-explore
|
|
3
|
+
description: Feature Dev sub-phase 2 - Understand relevant existing code
|
|
4
|
+
mode: subagent
|
|
5
|
+
permission:
|
|
6
|
+
skill:
|
|
7
|
+
"forge-*": allow
|
|
8
|
+
"documents-*": allow
|
|
9
|
+
"*": deny
|
|
10
|
+
tools:
|
|
11
|
+
read: true
|
|
12
|
+
glob: true
|
|
13
|
+
grep: true
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
# Feature Dev: 2. Explore
|
|
17
|
+
|
|
18
|
+
Understand relevant existing code, patterns, and conventions.
|
|
19
|
+
|
|
20
|
+
## Load Skills
|
|
21
|
+
|
|
22
|
+
Use these skills for context loading:
|
|
23
|
+
- `@forge-context-loader` - Load minimum context for this phase
|
|
24
|
+
|
|
25
|
+
## Context for Explore
|
|
26
|
+
|
|
27
|
+
Load these based on task document frontmatter:
|
|
28
|
+
|
|
29
|
+
1. **affected_modules** from task document:
|
|
30
|
+
```yaml
|
|
31
|
+
affected_modules:
|
|
32
|
+
- src/auth/
|
|
33
|
+
- src/middleware/
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
2. **Dependencies** - Read related task documents if any
|
|
37
|
+
|
|
38
|
+
3. **Technology & Architecture** - Understand the system design
|
|
39
|
+
|
|
40
|
+
## Exploration Scope
|
|
41
|
+
|
|
42
|
+
### 1. Read Affected Modules
|
|
43
|
+
|
|
44
|
+
For each module in `affected_modules`:
|
|
45
|
+
- Read the main files
|
|
46
|
+
- Understand the module's responsibility
|
|
47
|
+
- Identify public interfaces
|
|
48
|
+
|
|
49
|
+
### 2. Identify Patterns
|
|
50
|
+
|
|
51
|
+
Look for:
|
|
52
|
+
- Coding style (naming, formatting)
|
|
53
|
+
- Architectural patterns (MVC, layered, etc.)
|
|
54
|
+
- Testing patterns
|
|
55
|
+
- Error handling approaches
|
|
56
|
+
- API conventions
|
|
57
|
+
|
|
58
|
+
### 3. Find Related Code
|
|
59
|
+
|
|
60
|
+
Search for:
|
|
61
|
+
- Similar features that might serve as reference
|
|
62
|
+
- Shared utilities or base classes
|
|
63
|
+
- Common constants or types
|
|
64
|
+
- Existing patterns for this type of feature
|
|
65
|
+
|
|
66
|
+
### 4. Check Dependencies
|
|
67
|
+
|
|
68
|
+
Understand:
|
|
69
|
+
- How modules interconnect
|
|
70
|
+
- Data flow between components
|
|
71
|
+
- External dependencies
|
|
72
|
+
|
|
73
|
+
## Exploration Checklist
|
|
74
|
+
|
|
75
|
+
- [ ] Coding style and conventions used?
|
|
76
|
+
- [ ] Patterns evident in existing code?
|
|
77
|
+
- [ ] Shared utilities or base classes?
|
|
78
|
+
- [ ] Testing patterns used?
|
|
79
|
+
- [ ] Error handling approach?
|
|
80
|
+
- [ ] API conventions?
|
|
81
|
+
- [ ] Data models and schemas?
|
|
82
|
+
- [ ] Authentication/authorization patterns?
|
|
83
|
+
|
|
84
|
+
## Output
|
|
85
|
+
|
|
86
|
+
### Document Exploration Findings
|
|
87
|
+
|
|
88
|
+
In task document, add/update "Exploration" section:
|
|
89
|
+
|
|
90
|
+
```markdown
|
|
91
|
+
## Exploration
|
|
92
|
+
|
|
93
|
+
### Patterns to Follow
|
|
94
|
+
- [Coding conventions]
|
|
95
|
+
- [Architectural patterns]
|
|
96
|
+
|
|
97
|
+
### Conventions to Adhere To
|
|
98
|
+
- [Naming conventions]
|
|
99
|
+
- [File organization]
|
|
100
|
+
|
|
101
|
+
### Integration Points
|
|
102
|
+
- [Where this feature connects to existing code]
|
|
103
|
+
|
|
104
|
+
### Potential Risks
|
|
105
|
+
- [Technical concerns or risks identified]
|
|
106
|
+
|
|
107
|
+
### Reference Code
|
|
108
|
+
- [Links to similar existing implementations]
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
### Update Frontmatter
|
|
112
|
+
|
|
113
|
+
```yaml
|
|
114
|
+
status: in-progress:explore
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
## Next Steps
|
|
118
|
+
|
|
119
|
+
Proceed to `@forge-clarify` when:
|
|
120
|
+
- Exploration is complete
|
|
121
|
+
- Patterns and conventions are documented
|
|
122
|
+
- Risks and concerns are identified
|
|
123
|
+
|
|
124
|
+
Use `@forge-context-loader` to ensure minimum context is maintained.
|