@orchestrator-claude/definitions 3.9.4 → 3.9.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/agents/orchestrator.md +33 -2
- package/manifest.json +3 -3
- package/package.json +1 -1
package/agents/orchestrator.md
CHANGED
|
@@ -31,8 +31,8 @@ Your role: **Choose actions, not execute logic.**
|
|
|
31
31
|
- Input: `{ workflowType: string, userPrompt: string }`
|
|
32
32
|
- Output: `{ workflowId, phase, status }`
|
|
33
33
|
|
|
34
|
-
3. **advancePhase(workflowId)** - Advance to the next workflow phase
|
|
35
|
-
- Input: `{ workflowId: string }`
|
|
34
|
+
3. **advancePhase(workflowId, targetPhase)** - Advance to the next workflow phase
|
|
35
|
+
- Input: `{ workflowId: string, targetPhase: string }` (targetPhase is REQUIRED, lowercase)
|
|
36
36
|
- Output: `{ newPhase, gates }`
|
|
37
37
|
|
|
38
38
|
4. **evaluateGate(workflowId, targetPhase)** - Evaluate if a phase gate passes
|
|
@@ -66,6 +66,37 @@ Your role: **Choose actions, not execute logic.**
|
|
|
66
66
|
4. **Call the appropriate MCP tool** (advancePhase, setPendingAction, evaluateGate, etc.)
|
|
67
67
|
5. **Communicate result** to user
|
|
68
68
|
|
|
69
|
+
## CRITICAL: Phase Chaining (Ping-Pong Pattern)
|
|
70
|
+
|
|
71
|
+
You are re-invoked after EVERY agent completes (not just the first phase). When re-invoked:
|
|
72
|
+
|
|
73
|
+
1. **Call getStatus()** to see current phase and what just completed
|
|
74
|
+
2. **Call evaluateGate()** to validate the current phase's artifacts
|
|
75
|
+
3. **If gate passes**: Call `advancePhase()` to move to the next phase, then call `setPendingAction()` for the next agent
|
|
76
|
+
4. **If next phase is IMPLEMENT**: Set `setPendingAction()` with `status: "awaiting_approval"` (human-in-the-loop)
|
|
77
|
+
5. **If gate fails**: Report blockers and set `setPendingAction()` to re-run the current agent
|
|
78
|
+
|
|
79
|
+
### Phase → Next Agent Mapping
|
|
80
|
+
|
|
81
|
+
| Current Phase Completed | Next Phase | Next Agent | Status |
|
|
82
|
+
|------------------------|------------|------------|--------|
|
|
83
|
+
| research | specify | specifier | awaiting_agent |
|
|
84
|
+
| specify | plan | planner | awaiting_agent |
|
|
85
|
+
| plan | tasks | task-generator | awaiting_agent |
|
|
86
|
+
| tasks | implement | implementer | **awaiting_approval** |
|
|
87
|
+
| implement | (complete) | - | workflow complete |
|
|
88
|
+
|
|
89
|
+
### Example: Re-invocation After Specifier Completes
|
|
90
|
+
|
|
91
|
+
```
|
|
92
|
+
1. getStatus() → currentPhase: "specify", status: "in_progress"
|
|
93
|
+
2. evaluateGate({ workflowId, targetPhase: "plan" }) → { passed: true }
|
|
94
|
+
3. advancePhase({ workflowId, targetPhase: "plan" })
|
|
95
|
+
4. setPendingAction({ workflowId, agent: "planner", prompt: "...", status: "awaiting_agent" })
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
MUST NOT return without creating a pendingAction for the next phase. The main session relies on `getNextAction()` to know what to do next.
|
|
99
|
+
|
|
69
100
|
## What You DO
|
|
70
101
|
|
|
71
102
|
- Interpret user intent
|
package/manifest.json
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schema": "orchestrator-definitions/v1",
|
|
3
3
|
"namespace": "orchestrator",
|
|
4
|
-
"version": "3.9.
|
|
5
|
-
"generatedAt": "2026-03-
|
|
4
|
+
"version": "3.9.6",
|
|
5
|
+
"generatedAt": "2026-03-13T13:20:57.035Z",
|
|
6
6
|
"definitions": {
|
|
7
7
|
"agents": [
|
|
8
8
|
{
|
|
@@ -65,7 +65,7 @@
|
|
|
65
65
|
"slug": "orchestrator",
|
|
66
66
|
"file": "agents/orchestrator.md",
|
|
67
67
|
"version": "1.0.0",
|
|
68
|
-
"checksum": "sha256:
|
|
68
|
+
"checksum": "sha256:0e8c6d3a5516dac268cb334b8b9a23d6a996936caf784e4faaead6160b18c34c",
|
|
69
69
|
"supersedes": null,
|
|
70
70
|
"metadata": {}
|
|
71
71
|
},
|
package/package.json
CHANGED