forge-orkes 0.5.1 → 0.6.1
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/package.json
CHANGED
|
@@ -40,6 +40,33 @@ Sessions `/clear` or die mid-discussion. Previous behavior: decisions lived only
|
|
|
40
40
|
|
|
41
41
|
Now: any `/clear` preserves everything decided so far. Worst case on interruption = last answer lost, not all answers.
|
|
42
42
|
|
|
43
|
+
## Functionality Distillation
|
|
44
|
+
|
|
45
|
+
Per feature, force behavioral clarity. Surface assumptions + edge cases.
|
|
46
|
+
|
|
47
|
+
**L1 (Happy Path):** *"See first?" / "Sequence?" / "Confirms success?"*
|
|
48
|
+
**L2 (Rules):** *"Who can?" / "Limits?" / "Trigger type?"*
|
|
49
|
+
**L3 (Failures):** *"Invalid/down/cancel?" / "Retry/fail/alert?" / "Concurrent?"*
|
|
50
|
+
**L4 (Side Effects):** *"Else updates?" / "Notify?" / "Undo?"*
|
|
51
|
+
**L5 (Evolution):** *"v1 or final?" / "Essential vs nice-to-have?"*
|
|
52
|
+
|
|
53
|
+
**Listen for:** Contradictions ("Simple" + "12 states"), Vague ("Just work" → push for example), Assumed knowledge ("Like Stripe" → confirm specifics), Energy shifts (excitement/boredom = signal).
|
|
54
|
+
|
|
55
|
+
Not all 5 mechanically. 2-3 questions, deeper on uncertainty. `AskUserQuestion` for discrete; prose to explain.
|
|
56
|
+
|
|
57
|
+
Example -- L3:
|
|
58
|
+
```
|
|
59
|
+
question: "When the enrichment API is down, what should the system do?"
|
|
60
|
+
header: "Failure mode"
|
|
61
|
+
options:
|
|
62
|
+
- label: "Retry with backoff (Recommended)"
|
|
63
|
+
description: "Queue retries at 1m/5m/30m. Adds complexity but self-heals."
|
|
64
|
+
- label: "Fail and alert"
|
|
65
|
+
description: "Mark failed, send alert. Simple but requires manual re-trigger."
|
|
66
|
+
- label: "Skip and continue"
|
|
67
|
+
description: "Process remaining items, revisit failures in next sweep."
|
|
68
|
+
```
|
|
69
|
+
|
|
43
70
|
## Pre-Planning Discussion
|
|
44
71
|
|
|
45
72
|
### Step 0: Load Context
|
|
@@ -114,33 +141,10 @@ Open-ended via prose: *"Tried before?" / "Must-haves or must-nots?"* 1-2 at a ti
|
|
|
114
141
|
|
|
115
142
|
### Step 4: Functionality Distillation
|
|
116
143
|
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
**L1 (Happy Path):** *"See first?" / "Sequence?" / "Confirms success?"*
|
|
120
|
-
**L2 (Rules):** *"Who can?" / "Limits?" / "Trigger type?"*
|
|
121
|
-
**L3 (Failures):** *"Invalid/down/cancel?" / "Retry/fail/alert?" / "Concurrent?"*
|
|
122
|
-
**L4 (Side Effects):** *"Else updates?" / "Notify?" / "Undo?"*
|
|
123
|
-
**L5 (Evolution):** *"v1 or final?" / "Essential vs nice-to-have?"*
|
|
124
|
-
|
|
125
|
-
**Listen for:** Contradictions ("Simple" + "12 states"), Vague ("Just work" → push for example), Assumed knowledge ("Like Stripe" → confirm specifics), Energy shifts (excitement/boredom = signal).
|
|
126
|
-
|
|
127
|
-
Not all 5 mechanically. 2-3 questions, deeper on uncertainty. `AskUserQuestion` for discrete; prose to explain.
|
|
144
|
+
Apply Functionality Distillation (above), grounded in research findings.
|
|
128
145
|
|
|
129
146
|
**After each user response:** write confirmed behavioral decisions to `context.md` immediately.
|
|
130
147
|
|
|
131
|
-
Example -- L3:
|
|
132
|
-
```
|
|
133
|
-
question: "When the enrichment API is down, what should the system do?"
|
|
134
|
-
header: "Failure mode"
|
|
135
|
-
options:
|
|
136
|
-
- label: "Retry with backoff (Recommended)"
|
|
137
|
-
description: "Queue retries at 1m/5m/30m. Adds complexity but self-heals."
|
|
138
|
-
- label: "Fail and alert"
|
|
139
|
-
description: "Mark failed, send alert. Simple but requires manual re-trigger."
|
|
140
|
-
- label: "Skip and continue"
|
|
141
|
-
description: "Process remaining items, revisit failures in next sweep."
|
|
142
|
-
```
|
|
143
|
-
|
|
144
148
|
### Step 5: Converge
|
|
145
149
|
|
|
146
150
|
Summarize decided items, then confirm:
|
|
@@ -157,8 +161,6 @@ options:
|
|
|
157
161
|
description: "Topics we haven't covered yet."
|
|
158
162
|
```
|
|
159
163
|
|
|
160
|
-
Decisions written to `.forge/context.md` at Phase Handoff (below).
|
|
161
|
-
|
|
162
164
|
## Post-Planning Discussion
|
|
163
165
|
|
|
164
166
|
### Step 1: Load Context
|
|
@@ -184,7 +186,7 @@ Translate into meaning, don't recite. Example: *"Phase 2: 3 plans, 8 tasks. Plan
|
|
|
184
186
|
|
|
185
187
|
### Step 4: Drill Functionality
|
|
186
188
|
|
|
187
|
-
Apply
|
|
189
|
+
Apply Functionality Distillation (above), grounded in plan tasks:
|
|
188
190
|
|
|
189
191
|
- *"Notification service send failure -- retry or log?"*
|
|
190
192
|
- *"Dashboard-to-API -- poll or push?"*
|
|
@@ -255,6 +257,4 @@ After convergence:
|
|
|
255
257
|
- Add any unresolved items to `## Needs Resolution`
|
|
256
258
|
- If `context.md` already exists (post-planning discussion), update relevant sections + log amendments
|
|
257
259
|
2. **Update state** -- `current.status` = `planning` (`architecting` for Full) in milestone yml
|
|
258
|
-
3. **Recommend clear:**
|
|
259
|
-
|
|
260
|
-
*"Decisions written to `.forge/context.md`. State updated. `/clear` then `/forge` to continue with {planning/architecting}."*
|
|
260
|
+
3. **Recommend clear:** *"State written. `/clear` then `/forge` for {planning/architecting}."*
|
|
@@ -119,6 +119,8 @@ Subagents via `Agent` tool → same precedence, enforced via `model` param.
|
|
|
119
119
|
| discussing | sonnet | Conversation |
|
|
120
120
|
| testing | sonnet | Code gen (author) + audit judgment (analyst) — matches executing/reviewing |
|
|
121
121
|
|
|
122
|
+
*Model enforced only for Agent-dispatched skills (verifying, quick-tasking). Skill-routed phases are advisory — use `/model` to switch.*
|
|
123
|
+
|
|
122
124
|
| `current.status` | Route To | Method |
|
|
123
125
|
|-------------------|----------|--------|
|
|
124
126
|
| `not_started` | Detect tier, start | — |
|
|
@@ -130,51 +132,82 @@ Subagents via `Agent` tool → same precedence, enforced via `model` param.
|
|
|
130
132
|
| `verifying` | Agent-dispatched → reviewing | **Agent** |
|
|
131
133
|
| `reviewing` | `Skill(reviewing)` → complete | Skill |
|
|
132
134
|
| `complete` | Done. Ask what's next. | — |
|
|
135
|
+
| `quick-tasking` | Agent-dispatched (Quick tier / refactor-backlog) | **Agent** |
|
|
136
|
+
|
|
137
|
+
**Phases marked Agent MUST use `Agent()` with `model` param. Never `Skill()` — model enforcement only works through `Agent()`.**
|
|
133
138
|
|
|
134
139
|
### Agent-Dispatched Phases
|
|
135
140
|
|
|
136
|
-
|
|
141
|
+
Phases marked **Agent** run as spawned agents to enforce model routing. `Agent` tool's `model` param = only enforcement point.
|
|
142
|
+
|
|
143
|
+
**Skill contract:** Each dispatched skill carries a guard header — if parent loads via Skill(), guard says STOP.
|
|
144
|
+
|
|
145
|
+
**Parent protocol:**
|
|
146
|
+
1. Resolve model: `models.skills.{skill}` → `models.default` → parent
|
|
147
|
+
2. On return: read updated state, display *"Result: {outcome}. Model: {model} (enforced)."*, route next
|
|
137
148
|
|
|
138
|
-
|
|
149
|
+
**Agent prompt requirements:** `touch .forge/.active-skill` (pre-commit guard) + "Report resolved model in summary."
|
|
139
150
|
|
|
140
|
-
|
|
151
|
+
#### Verifying
|
|
141
152
|
|
|
142
|
-
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
|
|
153
|
+
When `current.status == verifying`:
|
|
154
|
+
|
|
155
|
+
1. Read milestone state → identify plan path
|
|
156
|
+
2. Spawn:
|
|
146
157
|
|
|
147
158
|
```
|
|
148
159
|
Agent(
|
|
149
|
-
model: "{
|
|
160
|
+
model: "{model}",
|
|
150
161
|
description: "Verify milestone {id}: {name}",
|
|
151
|
-
prompt: "You are a verifier agent.
|
|
162
|
+
prompt: "You are a verifier agent. Prove completed work delivers what was promised.
|
|
152
163
|
|
|
153
|
-
FIRST: Run `touch .forge/.active-skill`
|
|
164
|
+
FIRST: Run `touch .forge/.active-skill`
|
|
154
165
|
|
|
155
|
-
Read
|
|
156
|
-
- .claude/skills/verifying/SKILL.md —
|
|
157
|
-
- .claude/agents/verifier.md —
|
|
166
|
+
Read:
|
|
167
|
+
- .claude/skills/verifying/SKILL.md — process instructions
|
|
168
|
+
- .claude/agents/verifier.md — role, tools, output format
|
|
158
169
|
- .forge/state/milestone-{id}.yml — current state
|
|
159
|
-
- .forge/phases/{phase_path}/plan-{NN}.md — must_haves
|
|
160
|
-
- .forge/project.yml —
|
|
170
|
+
- .forge/phases/{phase_path}/plan-{NN}.md — must_haves
|
|
171
|
+
- .forge/project.yml — stack, verification commands
|
|
161
172
|
- .forge/context.md — locked decisions
|
|
162
|
-
- .forge/requirements.yml — requirement
|
|
173
|
+
- .forge/requirements.yml — requirement coverage
|
|
163
174
|
|
|
164
|
-
Follow
|
|
165
|
-
Write
|
|
166
|
-
Update
|
|
167
|
-
|
|
175
|
+
Follow verifying/SKILL.md 3-level process exactly.
|
|
176
|
+
Write results to plan directory.
|
|
177
|
+
Update state: 'reviewing' if PASSED, keep 'verifying' if GAPS.
|
|
178
|
+
Report resolved model in summary."
|
|
168
179
|
)
|
|
169
180
|
```
|
|
170
181
|
|
|
171
|
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
|
|
182
|
+
3. On return: PASSED → reviewing. GAPS → planning (gap-closure).
|
|
183
|
+
|
|
184
|
+
#### Quick-Tasking
|
|
185
|
+
|
|
186
|
+
Quick-tasking runs as Agent from Quick tier or refactor-backlog. Parent constructs prompt based on milestone context:
|
|
187
|
+
|
|
188
|
+
```
|
|
189
|
+
Agent(
|
|
190
|
+
model: "{model}",
|
|
191
|
+
description: "Quick fix: {description}",
|
|
192
|
+
prompt: "You are a quick-tasking agent. Small, scoped fix.
|
|
193
|
+
|
|
194
|
+
FIRST: Run `touch .forge/.active-skill`
|
|
195
|
+
|
|
196
|
+
Read:
|
|
197
|
+
- .claude/skills/quick-tasking/SKILL.md — workflow
|
|
198
|
+
- .forge/project.yml — stack, verification commands
|
|
199
|
+
[with milestone: + .forge/state/milestone-{id}.yml, .forge/context.md]
|
|
200
|
+
|
|
201
|
+
Task: {description}
|
|
202
|
+
|
|
203
|
+
Follow quick-tasking/SKILL.md workflow.
|
|
204
|
+
[with milestone: After commit, update milestone-{id}.yml (increment progress, log deviations).]
|
|
205
|
+
[without milestone: No state management.]
|
|
206
|
+
Report resolved model in summary."
|
|
207
|
+
)
|
|
208
|
+
```
|
|
176
209
|
|
|
177
|
-
|
|
210
|
+
On return: display result + model. With milestone → read updated state.
|
|
178
211
|
|
|
179
212
|
### Status Advancement Check
|
|
180
213
|
|
|
@@ -3,6 +3,8 @@ name: quick-tasking
|
|
|
3
3
|
description: "Small, scoped changes: typo fixes, config updates, minor bugs, dependency bumps, doc tweaks. Under 50 lines, 1-2 files, no architectural decisions. Quick tier — skip ceremony."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
+
> **AGENT-DISPATCHED:** If reading in parent session, STOP — use Agent() via forge/SKILL.md § Agent-Dispatched Phases.
|
|
7
|
+
|
|
6
8
|
# Quick-Tasking
|
|
7
9
|
|
|
8
10
|
Small change? Skip ceremony. Do it right, do it fast.
|
|
@@ -60,6 +62,27 @@ Example: `fix(docs): correct typo in API reference`
|
|
|
60
62
|
### 6. Done
|
|
61
63
|
No verification ceremony. Move on.
|
|
62
64
|
|
|
65
|
+
## Milestone Context
|
|
66
|
+
|
|
67
|
+
Quick-tasking handles two contexts. Existing workflow steps (Identify → Validate → Execute → Test → Commit → Done) apply in both — this section adds state management around them.
|
|
68
|
+
|
|
69
|
+
### With Milestone
|
|
70
|
+
|
|
71
|
+
Invoked via forge routing (mid-workflow or refactor-backlog item with milestone context):
|
|
72
|
+
|
|
73
|
+
1. Read `.forge/state/milestone-{id}.yml` for current position
|
|
74
|
+
2. Follow standard workflow (above)
|
|
75
|
+
3. After commit: update milestone state — increment `progress.overall_percent`, log deviations if any Rule 1-3 applied
|
|
76
|
+
4. Report: fix description, files changed, milestone progress update
|
|
77
|
+
|
|
78
|
+
### Without Milestone
|
|
79
|
+
|
|
80
|
+
Standalone quick fix (no forge state exists or no milestone context provided):
|
|
81
|
+
|
|
82
|
+
1. Follow standard workflow (above)
|
|
83
|
+
2. No state reads or writes
|
|
84
|
+
3. Report: fix description, files changed
|
|
85
|
+
|
|
63
86
|
## Scope Creep Detection
|
|
64
87
|
|
|
65
88
|
During execution, if you discover:
|
|
@@ -3,6 +3,8 @@ name: verifying
|
|
|
3
3
|
description: "Prove completed work delivers what was promised. Goal-backward verification with 3 levels: Observable Truths, Artifacts, and Key Links. Task completion ≠ goal achievement."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
+
> **AGENT-DISPATCHED:** If reading in parent session, STOP — use Agent() via forge/SKILL.md § Agent-Dispatched Phases.
|
|
7
|
+
|
|
6
8
|
# Verifying
|
|
7
9
|
|
|
8
10
|
Prove completed work delivers what was promised. Task completion ≠ goal achievement.
|
|
@@ -194,8 +196,6 @@ After PASSED verdict:
|
|
|
194
196
|
|
|
195
197
|
1. **Persist** — Confirm verification results documented, desire paths logged to `.forge/state/index.yml`
|
|
196
198
|
2. **Update state** — Set `current.status` to `reviewing` in `.forge/state/milestone-{id}.yml`
|
|
197
|
-
3. **Recommend
|
|
198
|
-
|
|
199
|
-
*"Verification passed. State written. `/clear` then `/forge` to continue with reviewing."*
|
|
199
|
+
3. **Recommend clear:** *"State written. `/clear` then `/forge` for reviewing."*
|
|
200
200
|
|
|
201
201
|
If GAPS found, route back to planning in gap-closure mode. Context clear applies after re-verified PASSED verdict.
|