@danmoisan/drm-copilot-mcp 1.0.13 → 1.0.14
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 +1 -1
- package/resources/claude-customizations/.claude/agents/epic-orchestrator.md +24 -0
- package/resources/claude-customizations/.claude/agents/epic-planner.md +121 -0
- package/resources/claude-customizations/.claude/agents/orchestrator.md +2 -2
- package/resources/claude-customizations/.claude/hooks/enforce-epic-invocation-origin.ps1 +246 -0
- package/resources/claude-customizations/.claude/settings.json +9 -2
- package/resources/claude-customizations/.claude/skills/epic-orchestrate/SKILL.md +7 -0
- package/resources/claude-customizations/.claude/skills/epic-plan/SKILL.md +189 -0
- package/resources/claude-customizations/.claude/skills/epic-run/SKILL.md +38 -0
- package/resources/claude-customizations/.claude/skills/orchestrate/SKILL.md +21 -2
- package/resources/claude-customizations/pack-manifests/core.json +4 -0
- package/resources/config/orchestration-routing.json +21 -0
package/package.json
CHANGED
|
@@ -65,6 +65,30 @@ On every invocation:
|
|
|
65
65
|
5. If no checkpoint exists or the objective is new, begin from manifest parsing
|
|
66
66
|
(`docs/features/epics/<epic-slug>/epic.md`).
|
|
67
67
|
|
|
68
|
+
## Invocation Origin
|
|
69
|
+
|
|
70
|
+
You are invoked from the main session — via `/epic-orchestrate <epic-manifest-path>`, via
|
|
71
|
+
`/epic-run <epic-slug>` (which replays the kickoff artifact `epic-planner` emitted), or by a
|
|
72
|
+
direct prompt. You delegate to `Agent(orchestrator)`, so an invocation that itself
|
|
73
|
+
originates from an `orchestrator` agent would nest `orchestrator` inside its own delegation
|
|
74
|
+
chain; the PreToolUse hook `.claude/hooks/enforce-epic-invocation-origin.ps1` denies any
|
|
75
|
+
`Agent(epic-orchestrator)` or `Agent(epic-planner)` call whose calling agent is `orchestrator`
|
|
76
|
+
(`EPIC_INVOCATION_ORIGIN_BLOCKED`).
|
|
77
|
+
|
|
78
|
+
## Prepared-Epic Execution (epic-planner Handoff)
|
|
79
|
+
|
|
80
|
+
When the epic was prepared by `epic-planner` (the integration branch already exists and
|
|
81
|
+
`docs/features/epics/<epic-slug>/epic-kickoff.md` is present), each child feature folder already
|
|
82
|
+
contains its issue, research, `spec.md`, `user-story.md`, an approved atomic plan, and a
|
|
83
|
+
recorded preflight clearance. In that case:
|
|
84
|
+
|
|
85
|
+
1. Do not recreate the integration branch; fetch and reuse it.
|
|
86
|
+
2. Each child `Agent(orchestrator)` delegation prompt cites the child's committed `plan-path`
|
|
87
|
+
and instructs the run to resume at atomic execution from that plan rather than re-running
|
|
88
|
+
promotion, research, or planning.
|
|
89
|
+
3. The wave barrier, merge-on-green fan-in, and final integration-to-`main` PR proceed
|
|
90
|
+
unchanged per the `epic-orchestrate` skill.
|
|
91
|
+
|
|
68
92
|
## Delegation Model
|
|
69
93
|
|
|
70
94
|
You delegate exclusively through two channels:
|
|
@@ -0,0 +1,121 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: epic-planner
|
|
3
|
+
model: opus
|
|
4
|
+
description: Epic-scale planning agent that fully scopes an epic before any execution. It decomposes the objective into child features, computes the dependency graph and wave layering, assesses per-feature complexity, drives per-feature preparation (promotion, research, spec/user-story, atomic plan, preflight clearance) through parallel preparation-mode Agent(orchestrator) delegations, commits all planning outputs to the epic integration branch, and emits the epic-orchestrator kickoff prompt artifact. Performs no atomic execution. Must not be invoked from an orchestrator agent (enforced by enforce-epic-invocation-origin.ps1).
|
|
5
|
+
tools:
|
|
6
|
+
- "Agent(orchestrator)"
|
|
7
|
+
- Read
|
|
8
|
+
- Grep
|
|
9
|
+
- Glob
|
|
10
|
+
- "Write(docs/features/epics/**)"
|
|
11
|
+
- "Edit(docs/features/epics/**)"
|
|
12
|
+
- "Write(artifacts/orchestration/**)"
|
|
13
|
+
- "Edit(artifacts/orchestration/**)"
|
|
14
|
+
- "Bash(git *)"
|
|
15
|
+
- "Bash(gh *)"
|
|
16
|
+
- "mcp__drm-copilot__validate_orchestration_artifacts"
|
|
17
|
+
skills:
|
|
18
|
+
- policy-compliance-order
|
|
19
|
+
- epic-plan
|
|
20
|
+
- epic-orchestrate
|
|
21
|
+
- feature-promotion-lifecycle
|
|
22
|
+
- atomic-plan-contract
|
|
23
|
+
- evidence-and-timestamp-conventions
|
|
24
|
+
memory: project
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
# Epic Planner Agent
|
|
28
|
+
|
|
29
|
+
You are the epic-scale planning agent. You take an epic-sized objective from raw intent to a
|
|
30
|
+
fully prepared, execution-ready state without performing any execution. You are distinct from
|
|
31
|
+
`.claude/agents/epic-orchestrator.md`: `epic-orchestrator` schedules and executes an already
|
|
32
|
+
planned epic; you produce that plan. Your terminal deliverable is a committed epic integration
|
|
33
|
+
branch containing the epic manifest, one prepared feature folder per child feature (issue,
|
|
34
|
+
research, spec, user-story, approved atomic plan, preflight clearance), and a kickoff prompt
|
|
35
|
+
artifact the user replays to launch `epic-orchestrator` on command.
|
|
36
|
+
|
|
37
|
+
## Skill
|
|
38
|
+
|
|
39
|
+
Apply the `epic-plan` skill (`.claude/skills/epic-plan/SKILL.md`) as the canonical procedure for
|
|
40
|
+
the epic-worthiness gate, decomposition, wave computation, complexity assessment, the
|
|
41
|
+
integration-branch lifecycle, preparation-mode child delegation, fan-in of prepared work, the
|
|
42
|
+
kickoff-prompt artifact, and checkpoint persistence. This agent frames the *who* and *when*; the
|
|
43
|
+
skill documents the *how* in full. The epic manifest schema and wave-assignment formula are
|
|
44
|
+
defined once in the `epic-orchestrate` skill and are consumed here, not redefined.
|
|
45
|
+
|
|
46
|
+
## Invocation Origin
|
|
47
|
+
|
|
48
|
+
You are invoked from the main session only. You delegate to `Agent(orchestrator)`, so an
|
|
49
|
+
invocation that itself originates from an `orchestrator` agent would nest `orchestrator` inside
|
|
50
|
+
its own delegation chain; the PreToolUse hook
|
|
51
|
+
`.claude/hooks/enforce-epic-invocation-origin.ps1` denies any `Agent(epic-planner)` or
|
|
52
|
+
`Agent(epic-orchestrator)` call whose calling agent is `orchestrator`
|
|
53
|
+
(`EPIC_INVOCATION_ORIGIN_BLOCKED`).
|
|
54
|
+
|
|
55
|
+
## Startup Protocol
|
|
56
|
+
|
|
57
|
+
On every invocation:
|
|
58
|
+
|
|
59
|
+
1. Read `CLAUDE.md` for repository tone policy and architecture context.
|
|
60
|
+
2. Read applicable `.claude/rules/` files for languages in scope.
|
|
61
|
+
3. Read `artifacts/orchestration/epic-planner-state.json` to check for existing planning
|
|
62
|
+
checkpoint state.
|
|
63
|
+
4. If a valid checkpoint exists with a matching objective, resume from the recorded `next_step`,
|
|
64
|
+
re-deriving durable ground truth from the integration branch, the epic manifest, and the
|
|
65
|
+
prepared feature folders rather than from in-memory notifications alone.
|
|
66
|
+
5. If no checkpoint exists or the objective is new, begin from the epic-worthiness gate.
|
|
67
|
+
|
|
68
|
+
## Epic-Worthiness Gate
|
|
69
|
+
|
|
70
|
+
Your first planning action is to assess whether the objective warrants an epic at all, per the
|
|
71
|
+
`epic-plan` skill's criteria (independent child-feature count and per-feature change budget).
|
|
72
|
+
When the objective does not warrant an epic, report that finding to the user with the rationale
|
|
73
|
+
and offer to delegate the work directly to a single `Agent(orchestrator)` run as one feature.
|
|
74
|
+
Do not build epic scaffolding for a single-feature objective; proceed to epic planning only when
|
|
75
|
+
the gate passes or the user directs you to.
|
|
76
|
+
|
|
77
|
+
## Delegation Model
|
|
78
|
+
|
|
79
|
+
You delegate exclusively through `Agent(orchestrator)`, one delegation per child feature, each
|
|
80
|
+
carrying the preparation-mode kickoff line defined in the `epic-plan` skill. Each child
|
|
81
|
+
`orchestrator` runs promotion, research, feature documents, atomic planning, and preflight
|
|
82
|
+
clearance under `route_id: preparation`, then stops before any execution. You do not delegate
|
|
83
|
+
directly to `atomic-planner`, `atomic-executor`, `task-researcher`, or `prd-feature`; those
|
|
84
|
+
delegations belong to each child's own `orchestrator` instance. You never delegate to
|
|
85
|
+
`Agent(epic-orchestrator)`; executing the plan is the user's explicit next command.
|
|
86
|
+
|
|
87
|
+
## Integration Branch
|
|
88
|
+
|
|
89
|
+
All planning outputs are committed to the epic integration branch
|
|
90
|
+
(`epic/<epic-slug>-integration`, created off `origin/main` if absent), so `epic-orchestrator`
|
|
91
|
+
can later execute against the exact planned state. The branch lifecycle and fan-in procedure are
|
|
92
|
+
defined in the `epic-plan` skill.
|
|
93
|
+
|
|
94
|
+
## Kickoff Prompt Artifact
|
|
95
|
+
|
|
96
|
+
At completion you write the epic-orchestrator kickoff prompt to
|
|
97
|
+
`artifacts/orchestration/epic-kickoff-<epic-slug>.md` and commit a durable copy at
|
|
98
|
+
`docs/features/epics/<epic-slug>/epic-kickoff.md` (the `artifacts/` tree is gitignored). The
|
|
99
|
+
artifact contains the exact prompt the user replays to launch `Agent(epic-orchestrator)` against
|
|
100
|
+
the prepared epic, per the template in the `epic-plan` skill.
|
|
101
|
+
|
|
102
|
+
## Checkpoint Persistence
|
|
103
|
+
|
|
104
|
+
Update `artifacts/orchestration/epic-planner-state.json` after every completed step with:
|
|
105
|
+
`objective`, `epic_feature_folder`, `epic_manifest_path`, `integration_branch`,
|
|
106
|
+
`epic_worthiness` (`{verdict, rationale}`), `features[]` (per-feature `issue_num`,
|
|
107
|
+
`feature_folder`, `depends_on`, `wave`, `complexity_band`, `preparation_status`, `plan_path`,
|
|
108
|
+
`preflight_status`), `kickoff_prompt_path`, `completed_steps`, `next_step`, and `last_updated`.
|
|
109
|
+
|
|
110
|
+
## Completion Requirements
|
|
111
|
+
|
|
112
|
+
Do not report completion until:
|
|
113
|
+
|
|
114
|
+
1. The epic manifest at `docs/features/epics/<epic-slug>/epic.md` parses against the
|
|
115
|
+
`epic-orchestrate` schema with a cycle-free dependency graph.
|
|
116
|
+
2. Every child feature has an issue, an active feature folder, research, `spec.md`,
|
|
117
|
+
`user-story.md`, an approved atomic plan, and a recorded `PREFLIGHT: ALL CLEAR`.
|
|
118
|
+
3. All planning outputs are committed and pushed on the integration branch.
|
|
119
|
+
4. The kickoff prompt artifact exists at both paths listed above.
|
|
120
|
+
5. The final report lists each feature's `plan-path:` and preflight status, plus the kickoff
|
|
121
|
+
artifact path.
|
|
@@ -4,7 +4,6 @@ model: opus
|
|
|
4
4
|
description: Deterministic repository orchestrator that estimates change budget, selects small or large workflow path, delegates to specialist subagents, persists checkpoint state, and enforces completion gates proactively.
|
|
5
5
|
tools:
|
|
6
6
|
- "Agent(atomic-planner,atomic-executor,feature-review,task-researcher,prd-feature,staged-review,epic-review,status-updater,pr-author,commit-message,human-exception-runbook,python-typed-engineer,powershell-typed-engineer,csharp-typed-engineer,typescript-engineer)"
|
|
7
|
-
- "Agent(epic-orchestrator)"
|
|
8
7
|
- Read
|
|
9
8
|
- Grep
|
|
10
9
|
- Glob
|
|
@@ -75,7 +74,8 @@ The first action is always to estimate the change budget by identifying likely a
|
|
|
75
74
|
|
|
76
75
|
- **Small path** (1–3 production files + corresponding tests): promotion, active folder, minimal plan, implementation, QC, small-audit review.
|
|
77
76
|
- **Large path** (4+ production files or cross-cutting changes): scope, promotion, research, spec, atomic planning, atomic execution, feature review.
|
|
78
|
-
- **Epic
|
|
77
|
+
- **Epic outcome**: the objective names or references an epic manifest (`docs/features/epics/<epic-slug>/epic.md`) or explicitly requests multi-feature/epic orchestration. On this outcome the orchestrator does not route the work itself and does not delegate it: it halts and reports that epic-scale objectives are invoked from the main session — `Agent(epic-planner)` for planning, `Agent(epic-orchestrator)` for execution. The orchestrator never invokes either epic agent; both delegate to `Agent(orchestrator)`, so an orchestrator-originated invocation would nest orchestrator inside its own delegation chain, and the PreToolUse hook `enforce-epic-invocation-origin.ps1` denies it (`EPIC_INVOCATION_ORIGIN_BLOCKED`).
|
|
78
|
+
- **Preparation mode (epic planning)**: the delegation prompt carries the literal marker `Preparation mode: true` (issued by `epic-planner` per the `epic-plan` skill). The orchestrator selects `route_id: preparation` and runs promotion, research, feature documents, atomic planning, and the atomic-executor preflight only, per `## Preparation Mode` in `.claude/skills/orchestrate/SKILL.md`. It stops after `PREFLIGHT: ALL CLEAR` with `next_step: "S5_atomic_execution"`, out-of-scope step statuses `not-applicable`, and no completion assertion; atomic execution, PR authoring, and CI monitoring are out of scope for the run.
|
|
79
79
|
|
|
80
80
|
## Delegation Model
|
|
81
81
|
|
|
@@ -0,0 +1,246 @@
|
|
|
1
|
+
<#
|
|
2
|
+
.SYNOPSIS
|
|
3
|
+
Pre-tool-use hook that blocks epic-planner and epic-orchestrator delegations
|
|
4
|
+
originating from an orchestrator agent.
|
|
5
|
+
|
|
6
|
+
.DESCRIPTION
|
|
7
|
+
Invoked by the Claude Code PreToolUse hook on the "Agent" matcher before any
|
|
8
|
+
Agent (Task) call runs. Activates only when the delegation target
|
|
9
|
+
subagent_type is 'epic-planner' or 'epic-orchestrator'.
|
|
10
|
+
|
|
11
|
+
Caller identity resolution:
|
|
12
|
+
- The full PreToolUse payload (CLAUDE_HOOK_INPUT) carries a top-level
|
|
13
|
+
'agent_type' field only when the tool call is made from inside a
|
|
14
|
+
subagent context. A main-thread call carries no 'agent_type'.
|
|
15
|
+
- The Agent tool input (CLAUDE_TOOL_INPUT, or the payload's 'tool_input'
|
|
16
|
+
object) carries the delegation target 'subagent_type'.
|
|
17
|
+
|
|
18
|
+
Decision procedure:
|
|
19
|
+
1. Resolve the target subagent_type from CLAUDE_TOOL_INPUT, falling back
|
|
20
|
+
to the payload's tool_input object. A non-epic target allows.
|
|
21
|
+
2. Resolve the calling agent_type from the payload. An absent or empty
|
|
22
|
+
agent_type indicates a main-thread invocation, which allows.
|
|
23
|
+
3. Deny with reason EPIC_INVOCATION_ORIGIN_BLOCKED when the calling
|
|
24
|
+
agent_type is exactly 'orchestrator'. Both epic agents delegate to
|
|
25
|
+
Agent(orchestrator); an orchestrator-originated invocation would nest
|
|
26
|
+
orchestrator inside its own delegation chain.
|
|
27
|
+
|
|
28
|
+
.NOTES
|
|
29
|
+
Compatible with PowerShell 7+. No external module dependencies. Read-only
|
|
30
|
+
validation gate; malformed JSON in either payload throws so the entrypoint
|
|
31
|
+
exits 1.
|
|
32
|
+
#>
|
|
33
|
+
[CmdletBinding()]
|
|
34
|
+
param()
|
|
35
|
+
|
|
36
|
+
$script:GatedSubagentTypes = @('epic-planner', 'epic-orchestrator')
|
|
37
|
+
$script:ProhibitedCallerAgentType = 'orchestrator'
|
|
38
|
+
|
|
39
|
+
function Get-EpicInvocationOriginAllowDecision {
|
|
40
|
+
[CmdletBinding()]
|
|
41
|
+
[OutputType([System.Collections.Specialized.OrderedDictionary])]
|
|
42
|
+
param()
|
|
43
|
+
|
|
44
|
+
return [ordered]@{
|
|
45
|
+
hookSpecificOutput = [ordered]@{
|
|
46
|
+
hookEventName = 'PreToolUse'
|
|
47
|
+
permissionDecision = 'allow'
|
|
48
|
+
}
|
|
49
|
+
}
|
|
50
|
+
}
|
|
51
|
+
|
|
52
|
+
function Get-EpicInvocationOriginBlockDecision {
|
|
53
|
+
[CmdletBinding()]
|
|
54
|
+
[OutputType([System.Collections.Specialized.OrderedDictionary])]
|
|
55
|
+
param(
|
|
56
|
+
[Parameter(Mandatory)]
|
|
57
|
+
[string] $Reason
|
|
58
|
+
)
|
|
59
|
+
|
|
60
|
+
return [ordered]@{
|
|
61
|
+
hookSpecificOutput = [ordered]@{
|
|
62
|
+
hookEventName = 'PreToolUse'
|
|
63
|
+
permissionDecision = 'deny'
|
|
64
|
+
permissionDecisionReason = $Reason
|
|
65
|
+
}
|
|
66
|
+
}
|
|
67
|
+
}
|
|
68
|
+
|
|
69
|
+
function ConvertFrom-EpicInvocationOriginPayload {
|
|
70
|
+
<#
|
|
71
|
+
.SYNOPSIS
|
|
72
|
+
Parses a raw JSON payload string, returning $null for a blank payload
|
|
73
|
+
and throwing a named error for malformed JSON.
|
|
74
|
+
.PARAMETER RawPayload
|
|
75
|
+
The raw JSON text under evaluation.
|
|
76
|
+
.PARAMETER PayloadName
|
|
77
|
+
The payload's environment-variable name, used in the error message.
|
|
78
|
+
.OUTPUTS
|
|
79
|
+
System.Object or $null
|
|
80
|
+
#>
|
|
81
|
+
[CmdletBinding()]
|
|
82
|
+
param(
|
|
83
|
+
[AllowNull()]
|
|
84
|
+
[AllowEmptyString()]
|
|
85
|
+
[string] $RawPayload,
|
|
86
|
+
|
|
87
|
+
[Parameter(Mandatory)]
|
|
88
|
+
[string] $PayloadName
|
|
89
|
+
)
|
|
90
|
+
|
|
91
|
+
if ([string]::IsNullOrWhiteSpace($RawPayload)) {
|
|
92
|
+
return $null
|
|
93
|
+
}
|
|
94
|
+
|
|
95
|
+
try {
|
|
96
|
+
return $RawPayload | ConvertFrom-Json -ErrorAction Stop
|
|
97
|
+
} catch {
|
|
98
|
+
throw "enforce-epic-invocation-origin hook received malformed JSON in ${PayloadName}: $_"
|
|
99
|
+
}
|
|
100
|
+
}
|
|
101
|
+
|
|
102
|
+
function Get-EpicInvocationOriginTargetSubagent {
|
|
103
|
+
<#
|
|
104
|
+
.SYNOPSIS
|
|
105
|
+
Resolves the delegation target subagent_type from the tool input,
|
|
106
|
+
falling back to the full payload's tool_input object.
|
|
107
|
+
.PARAMETER ToolInput
|
|
108
|
+
Parsed CLAUDE_TOOL_INPUT object, or $null when absent.
|
|
109
|
+
.PARAMETER HookInput
|
|
110
|
+
Parsed CLAUDE_HOOK_INPUT object, or $null when absent.
|
|
111
|
+
.OUTPUTS
|
|
112
|
+
System.String or $null
|
|
113
|
+
#>
|
|
114
|
+
[CmdletBinding()]
|
|
115
|
+
[OutputType([string])]
|
|
116
|
+
param(
|
|
117
|
+
[AllowNull()]
|
|
118
|
+
$ToolInput,
|
|
119
|
+
|
|
120
|
+
[AllowNull()]
|
|
121
|
+
$HookInput
|
|
122
|
+
)
|
|
123
|
+
|
|
124
|
+
if ($null -ne $ToolInput -and
|
|
125
|
+
(@($ToolInput.PSObject.Properties.Name) -contains 'subagent_type') -and
|
|
126
|
+
-not [string]::IsNullOrWhiteSpace([string]$ToolInput.subagent_type)) {
|
|
127
|
+
return [string]$ToolInput.subagent_type
|
|
128
|
+
}
|
|
129
|
+
|
|
130
|
+
if ($null -ne $HookInput -and
|
|
131
|
+
(@($HookInput.PSObject.Properties.Name) -contains 'tool_input')) {
|
|
132
|
+
$nested = $HookInput.tool_input
|
|
133
|
+
if ($null -ne $nested -and
|
|
134
|
+
(@($nested.PSObject.Properties.Name) -contains 'subagent_type') -and
|
|
135
|
+
-not [string]::IsNullOrWhiteSpace([string]$nested.subagent_type)) {
|
|
136
|
+
return [string]$nested.subagent_type
|
|
137
|
+
}
|
|
138
|
+
}
|
|
139
|
+
|
|
140
|
+
return $null
|
|
141
|
+
}
|
|
142
|
+
|
|
143
|
+
function Get-EpicInvocationOriginCallerAgentType {
|
|
144
|
+
<#
|
|
145
|
+
.SYNOPSIS
|
|
146
|
+
Resolves the calling agent_type from the full hook payload. Returns
|
|
147
|
+
$null for a main-thread invocation (no agent_type field).
|
|
148
|
+
.PARAMETER HookInput
|
|
149
|
+
Parsed CLAUDE_HOOK_INPUT object, or $null when absent.
|
|
150
|
+
.OUTPUTS
|
|
151
|
+
System.String or $null
|
|
152
|
+
#>
|
|
153
|
+
[CmdletBinding()]
|
|
154
|
+
[OutputType([string])]
|
|
155
|
+
param(
|
|
156
|
+
[AllowNull()]
|
|
157
|
+
$HookInput
|
|
158
|
+
)
|
|
159
|
+
|
|
160
|
+
if ($null -eq $HookInput) {
|
|
161
|
+
return $null
|
|
162
|
+
}
|
|
163
|
+
if (@($HookInput.PSObject.Properties.Name) -notcontains 'agent_type') {
|
|
164
|
+
return $null
|
|
165
|
+
}
|
|
166
|
+
|
|
167
|
+
$agentType = [string]$HookInput.agent_type
|
|
168
|
+
if ([string]::IsNullOrWhiteSpace($agentType)) {
|
|
169
|
+
return $null
|
|
170
|
+
}
|
|
171
|
+
return $agentType
|
|
172
|
+
}
|
|
173
|
+
|
|
174
|
+
function Invoke-EpicInvocationOriginDecision {
|
|
175
|
+
<#
|
|
176
|
+
.SYNOPSIS
|
|
177
|
+
Parses the hook payloads and returns an allow-or-block decision.
|
|
178
|
+
.PARAMETER HookInputRaw
|
|
179
|
+
The raw full PreToolUse payload JSON supplied via CLAUDE_HOOK_INPUT.
|
|
180
|
+
.PARAMETER ToolInputRaw
|
|
181
|
+
The raw Agent tool input JSON supplied via CLAUDE_TOOL_INPUT.
|
|
182
|
+
.OUTPUTS
|
|
183
|
+
System.Collections.Specialized.OrderedDictionary
|
|
184
|
+
#>
|
|
185
|
+
[CmdletBinding()]
|
|
186
|
+
[OutputType([System.Collections.Specialized.OrderedDictionary])]
|
|
187
|
+
param(
|
|
188
|
+
[AllowNull()]
|
|
189
|
+
[AllowEmptyString()]
|
|
190
|
+
[string] $HookInputRaw,
|
|
191
|
+
|
|
192
|
+
[AllowNull()]
|
|
193
|
+
[AllowEmptyString()]
|
|
194
|
+
[string] $ToolInputRaw
|
|
195
|
+
)
|
|
196
|
+
|
|
197
|
+
# The tool input identifies the delegation target; a non-epic target is
|
|
198
|
+
# outside this hook's scope, so the hook input is not parsed for it.
|
|
199
|
+
$toolInput = ConvertFrom-EpicInvocationOriginPayload -RawPayload $ToolInputRaw -PayloadName 'CLAUDE_TOOL_INPUT'
|
|
200
|
+
$hookInputParsed = $false
|
|
201
|
+
$hookInput = $null
|
|
202
|
+
|
|
203
|
+
$target = Get-EpicInvocationOriginTargetSubagent -ToolInput $toolInput -HookInput $hookInput
|
|
204
|
+
if (-not $target -and -not [string]::IsNullOrWhiteSpace($HookInputRaw)) {
|
|
205
|
+
# Fallback: some harness surfaces supply only the full payload, whose
|
|
206
|
+
# tool_input object carries the target subagent_type.
|
|
207
|
+
$hookInput = ConvertFrom-EpicInvocationOriginPayload -RawPayload $HookInputRaw -PayloadName 'CLAUDE_HOOK_INPUT'
|
|
208
|
+
$hookInputParsed = $true
|
|
209
|
+
$target = Get-EpicInvocationOriginTargetSubagent -ToolInput $toolInput -HookInput $hookInput
|
|
210
|
+
}
|
|
211
|
+
|
|
212
|
+
if (-not $target -or $script:GatedSubagentTypes -notcontains $target) {
|
|
213
|
+
return Get-EpicInvocationOriginAllowDecision
|
|
214
|
+
}
|
|
215
|
+
|
|
216
|
+
if (-not $hookInputParsed) {
|
|
217
|
+
$hookInput = ConvertFrom-EpicInvocationOriginPayload -RawPayload $HookInputRaw -PayloadName 'CLAUDE_HOOK_INPUT'
|
|
218
|
+
}
|
|
219
|
+
|
|
220
|
+
# An absent agent_type marks a main-thread invocation, which is the
|
|
221
|
+
# intended entry point for both epic agents; only an orchestrator-context
|
|
222
|
+
# invocation is prohibited.
|
|
223
|
+
$caller = Get-EpicInvocationOriginCallerAgentType -HookInput $hookInput
|
|
224
|
+
if ($caller -ne $script:ProhibitedCallerAgentType) {
|
|
225
|
+
return Get-EpicInvocationOriginAllowDecision
|
|
226
|
+
}
|
|
227
|
+
|
|
228
|
+
$reason = "EPIC_INVOCATION_ORIGIN_BLOCKED: Agent($target) must not be invoked from an orchestrator agent. Both epic-planner and epic-orchestrator delegate to Agent(orchestrator), so an orchestrator-originated invocation would nest orchestrator inside its own delegation chain. Invoke $target from the main session instead."
|
|
229
|
+
return Get-EpicInvocationOriginBlockDecision -Reason $reason
|
|
230
|
+
}
|
|
231
|
+
|
|
232
|
+
# Guard allows dot-sourcing in tests without executing the entrypoint.
|
|
233
|
+
if ($MyInvocation.InvocationName -eq '.') {
|
|
234
|
+
return
|
|
235
|
+
}
|
|
236
|
+
|
|
237
|
+
try {
|
|
238
|
+
$decision = Invoke-EpicInvocationOriginDecision -HookInputRaw $env:CLAUDE_HOOK_INPUT -ToolInputRaw $env:CLAUDE_TOOL_INPUT
|
|
239
|
+
} catch {
|
|
240
|
+
Write-Error $_
|
|
241
|
+
exit 1
|
|
242
|
+
}
|
|
243
|
+
|
|
244
|
+
$decision | ConvertTo-Json -Compress -Depth 5 | Write-Output
|
|
245
|
+
|
|
246
|
+
exit 0
|
|
@@ -1,6 +1,5 @@
|
|
|
1
1
|
{
|
|
2
2
|
"$schema": "https://json.schemastore.org/claude-code-settings.json",
|
|
3
|
-
"agent": "orchestrator",
|
|
4
3
|
"permissions": {
|
|
5
4
|
"allow": [
|
|
6
5
|
"Bash(git *)",
|
|
@@ -39,7 +38,11 @@
|
|
|
39
38
|
"Agent(csharp-typed-engineer)",
|
|
40
39
|
"Agent(typescript-engineer)",
|
|
41
40
|
"Agent(epic-orchestrator)",
|
|
41
|
+
"Agent(epic-planner)",
|
|
42
42
|
"Skill(orchestrate *)",
|
|
43
|
+
"Skill(epic-plan *)",
|
|
44
|
+
"Skill(epic-orchestrate *)",
|
|
45
|
+
"Skill(epic-run *)",
|
|
43
46
|
"Skill(commit-message *)",
|
|
44
47
|
"Skill(pr-author *)",
|
|
45
48
|
"Skill(research-issue *)",
|
|
@@ -173,13 +176,17 @@
|
|
|
173
176
|
{
|
|
174
177
|
"type": "command",
|
|
175
178
|
"command": "pwsh -NoProfile -File .claude/hooks/enforce-model-routing-receipt.ps1"
|
|
179
|
+
},
|
|
180
|
+
{
|
|
181
|
+
"type": "command",
|
|
182
|
+
"command": "pwsh -NoProfile -File .claude/hooks/enforce-epic-invocation-origin.ps1"
|
|
176
183
|
}
|
|
177
184
|
]
|
|
178
185
|
}
|
|
179
186
|
],
|
|
180
187
|
"SubagentStop": [
|
|
181
188
|
{
|
|
182
|
-
"matcher": "atomic-planner|atomic-executor|feature-review|task-researcher|prd-feature|staged-review|epic-review|status-updater|python-typed-engineer|powershell-typed-engineer|csharp-typed-engineer|typescript-engineer|orchestrator|epic-orchestrator",
|
|
189
|
+
"matcher": "atomic-planner|atomic-executor|feature-review|task-researcher|prd-feature|staged-review|epic-review|status-updater|python-typed-engineer|powershell-typed-engineer|csharp-typed-engineer|typescript-engineer|orchestrator|epic-orchestrator|epic-planner",
|
|
183
190
|
"hooks": [
|
|
184
191
|
{
|
|
185
192
|
"type": "command",
|
|
@@ -2,10 +2,17 @@
|
|
|
2
2
|
name: epic-orchestrate
|
|
3
3
|
description: Route a multi-feature epic through the deterministic wave-scheduling, integration-branch, and fan-in workflow for the epic-orchestrator agent.
|
|
4
4
|
argument-hint: "[epic-manifest-path]"
|
|
5
|
+
context: fork
|
|
6
|
+
agent: epic-orchestrator
|
|
5
7
|
---
|
|
6
8
|
|
|
7
9
|
# Epic Orchestrate Skill
|
|
8
10
|
|
|
11
|
+
A user invocation (`/epic-orchestrate <epic-manifest-path>`) forks the `epic-orchestrator`
|
|
12
|
+
agent with this procedure in context. The epic manifest path (or epic slug) for this run is:
|
|
13
|
+
|
|
14
|
+
$ARGUMENTS
|
|
15
|
+
|
|
9
16
|
This skill frames work for the `epic-orchestrator` agent, parallel to how
|
|
10
17
|
`.claude/skills/orchestrate/SKILL.md` frames work for `orchestrator`. It documents the epic
|
|
11
18
|
checkpoint handling, wave computation, integration-branch lifecycle, wave barrier,
|
|
@@ -0,0 +1,189 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: epic-plan
|
|
3
|
+
description: Scope and prepare a multi-feature epic end-to-end before execution for the epic-planner agent - epic-worthiness gate, decomposition, dependency-wave design, complexity assessment, preparation-mode child orchestrator delegations, integration-branch fan-in, and the epic-orchestrator kickoff prompt artifact.
|
|
4
|
+
argument-hint: "[epic objective or epic-manifest-path]"
|
|
5
|
+
context: fork
|
|
6
|
+
agent: epic-planner
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Epic Plan Skill
|
|
10
|
+
|
|
11
|
+
A user invocation (`/epic-plan <objective>`) forks the `epic-planner` agent with this procedure
|
|
12
|
+
in context. The epic objective (or an existing epic-manifest path) for this run is:
|
|
13
|
+
|
|
14
|
+
$ARGUMENTS
|
|
15
|
+
|
|
16
|
+
This skill frames work for the `epic-planner` agent, parallel to how
|
|
17
|
+
`.claude/skills/epic-orchestrate/SKILL.md` frames work for `epic-orchestrator`. It documents the
|
|
18
|
+
epic-worthiness gate, decomposition and wave design, per-feature complexity assessment, the
|
|
19
|
+
preparation-mode child delegation contract, integration-branch fan-in, the kickoff-prompt
|
|
20
|
+
artifact, and planning-checkpoint handling so the procedure is not re-derived ad hoc on each
|
|
21
|
+
planning run. Planning ends at preflight clearance; no atomic execution, PR authoring, or CI
|
|
22
|
+
monitoring occurs under this skill.
|
|
23
|
+
|
|
24
|
+
## Prerequisites
|
|
25
|
+
|
|
26
|
+
Before proceeding, `epic-planner` must:
|
|
27
|
+
|
|
28
|
+
1. Read `CLAUDE.md` for repository tone policy and architectural context.
|
|
29
|
+
2. Read applicable `.claude/rules/` files for the languages in scope.
|
|
30
|
+
3. Read the policy files listed in the compliance reading order section of `CLAUDE.md`.
|
|
31
|
+
|
|
32
|
+
## Epic-Worthiness Gate
|
|
33
|
+
|
|
34
|
+
The first planning step is a deterministic assessment of whether the objective warrants an epic:
|
|
35
|
+
|
|
36
|
+
- Decompose the objective into candidate child features, each independently mergeable with its
|
|
37
|
+
own issue, feature folder, and PR.
|
|
38
|
+
- The objective warrants an epic only when BOTH hold:
|
|
39
|
+
1. The decomposition yields two or more child features, and
|
|
40
|
+
2. At least one candidate feature exceeds — or the combined scope clearly exceeds — a single
|
|
41
|
+
large-path feature's practical change budget.
|
|
42
|
+
|
|
43
|
+
When the gate fails, `epic-planner` reports to the user that the complexity does not warrant an
|
|
44
|
+
epic, states the rationale (feature count and estimated change budget), and offers to delegate
|
|
45
|
+
the work directly to a single `Agent(orchestrator)` run as one feature. It records the verdict
|
|
46
|
+
under `epic_worthiness` in the planning checkpoint and proceeds with epic scaffolding only when
|
|
47
|
+
the gate passes or the user explicitly directs it to.
|
|
48
|
+
|
|
49
|
+
## Decomposition and Wave Design
|
|
50
|
+
|
|
51
|
+
For an epic-worthy objective:
|
|
52
|
+
|
|
53
|
+
1. Define the epic slug and epic home `docs/features/epics/<epic-slug>/`.
|
|
54
|
+
2. Author `docs/features/epics/<epic-slug>/epic.md` using the manifest frontmatter schema
|
|
55
|
+
defined in the `epic-orchestrate` skill (that skill is the single schema authority; do not
|
|
56
|
+
redefine it here). The Markdown body carries the epic narrative: goal, scope, non-goals,
|
|
57
|
+
shared design, and decomposition rationale.
|
|
58
|
+
3. Derive `depends_on` edges from real upstream/downstream contracts only; do not add ordering
|
|
59
|
+
edges for stylistic reasons, because every edge reduces execution parallelism.
|
|
60
|
+
4. Compute wave assignment with the longest-path layering formula from the `epic-orchestrate`
|
|
61
|
+
skill (`scripts/dev_tools/epic_wave_computation.py` is the tested reference implementation)
|
|
62
|
+
and reject cycles or unresolved references before any preparation is delegated.
|
|
63
|
+
5. Record the planned waves in the planning checkpoint and in the epic narrative.
|
|
64
|
+
|
|
65
|
+
At manifest-authoring time child issues do not exist yet, so `issue_num` values are recorded as
|
|
66
|
+
placeholders and back-filled from each child's promotion receipt as preparation completes. The
|
|
67
|
+
manifest is committed in final, resolved form before the kickoff artifact is written.
|
|
68
|
+
|
|
69
|
+
## Complexity Assessment
|
|
70
|
+
|
|
71
|
+
Assess each child feature's complexity band (`C1`-`C4`) using the `model_policy` scale and
|
|
72
|
+
signals in `config/orchestration-routing.json`, and record the band with a short rationale in
|
|
73
|
+
the planning checkpoint's `features[]` entries and in the epic narrative. The bands serve two
|
|
74
|
+
purposes: they feed the epic-worthiness rationale, and they give each child orchestrator's own
|
|
75
|
+
model-selection step a reviewed starting assessment.
|
|
76
|
+
|
|
77
|
+
## Integration Branch Lifecycle
|
|
78
|
+
|
|
79
|
+
1. Before any preparation delegation, create the integration branch off the tip of `main` if it
|
|
80
|
+
does not already exist: `git fetch origin main`,
|
|
81
|
+
`git checkout -b epic/<epic-slug>-integration origin/main`,
|
|
82
|
+
`git push -u origin epic/<epic-slug>-integration`.
|
|
83
|
+
2. Commit the epic home (`epic.md`) to the integration branch before delegating preparation.
|
|
84
|
+
3. All prepared child outputs fan in to the integration branch (see Fan-In below), so the
|
|
85
|
+
branch's final state is the complete, execution-ready epic plan.
|
|
86
|
+
|
|
87
|
+
## Preparation-Mode Child Delegation
|
|
88
|
+
|
|
89
|
+
Delegate one `Agent(orchestrator)` run per child feature. Because preparation produces documents
|
|
90
|
+
and plans rather than code, dependency edges impose no build-order constraint: launch ALL child
|
|
91
|
+
preparations concurrently (one message, N `Agent` calls, each `isolation: "worktree"` and
|
|
92
|
+
`run_in_background: true`), branching each worktree from `origin/epic/<epic-slug>-integration`.
|
|
93
|
+
For a dependent feature, include the upstream features' planned scope (spec/plan references or
|
|
94
|
+
manifest excerpts) as context lines so its spec and plan cite the upstream contracts they will
|
|
95
|
+
consume.
|
|
96
|
+
|
|
97
|
+
Each delegation prompt includes the literal preparation-mode kickoff line:
|
|
98
|
+
|
|
99
|
+
> `Preparation mode: true. route_id: preparation. epic_feature_folder: <epic-slug>. integration_branch: epic/<epic-slug>-integration. Perform promotion, research, feature documents (spec.md, user-story.md), atomic planning, and preflight clearance only. Atomic execution, PR authoring, and CI monitoring are out of scope for this run and are executed later by epic-orchestrator. After the atomic-executor preflight returns PREFLIGHT: ALL CLEAR, commit the feature folder and plan to the current branch, set out-of-scope step statuses to not-applicable, set next_step to S5_atomic_execution, and stop, reporting the plan-path and preflight status.`
|
|
100
|
+
|
|
101
|
+
The prompt must also reference the child's target feature folder path once promotion assigns it,
|
|
102
|
+
or the promotion inputs (potential entry path, short name) when it does not exist yet. The
|
|
103
|
+
preparation-mode kickoff line deliberately omits the epic-mode marker (`Epic mode: true`) so the
|
|
104
|
+
`enforce-epic-wave-barrier.ps1` deterrent, which gates execution-phase delegations, does not
|
|
105
|
+
apply to preparation.
|
|
106
|
+
|
|
107
|
+
### Child run contract (route_id: preparation)
|
|
108
|
+
|
|
109
|
+
A preparation-mode `orchestrator` run:
|
|
110
|
+
|
|
111
|
+
- Selects `route_id: preparation` (defined in `config/orchestration-routing.json`), whose
|
|
112
|
+
required receipts are `task-researcher`, `prd-feature`, `atomic-planner`, and
|
|
113
|
+
`atomic-executor` (preflight-only), the skills `orchestrate`,
|
|
114
|
+
`feature-promotion-lifecycle`, and `atomic-plan-contract`, and the promotion plus validator
|
|
115
|
+
MCP tools.
|
|
116
|
+
- Runs promotion via the MCP surface, research, feature documents, atomic planning, and the
|
|
117
|
+
atomic-executor preflight (precondition validation only, per the orchestrate skill's R2
|
|
118
|
+
semantics), iterating plan revisions until `PREFLIGHT: ALL CLEAR`.
|
|
119
|
+
- Terminates with `completed_steps` containing `S3_promotion` and `S4_atomic_planning`,
|
|
120
|
+
`next_step: "S5_atomic_execution"`, out-of-scope step statuses `not-applicable`, and
|
|
121
|
+
`blocked_reason: "none"`. The route's `requires_ci_gate: false` means the completion validator
|
|
122
|
+
demands no `ci_gate`/`pr_gate` evidence; the run must NOT assert `next_step: "complete"`.
|
|
123
|
+
|
|
124
|
+
## Fan-In to the Integration Branch
|
|
125
|
+
|
|
126
|
+
As each child preparation completes:
|
|
127
|
+
|
|
128
|
+
1. Fetch the child worktree's branch and merge it into `epic/<epic-slug>-integration`. Prepared
|
|
129
|
+
outputs live in disjoint `docs/features/active/<feature>/` trees, so conflicts indicate a
|
|
130
|
+
decomposition defect; on conflict, halt fan-in and record blocked state rather than resolving
|
|
131
|
+
ad hoc.
|
|
132
|
+
2. Back-fill the child's `issue_num` (and resolved `feature_folder`) into the epic manifest.
|
|
133
|
+
3. Update the planning checkpoint's `features[]` entry (`preparation_status`, `plan_path`,
|
|
134
|
+
`preflight_status`).
|
|
135
|
+
4. Remove the child worktree once its branch is merged.
|
|
136
|
+
|
|
137
|
+
After the final fan-in, push the integration branch.
|
|
138
|
+
|
|
139
|
+
## Kickoff Prompt Artifact
|
|
140
|
+
|
|
141
|
+
After all features are prepared and committed, write the epic-orchestrator kickoff prompt to
|
|
142
|
+
`artifacts/orchestration/epic-kickoff-<epic-slug>.md`, and commit a durable copy to
|
|
143
|
+
`docs/features/epics/<epic-slug>/epic-kickoff.md` (the `artifacts/` tree is gitignored; the
|
|
144
|
+
committed copy travels with the integration branch). The artifact contains:
|
|
145
|
+
|
|
146
|
+
```markdown
|
|
147
|
+
# Epic Kickoff: <epic-slug>
|
|
148
|
+
|
|
149
|
+
Planned by epic-planner on <iso8601>. All child features are prepared: issues promoted, active
|
|
150
|
+
folders created, research complete, spec/user-story written, atomic plans approved, preflight
|
|
151
|
+
ALL CLEAR. Planning state: artifacts/orchestration/epic-planner-state.json (branch:
|
|
152
|
+
epic/<epic-slug>-integration).
|
|
153
|
+
|
|
154
|
+
## Invocation Prompt
|
|
155
|
+
|
|
156
|
+
Run `/epic-run <epic-slug>` to execute this epic, or paste the prompt below.
|
|
157
|
+
|
|
158
|
+
Use the epic-orchestrator subagent to execute the prepared epic at
|
|
159
|
+
docs/features/epics/<epic-slug>/epic.md. The integration branch
|
|
160
|
+
epic/<epic-slug>-integration already contains every prepared feature folder and approved atomic
|
|
161
|
+
plan; child features resume at atomic execution from their committed plan-path rather than
|
|
162
|
+
re-planning. Execute per the epic-orchestrate skill: wave-scheduled child orchestrator runs in
|
|
163
|
+
isolated worktrees, merge-on-green fan-in to the integration branch, and the final
|
|
164
|
+
integration-to-main PR.
|
|
165
|
+
|
|
166
|
+
## Feature Summary
|
|
167
|
+
|
|
168
|
+
| issue_num | feature_folder | wave | complexity | plan-path |
|
|
169
|
+
| --- | --- | --- | --- | --- |
|
|
170
|
+
| ... | ... | ... | ... | ... |
|
|
171
|
+
```
|
|
172
|
+
|
|
173
|
+
The `## Invocation Prompt` section is the exact text the user replays (from the main session,
|
|
174
|
+
never from an `orchestrator` agent) to launch execution.
|
|
175
|
+
|
|
176
|
+
## Checkpoint Handling
|
|
177
|
+
|
|
178
|
+
Persist `artifacts/orchestration/epic-planner-state.json` after every completed step with the
|
|
179
|
+
fields listed in `.claude/agents/epic-planner.md` (`## Checkpoint Persistence`). On resume,
|
|
180
|
+
re-derive durable ground truth from `git branch`/`git worktree list --porcelain`, the epic
|
|
181
|
+
manifest, and the prepared feature folders; treat the checkpoint's `next_step` as the resume
|
|
182
|
+
pointer, not as a substitute for on-disk state.
|
|
183
|
+
|
|
184
|
+
## Completion Report
|
|
185
|
+
|
|
186
|
+
The final report to the user must include: the epic manifest path, one `plan-path:` line plus
|
|
187
|
+
preflight status per feature, the integration branch name, and the kickoff artifact paths. End
|
|
188
|
+
with the statement that execution has NOT started and will begin only when the user runs
|
|
189
|
+
`/epic-run <epic-slug>` or replays the kickoff prompt.
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: epic-run
|
|
3
|
+
description: Execute a previously planned epic by replaying the committed epic-kickoff artifact through the epic-orchestrator agent. Use after /epic-plan has prepared the epic (issues, folders, research, specs, atomic plans, preflight clearance) and the user is ready to execute end-to-end.
|
|
4
|
+
argument-hint: "[epic-slug]"
|
|
5
|
+
context: fork
|
|
6
|
+
agent: epic-orchestrator
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Epic Run Skill
|
|
10
|
+
|
|
11
|
+
A user invocation (`/epic-run <epic-slug>`) forks the `epic-orchestrator` agent to execute an
|
|
12
|
+
epic that `epic-planner` has already prepared. The epic slug (or a path under
|
|
13
|
+
`docs/features/epics/`) for this run is:
|
|
14
|
+
|
|
15
|
+
$ARGUMENTS
|
|
16
|
+
|
|
17
|
+
## Procedure
|
|
18
|
+
|
|
19
|
+
1. Resolve the epic home. A bare slug resolves to `docs/features/epics/<epic-slug>/`; a path
|
|
20
|
+
argument resolves to its containing epic folder.
|
|
21
|
+
2. Read the committed kickoff artifact at `docs/features/epics/<epic-slug>/epic-kickoff.md`.
|
|
22
|
+
- If the file does not exist, STOP without delegating anything and report that the epic has
|
|
23
|
+
no committed kickoff artifact: the user must run `/epic-plan` first (or, for an epic that
|
|
24
|
+
was authored manually, invoke `/epic-orchestrate <epic-manifest-path>` directly).
|
|
25
|
+
3. Execute the kickoff artifact's `## Invocation Prompt` section as the epic objective, applying
|
|
26
|
+
the `epic-orchestrate` skill procedure and the `## Prepared-Epic Execution (epic-planner
|
|
27
|
+
Handoff)` section of `.claude/agents/epic-orchestrator.md`: reuse the existing integration
|
|
28
|
+
branch, and have each child `Agent(orchestrator)` delegation resume at atomic execution from
|
|
29
|
+
its committed `plan-path` rather than re-running promotion, research, or planning.
|
|
30
|
+
4. Honor existing checkpoint state: if `artifacts/orchestration/epic-orchestrator-state.json`
|
|
31
|
+
already tracks this epic, resume per the `epic-orchestrate` skill's resume procedure instead
|
|
32
|
+
of restarting.
|
|
33
|
+
|
|
34
|
+
## Scope
|
|
35
|
+
|
|
36
|
+
This skill adds no procedure of its own beyond kickoff-artifact resolution; wave scheduling,
|
|
37
|
+
the wave barrier, merge-on-green fan-in, worktree cleanup, `epic-status.md` maintenance, and
|
|
38
|
+
the final integration-to-`main` PR are governed entirely by the `epic-orchestrate` skill.
|
|
@@ -6,7 +6,17 @@ argument-hint: "[objective]"
|
|
|
6
6
|
|
|
7
7
|
# Orchestrate Skill
|
|
8
8
|
|
|
9
|
-
This skill frames work for the already-active main session, which serves as the orchestrator runtime for end-to-end feature or bug delivery.
|
|
9
|
+
This skill frames work for the already-active main session, which serves as the orchestrator runtime for end-to-end feature or bug delivery. Orchestration deliberately stays in the main session on user invocation (`/orchestrate <objective>`); the same procedure governs a delegated `Agent(orchestrator)` run from `epic-planner` or `epic-orchestrator`.
|
|
10
|
+
|
|
11
|
+
## Invocation Argument
|
|
12
|
+
|
|
13
|
+
When invoked as `/orchestrate`, the orchestration objective is:
|
|
14
|
+
|
|
15
|
+
$ARGUMENTS
|
|
16
|
+
|
|
17
|
+
A delegated `Agent(orchestrator)` run receives its objective in the delegation prompt instead.
|
|
18
|
+
|
|
19
|
+
Perform the scale assessment first: if the objective is epic-scale (names an epic manifest or requires multiple independently mergeable features), stop before any delegation and direct the user to `/epic-plan` (planning) or `/epic-run` (executing a prepared epic), per `## Change Budget Routing` in `.claude/agents/orchestrator.md`.
|
|
10
20
|
|
|
11
21
|
## Prerequisites
|
|
12
22
|
|
|
@@ -77,9 +87,18 @@ After reading `artifacts/orchestration/orchestrator-state.json`, the main sessio
|
|
|
77
87
|
|
|
78
88
|
The orchestrator does not perform deep implementation itself. It coordinates, tracks state, and enforces completion.
|
|
79
89
|
|
|
90
|
+
## Preparation Mode
|
|
91
|
+
|
|
92
|
+
A delegation prompt carrying the literal marker `Preparation mode: true` (issued by `epic-planner` per the `.claude/skills/epic-plan/SKILL.md` kickoff line) scopes the run to planning only:
|
|
93
|
+
|
|
94
|
+
- **Route.** Select `route_id: preparation`. The route's routing-matrix entry requires receipts for `task-researcher`, `prd-feature`, `atomic-planner`, and `atomic-executor`; the skills `orchestrate`, `feature-promotion-lifecycle`, and `atomic-plan-contract`; and the promotion plus validator MCP tools.
|
|
95
|
+
- **Scope.** Run promotion (MCP surface), research, feature documents (`spec.md`, `user-story.md`), atomic planning, and the atomic-executor preflight (precondition validation only, R2 semantics: iterate plan revisions until `PREFLIGHT: ALL CLEAR`). Atomic execution, PR authoring, CI monitoring, and feature review are out of scope and are executed later by `epic-orchestrator`.
|
|
96
|
+
- **Terminal checkpoint.** Stop with `completed_steps` containing `S3_promotion` and `S4_atomic_planning`, `next_step: "S5_atomic_execution"`, out-of-scope step statuses set to `not-applicable`, and `blocked_reason: "none"`. Do NOT assert completion (`next_step: "complete"`, `S12_complete`, or a `completed` step8/9/10 status): the run has no PR or CI evidence, and the route's `requires_ci_gate: false` exempts it from `ci_gate` at the completion validator instead.
|
|
97
|
+
- **Commit.** Commit the prepared feature folder and plan to the current branch (the worktree branch created off the epic integration branch) before stopping, and report the `plan-path` and preflight status in the final output.
|
|
98
|
+
|
|
80
99
|
## Model Selection
|
|
81
100
|
|
|
82
|
-
Model selection is a second axis, strictly separate from `route`. `route` (`small | large | remediation | epic`) is deterministic
|
|
101
|
+
Model selection is a second axis, strictly separate from `route`. `route` (`small | large | remediation | preparation | epic`) is deterministic — file-count driven for `small`/`large`, marker-driven for `preparation` (the `Preparation mode: true` kickoff line) and `epic`; it governs `required_agents`, `required_skills`, and `required_mcp_tools` only. `route` is NOT an input to model selection anywhere. The sole feature-level input to the delegation model tier is a judgment-based `complexity_band` (`C1 | C2 | C3 | C4`). The authoritative values live in the `model_policy` block of `config/orchestration-routing.json`.
|
|
83
102
|
|
|
84
103
|
The two canonical, tested reference implementations express the formulas the orchestrator applies by judgment:
|
|
85
104
|
|
|
@@ -7,6 +7,7 @@
|
|
|
7
7
|
".claude/agents/atomic-planner.md",
|
|
8
8
|
".claude/agents/commit-message.md",
|
|
9
9
|
".claude/agents/epic-orchestrator.md",
|
|
10
|
+
".claude/agents/epic-planner.md",
|
|
10
11
|
".claude/agents/epic-review.md",
|
|
11
12
|
".claude/agents/feature-review.md",
|
|
12
13
|
".claude/agents/human-exception-runbook.md",
|
|
@@ -17,6 +18,7 @@
|
|
|
17
18
|
".claude/agents/task-researcher.md",
|
|
18
19
|
".claude/hooks/enforce-checkpoint-monotonic.ps1",
|
|
19
20
|
".claude/hooks/enforce-completion-consistency.ps1",
|
|
21
|
+
".claude/hooks/enforce-epic-invocation-origin.ps1",
|
|
20
22
|
".claude/hooks/enforce-epic-merge-gate.ps1",
|
|
21
23
|
".claude/hooks/enforce-epic-wave-barrier.ps1",
|
|
22
24
|
".claude/hooks/enforce-epic-worktree-removal-gate.ps1",
|
|
@@ -49,6 +51,8 @@
|
|
|
49
51
|
".claude/skills/atomic-plan-contract/SKILL.md",
|
|
50
52
|
".claude/skills/commit-message/SKILL.md",
|
|
51
53
|
".claude/skills/epic-orchestrate/SKILL.md",
|
|
54
|
+
".claude/skills/epic-plan/SKILL.md",
|
|
55
|
+
".claude/skills/epic-run/SKILL.md",
|
|
52
56
|
".claude/skills/evidence-and-timestamp-conventions/SKILL.md",
|
|
53
57
|
".claude/skills/execute-hard-lock/SKILL.md",
|
|
54
58
|
".claude/skills/feature-promotion-lifecycle/SKILL.md",
|
|
@@ -72,6 +72,27 @@
|
|
|
72
72
|
"validate_orchestration_artifacts"
|
|
73
73
|
]
|
|
74
74
|
},
|
|
75
|
+
"preparation": {
|
|
76
|
+
"description": "Epic preparation path driven by epic-planner: promotion, research, feature documents, atomic planning, and preflight clearance only. Atomic execution, PR authoring, and CI monitoring are out of scope and deferred to the epic execution phase, so this route requires no CI gate at completion.",
|
|
77
|
+
"requires_ci_gate": false,
|
|
78
|
+
"required_agents": [
|
|
79
|
+
"task-researcher",
|
|
80
|
+
"prd-feature",
|
|
81
|
+
"atomic-planner",
|
|
82
|
+
"atomic-executor"
|
|
83
|
+
],
|
|
84
|
+
"required_skills": [
|
|
85
|
+
"orchestrate",
|
|
86
|
+
"feature-promotion-lifecycle",
|
|
87
|
+
"atomic-plan-contract"
|
|
88
|
+
],
|
|
89
|
+
"required_mcp_tools": [
|
|
90
|
+
"new_potential_entry",
|
|
91
|
+
"potential_to_issue",
|
|
92
|
+
"new_active_feature_folder",
|
|
93
|
+
"validate_orchestration_artifacts"
|
|
94
|
+
]
|
|
95
|
+
},
|
|
75
96
|
"epic": {
|
|
76
97
|
"description": "Epic path for scheduling a dependency graph of child features across parallel worktrees with fan-in via a shared integration branch.",
|
|
77
98
|
"requires_pr_gate": true,
|