guild-agents 1.4.0 → 1.5.0

package/README.md

@@ -58,7 +58,7 @@ You ──> /council "Add JWT auth"
                                    └──────────┘└──────────┘
 ```
 
-Six phases: **evaluate**, **specify**, **plan**, **implement**, **review**, **validate**. Phases 1-3 happen before any code is written.
+Five phases: **evaluate**, **design**, **implement**, **review**, **validate**. Phases 1-2 happen before any code is written.
 
 ## Skills Reference
 
@@ -116,19 +116,16 @@ Every trigger run automatically records results to `benchmarks/benchmark.json` (
 
 ## Under the Hood
 
-Guild coordinates 10 specialized agents through the pipeline. Each agent handles one phase.
+Guild coordinates 7 specialized agents through the pipeline. Each agent handles one phase.
 
 | Agent | Role |
 | --- | --- |
 | advisor | Evaluates ideas and provides strategic direction |
-| product-owner | Turns approved ideas into concrete tasks |
-| tech-lead | Defines technical approach and architecture |
+| tech-lead | Defines technical approach, tasks, and architecture |
 | developer | Implements features following project conventions |
 | code-reviewer | Reviews quality, patterns, and technical debt |
 | qa | Testing, edge cases, regression validation |
 | bugfix | Bug diagnosis and resolution |
-| db-migration | Schema changes and safe migrations |
-| platform-expert | Diagnoses Claude Code integration issues |
 | learnings-extractor | Extracts compound learnings from pipeline executions |
 
 Agents are flat `.md` files with identity and expertise. Skills orchestrate agents through structured pipelines. Everything lives in `.claude/`, readable by humans, tracked by git.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "guild-agents",
-  "version": "1.4.0",
+  "version": "1.5.0",
   "description": "Specification-driven development CLI for Claude Code — think before you build",
   "type": "module",
   "files": [
@@ -73,7 +73,7 @@
     "@eslint/js": "^10.0.1",
     "@vitest/coverage-v8": "^4.0.18",
     "eslint": "^10.0.1",
-    "markdownlint-cli2": "^0.21.0",
+    "markdownlint-cli2": "^0.22.1",
     "vitest": "^4.0.18"
   }
 }

package/src/templates/agents/advisor.md

@@ -21,7 +21,6 @@ You are the domain guardian of [PROJECT]. Your job is to evaluate ideas and prop
 ## What you do NOT do
 
 - You do not define architecture or technical approach -- that is the Tech Lead's role
-- You do not prioritize the backlog or write acceptance criteria -- that is the Product Owner's role
 - You do not review code -- that is the Code Reviewer's role
 - You do not implement anything -- that is the Developer's role
 

package/src/templates/agents/developer.md

@@ -8,7 +8,7 @@ default-tier: execution
 
 # Developer
 
-You are the Developer for [PROJECT]. Your job is to implement features and changes following the project conventions, the approach defined by the Tech Lead, and the acceptance criteria from the Product Owner.
+You are the Developer for [PROJECT]. Your job is to implement features and changes following the project conventions, the approach defined by the Tech Lead, and the acceptance criteria.
 
 ## Responsibilities
 
@@ -22,7 +22,7 @@ You are the Developer for [PROJECT]. Your job is to implement features and chang
 
 - You do not define architecture or technical approach -- that is the Tech Lead's role
 - You do not validate the result functionally -- that is QA's role
-- You do not prioritize or decide what to implement -- that is the Product Owner's role
+- You do not prioritize or decide what to implement -- that is the Advisor's role
 - You do not investigate production bugs -- that is Bugfix's role
 
 ## Process

package/src/templates/agents/qa.md

@@ -22,7 +22,7 @@ You are QA for [PROJECT]. Your job is to functionally validate that the implemen
 
 - You do not fix bugs -- that is Bugfix's role
 - You do not write unit tests -- that is the Developer's role
-- You do not define acceptance criteria -- that is the Product Owner's role
+- You do not define acceptance criteria -- that is the Tech Lead's role
 - You do not implement features -- that is the Developer's role
 
 ## Process

package/src/templates/agents/tech-lead.md

@@ -15,7 +15,7 @@ You are the Tech Lead for [PROJECT]. Your job is to ensure the technical coheren
 - Define the technical approach for each task before implementation
 - Establish patterns, interfaces, and contracts between components
 - Identify technical risks and propose mitigations
-- Enrich Product Owner tasks with concrete technical direction
+- Break features into concrete tasks with verifiable acceptance criteria
 - Maintain the project's architectural coherence over time
 
 ## What you do NOT do
@@ -23,7 +23,7 @@ You are the Tech Lead for [PROJECT]. Your job is to ensure the technical coheren
 - You do not implement code -- that is the Developer's role
 - You do not validate functional behavior -- that is QA's role
 - You do not evaluate business coherence -- that is the Advisor's role
-- You do not prioritize the backlog -- that is the Product Owner's role
+- You do not evaluate business coherence or prioritize the backlog -- that is the Advisor's role
 
 ## Process
 

package/src/templates/skills/build-feature/SKILL.md

@@ -12,19 +12,13 @@ workflow:
       produces: [evaluation-report, verdict]
       model-tier: reasoning
       on-failure: abort
-    - id: specify
-      role: product-owner
-      intent: "Break the feature into concrete tasks with verifiable acceptance criteria. Estimate effort and suggest implementation order."
-      requires: [feature-description, evaluation-report]
-      produces: [task-list, acceptance-criteria]
-      model-tier: reasoning
-      condition: step.evaluate.verdict != rejected
     - id: design
       role: tech-lead
-      intent: "Define implementation approach: files to modify, patterns to follow, interfaces, and technical risks."
-      requires: [task-list, acceptance-criteria]
-      produces: [technical-plan]
+      intent: "Break the feature into concrete tasks with acceptance criteria. Define implementation approach: files to modify, patterns to follow, interfaces, and technical risks."
+      requires: [feature-description, evaluation-report]
+      produces: [task-list, acceptance-criteria, technical-plan]
       model-tier: reasoning
+      condition: step.evaluate.verdict != rejected
     - id: implement
       role: developer
       intent: "Implement the feature following the technical plan. Write unit tests. Make atomic commits."
@@ -131,19 +125,18 @@ git worktree remove .claude/worktrees/[branch-name]
 
 When running a single build-feature, a simple `git checkout -b` is sufficient.
 
-## 6-Phase Pipeline
+## 5-Phase Pipeline
 
 ### Progress Display
 
 At the start of each phase, display a progress indicator to the user before any agent output:
 
 ```text
-[1/6] Advisor (opus) — Evaluating feature...
-[2/6] Product Owner (opus) — Defining spec...
-[3/6] Tech Lead (opus) — Defining technical approach...
-[4/6] Developer (sonnet) — Implementing...
-[5/6] Code Reviewer (opus) — Reviewing changes...
-[6/6] QA (sonnet) — Validating acceptance criteria...
+[1/5] Advisor (opus) — Evaluating feature...
+[2/5] Tech Lead (opus) — Defining spec and technical approach...
+[3/5] Developer (sonnet) — Implementing...
+[4/5] Code Reviewer (opus) — Reviewing changes...
+[5/5] QA (sonnet) — Validating acceptance criteria...
 ```
 
 Model names are resolved from the step's `model-tier` using the `max` profile: reasoning=opus, execution=sonnet, routine=haiku. System/gate steps do not show a model name.
@@ -151,15 +144,15 @@ Model names are resolved from the step's `model-tier` using the `max` profile: r
 When a phase loops (review-fix or QA-review cycles), show the iteration:
 
 ```text
-[5/6 · round 2] Code Reviewer (opus) — Re-reviewing after fixes...
-[4/6 · round 2] Developer (sonnet) — Fixing review blockers...
+[4/5 · round 2] Code Reviewer (opus) — Re-reviewing after fixes...
+[3/5 · round 2] Developer (sonnet) — Fixing review blockers...
 ```
 
 This indicator MUST be displayed before spawning the agent for that phase.
 
 ### Phase 1 — Evaluation (Advisor)
 
-**Progress:** `[1/6] Advisor (opus) — Evaluating feature...`
+**Progress:** `[1/5] Advisor (opus) — Evaluating feature...`
 **Agent:** Reads `.claude/agents/advisor.md` via Task tool with `model: "opus"`
 **Input:** The feature description provided by the user
 **Process:**
@@ -172,39 +165,26 @@ This indicator MUST be displayed before spawning the agent for that phase.
 **Trace data:** Verdict (Approved/Rejected/Approved with conditions), risks identified, conditions if any
 **Exit condition:** If the Advisor rejects the feature, the pipeline stops here. Inform the user of the reason and suggest adjustments if any.
 
-### Phase 2 — Specification (Product Owner)
-
-**Progress:** `[2/6] Product Owner (opus) — Defining spec...`
-**Agent:** Reads `.claude/agents/product-owner.md` via Task tool with `model: "opus"`
-**Input:** The feature approved by the Advisor + their observations
-**Process:**
-
-1. The Product Owner breaks the feature into concrete tasks
-2. Defines verifiable acceptance criteria for each task
-3. Estimates effort and suggests implementation order
+### Phase 2 — Specification & Technical Approach (Tech Lead)
 
-**Output:** Task list with acceptance criteria, estimation, and order
-**Trace data:** Tasks defined count, acceptance criteria count, estimated effort
-
-### Phase 3 — Technical Approach (Tech Lead)
-
-**Progress:** `[3/6] Tech Lead (opus) — Defining technical approach...`
+**Progress:** `[2/5] Tech Lead (opus) — Defining spec and technical approach...`
 **Agent:** Reads `.claude/agents/tech-lead.md` via Task tool with `model: "opus"`
-**Input:** Product Owner tasks + acceptance criteria
+**Input:** The feature approved by the Advisor + their observations
 **Process:**
 
-1. The Tech Lead defines the implementation approach
-2. Identifies files to modify, patterns to follow, interfaces
+1. The Tech Lead breaks the feature into concrete tasks with verifiable acceptance criteria
+2. Defines the implementation approach: files to modify, patterns to follow, interfaces
 3. Anticipates technical risks and proposes mitigations
+4. Estimates effort and suggests implementation order
 
-**Output:** Technical plan with files, patterns, interfaces, and risks
-**Trace data:** Key patterns identified, files to modify, technical risks
+**Output:** Task list with acceptance criteria + technical plan with files, patterns, interfaces, and risks
+**Trace data:** Tasks defined count, acceptance criteria count, key patterns identified, files to modify, technical risks
 
-### Phase 4 — Implementation (Developer)
+### Phase 3 — Implementation (Developer)
 
-**Progress:** `[4/6] Developer (sonnet) — Implementing...`
+**Progress:** `[3/5] Developer (sonnet) — Implementing...`
 **Agent:** Reads `.claude/agents/developer.md` via Task tool with `model: "sonnet"`
-**Input:** Tech Lead technical plan + PO acceptance criteria
+**Input:** Tech Lead technical plan + acceptance criteria
 **Process:**
 
 1. The Developer implements following the technical plan
@@ -217,7 +197,7 @@ This indicator MUST be displayed before spawning the agent for that phase.
 
 ### Pre-Review Gate (mandatory)
 
-Before advancing to Phase 5, run automated verification:
+Before advancing to Phase 4, run automated verification:
 
 1. Run the project test commands (e.g., `npm test`) — if it fails, the Developer must fix before advancing
 2. Run the project lint commands (e.g., `npm run lint`) — if it fails, the Developer must fix before advancing
@@ -227,9 +207,9 @@ This gate CANNOT be skipped, even if the user requested phase skipping. The spec
 
 **Trace data:** Tests pass/fail, lint pass/fail
 
-### Phase 5 — Review (Code Reviewer)
+### Phase 4 — Review (Code Reviewer)
 
-**Progress:** `[5/6] Code Reviewer (opus) — Reviewing changes...`
+**Progress:** `[4/5] Code Reviewer (opus) — Reviewing changes...`
 **Agent:** Reads `.claude/agents/code-reviewer.md` via Task tool with `model: "opus"`
 **Input:** The implemented changes (git diff)
 **Process:**
@@ -239,13 +219,13 @@ This gate CANNOT be skipped, even if the user requested phase skipping. The spec
 
 **Output:** Review report with classified findings
 **Trace data:** Blockers count, warnings count, suggestions count, review-fix loops
-**Loop condition:** If there are Blocker findings, return to **Phase 4** for the Developer to fix them. Maximum 2 review-fix iterations.
+**Loop condition:** If there are Blocker findings, return to **Phase 3** for the Developer to fix them. Maximum 2 review-fix iterations.
 
-### Phase 6 — QA (delegates to /qa-cycle)
+### Phase 5 — QA (delegates to /qa-cycle)
 
-**Progress:** `[6/6] QA (sonnet) — Validating acceptance criteria...`
+**Progress:** `[5/5] QA (sonnet) — Validating acceptance criteria...`
 
-Runs the `/qa-cycle` skill passing the PO acceptance criteria as context. The qa-cycle handles:
+Runs the `/qa-cycle` skill passing the acceptance criteria as context. The qa-cycle handles:
 
 1. Running project tests and lint
 2. Validating acceptance criteria
@@ -253,7 +233,7 @@ Runs the `/qa-cycle` skill passing the PO acceptance criteria as context. The qa
 4. Bugfix cycle if issues arise (maximum 3 cycles)
 
 **Trace data:** Acceptance criteria verified count, bugs found, QA cycles
-**Additional loop condition:** If the qa-cycle bugfix introduces significant changes, return to **Phase 5** (Review) for verification. Maximum 2 review-QA cycles.
+**Additional loop condition:** If the qa-cycle bugfix introduces significant changes, return to **Phase 4** (Review) for verification. Maximum 2 review-QA cycles.
 
 ## Checkpoint Commits
 
@@ -267,11 +247,10 @@ git commit -m "wip: [feature-name] phase N complete — [phase-name]"
 Pattern for each phase:
 
 - After Phase 1: `wip: [feature] phase 1 — advisor approved`
-- After Phase 2: `wip: [feature] phase 2 — PO spec ready`
-- After Phase 3: `wip: [feature] phase 3 — tech approach defined`
-- After Phase 4: `wip: [feature] phase 4 — implementation done` -- also write partial trace (phases 1-4) to spec and update status to `implementing`
-- After Phase 5: `wip: [feature] phase 5 — review passed`
-- After Phase 6: `wip: [feature] phase 6 — QA passed`
+- After Phase 2: `wip: [feature] phase 2 — spec and tech approach defined`
+- After Phase 3: `wip: [feature] phase 3 — implementation done` -- also write partial trace (phases 1-3) to spec and update status to `implementing`
+- After Phase 4: `wip: [feature] phase 4 — review passed`
+- After Phase 5: `wip: [feature] phase 5 — QA passed`
 
 Also update SESSION.md at each phase transition:
 
@@ -325,7 +304,7 @@ Append this section to the spec file:
 
 pipeline-start: [YYYY-MM-DD]
 pipeline-end: [YYYY-MM-DD]
-phases-completed: [N]/6
+phases-completed: [N]/5
 review-fix-loops: [N]
 qa-cycles: [N]
 final-gate: pass | fail
@@ -335,19 +314,16 @@ final-gate: pass | fail
 - **Verdict**: [Approved/Rejected/Approved with conditions]
 - **Risks identified**: [list or "None"]
 
-### Phase 2 — Specification
+### Phase 2 — Specification & Technical Approach
 
 - **Tasks defined**: [N]
 - **Acceptance criteria**: [N]
-- **Estimated effort**: [summary]
-
-### Phase 3 — Technical Approach
-
 - **Key patterns**: [list]
 - **Files to modify**: [list]
 - **Technical risks**: [list or "None"]
+- **Estimated effort**: [summary]
 
-### Phase 4 — Implementation
+### Phase 3 — Implementation
 
 - **Files created/modified**: [list]
 - **Tests added**: [N]
@@ -358,14 +334,14 @@ final-gate: pass | fail
 - **Tests**: pass | fail
 - **Lint**: pass | fail
 
-### Phase 5 — Review
+### Phase 4 — Review
 
 - **Blockers**: [N]
 - **Warnings**: [N]
 - **Suggestions**: [N]
 - **Review-fix loops**: [N]
 
-### Phase 6 — QA
+### Phase 5 — QA
 
 - **Acceptance criteria verified**: [N]/[total]
 - **Bugs found**: [N]
@@ -380,15 +356,15 @@ final-gate: pass | fail
 
 ### When to write the trace
 
-- **Phase 4 checkpoint:** Write a partial trace covering phases 1-4 to the spec file. Set status to `implementing`. Include the spec file in the checkpoint commit.
+- **Phase 3 checkpoint:** Write a partial trace covering phases 1-3 to the spec file. Set status to `implementing`. Include the spec file in the checkpoint commit.
 - **Pipeline completion:** Write the complete trace (all phases) to the spec file. Set status to `implemented`. Include the spec file in the final checkpoint commit.
 
 ## Final Gate (mandatory before Completion)
 
 Before declaring the pipeline as complete, run final verification:
 
-1. Run project tests — if it fails, return to Phase 6 (QA/Bugfix)
-2. Run project lint — if it fails, return to Phase 4 (Developer)
+1. Run project tests — if it fails, return to Phase 5 (QA/Bugfix)
+2. Run project lint — if it fails, return to Phase 3 (Developer)
 3. Both must pass with exit code 0
 
 This gate is the last safety net. It CANNOT be skipped under any circumstances.
@@ -423,7 +399,7 @@ When spawning agents via the Task tool, use these `subagent_type` values:
 
 | Guild Agent Role | subagent_type to use |
 | --- | --- |
-| advisor, product-owner, tech-lead | `"general-purpose"` |
+| advisor, tech-lead | `"general-purpose"` |
 | developer, bugfix | `"general-purpose"` |
 | code-reviewer, qa | `"general-purpose"` |
 
@@ -445,22 +421,19 @@ The `model` parameter is resolved from the step's `model-tier`: reasoning→`"op
 ```text
 User: /build-feature add dark mode toggle to settings page
 
-[1/6] Advisor (opus) — Evaluating feature...
+[1/5] Advisor (opus) — Evaluating feature...
   Approved. Low risk, aligns with UX roadmap.
 
-[2/6] Product Owner (opus) — Defining spec...
-  3 tasks defined with acceptance criteria.
-
-[3/6] Tech Lead (opus) — Defining technical approach...
-  Use CSS variables + context provider pattern.
+[2/5] Tech Lead (opus) — Defining spec and technical approach...
+  3 tasks defined. Use CSS variables + context provider pattern.
 
-[4/6] Developer (sonnet) — Implementing...
+[3/5] Developer (sonnet) — Implementing...
   Implemented ThemeContext, toggle component, CSS vars.
 
-[5/6] Code Reviewer (opus) — Reviewing changes...
+[4/5] Code Reviewer (opus) — Reviewing changes...
   Passed. 1 suggestion (memoize context value).
 
-[6/6] QA (sonnet) — Validating acceptance criteria...
+[5/5] QA (sonnet) — Validating acceptance criteria...
   All 3 acceptance criteria verified. 0 bugs.
 
 Feature complete. PR ready for merge.
@@ -468,7 +441,7 @@ Feature complete. PR ready for merge.
 
 ## Notes
 
-- If the user wants to skip phases (e.g., "already evaluated, implement directly"), allow skipping to Phase 4 but warn that validation is lost. Verification gates (pre-Review and final) are NEVER skipped
+- If the user wants to skip phases (e.g., "already evaluated, implement directly"), allow skipping to Phase 3 but warn that validation is lost. Verification gates (pre-Review and final) are NEVER skipped
 - The pipeline is sequential: each phase depends on the output of the previous one
 - Review/QA loops have limits to prevent infinite cycles
 - In v1.x, parallel pipeline execution (multiple build-features via worktrees) is best-effort and depends on the host environment supporting concurrent agents

package/src/templates/skills/build-feature/evals/evals.json

@@ -3,10 +3,9 @@
   "evals": [
     {
       "id": "bf-has-core-phases",
-      "description": "Plan contains evaluate, specify, design, implement phases",
+      "description": "Plan contains evaluate, design, implement phases",
       "expectations": [
         { "text": "Has evaluate step", "assertion": "step-exists:evaluate" },
-        { "text": "Has specify step", "assertion": "step-exists:specify" },
         { "text": "Has design step", "assertion": "step-exists:design" },
         { "text": "Has implement step", "assertion": "step-exists:implement" }
       ]

package/src/templates/skills/council/SKILL.md

@@ -87,13 +87,13 @@ Invokes all 3 agents IN PARALLEL using Task tool:
 
 ### 2. Council Feature-Scope
 
-**Participants:** Advisor + Product Owner + Tech Lead
+**Participants:** Advisor + Developer + Tech Lead
 **When it applies:** Defining feature scope, prioritizing functionality, evaluating product proposals
 
 Invokes all 3 agents IN PARALLEL using Task tool:
 
 - Task 1: Reads `.claude/agents/advisor.md` — domain and strategic vision perspective
-- Task 2: Reads `.claude/agents/product-owner.md` — user value and scope perspective
+- Task 2: Reads `.claude/agents/developer.md` — implementability and pragmatism perspective
 - Task 3: Reads `.claude/agents/tech-lead.md` — technical feasibility and effort perspective
 
 ### 3. Council Tech-Debt

package/src/templates/skills/dev-flow/SKILL.md

@@ -47,11 +47,10 @@ Read `SESSION.md` to determine:
 The pipeline phases are:
 
 1. **Evaluation** (Advisor) — go/no-go
-2. **Specification** (Product Owner) — acceptance criteria
-3. **Technical Approach** (Tech Lead) — implementation plan
-4. **Implementation** (Developer) — code and tests
-5. **Review** (Code Reviewer) — quality review
-6. **QA** — functional validation
+2. **Specification & Technical Approach** (Tech Lead) — tasks, acceptance criteria, implementation plan
+3. **Implementation** (Developer) — code and tests
+4. **Review** (Code Reviewer) — quality review
+5. **QA** — functional validation
 
 ### Step 3 — Present flow state
 
@@ -59,11 +58,10 @@ The pipeline phases are:
 Dev Flow — [feature name]
 
 [x] Phase 1 — Evaluation (completed)
-[x] Phase 2 — Specification (completed)
-[ ] Phase 3 — Technical Approach (pending) <-- you are here
-[ ] Phase 4 — Implementation
-[ ] Phase 5 — Review
-[ ] Phase 6 — QA
+[x] Phase 2 — Specification & Technical Approach (completed)
+[ ] Phase 3 — Implementation (pending) <-- you are here
+[ ] Phase 4 — Review
+[ ] Phase 5 — QA
 
 Next step: Run /build-feature to continue from Phase 3.
 ```
@@ -76,8 +74,8 @@ If there is no feature in progress, report that there is no active pipeline and
 User: /dev-flow
 
 Current pipeline: build-feature "add user preferences"
-Phase: 4 of 6 — Implementation
+Phase: 3 of 5 — Implementation
 Developer agent active.
 
-Next: Phase 5 — Code Review
+Next: Phase 4 — Code Review
 ```

package/src/templates/skills/guild-specialize/SKILL.md

@@ -126,13 +126,10 @@ Invoke the Tech Lead agent using Task tool with `model: "sonnet"` (execution tie
 
 - **advisor.md**: real project domain, target users
 - **tech-lead.md**: specific stack, detected patterns, architecture decisions
-- **product-owner.md**: existing functionality, visible backlog
 - **developer.md**: code conventions, main framework, file structure
 - **code-reviewer.md**: lint rules, project patterns, anti-patterns to watch
 - **qa.md**: testing framework, commands to run tests, current coverage
 - **bugfix.md**: debugging stack, logs, available tools
-- **db-migration.md**: ORM, migration tool, current schema (if applicable)
-- **platform-expert.md**: Claude Code version, known permission bugs, hook configuration
 
 When specializing agents, append a zone at the bottom of each agent file:
 
@@ -204,7 +201,6 @@ Tech Lead (sonnet) — Specializing agents...
 Agents updated:
 - developer.md: Specialized for Next.js + TypeScript
 - qa.md: Configured for Vitest + Playwright
-- db-migration.md: Configured for Prisma
 
 Run /status to see the full state.
 ```

package/src/templates/skills/status/SKILL.md

@@ -94,7 +94,7 @@ Session: 2026-02-23
 Task: Implementing user preferences
 State: Phase 4 — Developer implementing
 
-Agents: advisor, product-owner, tech-lead, developer, code-reviewer, qa, bugfix, db-migration, platform-expert
+Agents: advisor, tech-lead, developer, code-reviewer, qa, bugfix, learnings-extractor
 Skills: guild-specialize, build-feature, new-feature, council, qa-cycle, review, dev-flow,
   status, session-start, session-end
 ```

package/src/utils/dispatch-protocol.js

@@ -34,14 +34,11 @@ export const DEFAULT_FAILURE_STRATEGY = 'abort';
  */
 export const DEFAULT_AGENT_TIERS = {
   'advisor': 'reasoning',
-  'product-owner': 'reasoning',
   'tech-lead': 'reasoning',
   'code-reviewer': 'reasoning',
   'developer': 'execution',
   'bugfix': 'execution',
-  'db-migration': 'execution',
   'qa': 'execution',
-  'platform-expert': 'execution',
   'learnings-extractor': 'routine',
 };
 

package/src/utils/executor.js

@@ -3,7 +3,7 @@
  *
  * Drives a plan to completion by iterating through steps, dispatching
  * agent steps to a provider function and system steps to local commands.
- * Sequential execution only (v1.1); parallel groups deferred to v1.2.
+ * Supports parallel execution (v1.2) and delegation to sub-skills.
  */
 
 import { execFile } from 'child_process';
@@ -11,8 +11,15 @@ import {
   advanceStep,
   getNextSteps,
   isPlanComplete,
+  MAX_DELEGATION_DEPTH,
+  createExecutionPlan,
 } from './orchestrator.js';
-import { buildStepContext, recordStepTrace } from './orchestrator-io.js';
+import {
+  buildStepContext,
+  recordStepTrace,
+  loadWorkflow,
+  resolveStepDispatch,
+} from './orchestrator-io.js';
 
 const SYSTEM_STEP_TIMEOUT = 120_000; // 2 minutes
 
@@ -70,7 +77,7 @@ async function executeSystemStep(step, options = {}) {
   }
 
   if (step.delegatesTo) {
-    return { status: 'passed', output: `Delegation to "${step.delegatesTo}" skipped (v1.1)` };
+    return { status: 'passed', output: `System step with delegation — handled by executeDelegation` };
   }
 
   return { status: 'passed', output: 'System step completed' };
@@ -92,12 +99,111 @@ function findStepInPlan(plan, stepId) {
   return null;
 }
 
+/**
+ * Dispatches a single step (agent or system) and returns its result.
+ *
+ * @param {object} step - Step definition
+ * @param {object} dispatch - Dispatch info for this step
+ * @param {object} context - Execution context
+ * @param {import('./orchestrator.js').ExecutionPlan} context.currentPlan - Current plan state
+ * @param {Function} context.provider - Agent step provider
+ * @param {string} context.projectRoot - Working directory
+ * @param {string} context.skillBody - Skill body text
+ * @param {object} context.executeOptions - Full options passed to execute()
+ * @returns {Promise<{ status: string, output: string, outcome?: object, error?: string }>}
+ */
+async function dispatchStep(step, dispatch, context) {
+  const { currentPlan, provider, projectRoot, skillBody, executeOptions } = context;
+
+  if (step.role === 'system' && step.delegatesTo) {
+    return executeDelegation(step, executeOptions);
+  }
+
+  if (step.role === 'system') {
+    return executeSystemStep(step, { projectRoot });
+  }
+
+  const stepContext = buildStepContext(step, currentPlan, { skillBody });
+  return provider(step, dispatch, stepContext);
+}
+
+/**
+ * Executes a delegation step by loading and running the sub-skill.
+ *
+ * @param {object} step - Delegation step (with delegatesTo field)
+ * @param {object} options - Execute options from parent
+ * @returns {Promise<{ status: string, output: string, error?: string }>}
+ */
+async function executeDelegation(step, options) {
+  const {
+    provider,
+    trace,
+    projectRoot,
+    profile = 'max',
+    onStepStart,
+    onStepEnd,
+    delegationDepth = 0,
+  } = options;
+
+  if (delegationDepth >= MAX_DELEGATION_DEPTH) {
+    return {
+      status: 'failed',
+      output: '',
+      error: `Delegation depth limit (${MAX_DELEGATION_DEPTH}) exceeded at step "${step.id}" delegating to "${step.delegatesTo}"`,
+    };
+  }
+
+  let subSkill;
+  try {
+    subSkill = loadWorkflow(step.delegatesTo);
+  } catch (err) {
+    return {
+      status: 'failed',
+      output: '',
+      error: `Failed to load delegated skill "${step.delegatesTo}": ${err.message}`,
+    };
+  }
+
+  const subPlan = createExecutionPlan(subSkill.workflow, {
+    skillName: subSkill.name || step.delegatesTo,
+  });
+
+  const subDispatchMap = {};
+  for (const group of subPlan.groups) {
+    for (const s of group.steps) {
+      subDispatchMap[s.id] = resolveStepDispatch(s, { profile, projectRoot });
+    }
+  }
+
+  const finalSubPlan = await execute(subPlan, subDispatchMap, {
+    provider,
+    trace,
+    projectRoot,
+    skillBody: subSkill.body || '',
+    onStepStart,
+    onStepEnd,
+    delegationDepth: delegationDepth + 1,
+    profile,
+  });
+
+  if (finalSubPlan.status === 'completed') {
+    return { status: 'passed', output: `Delegation to "${step.delegatesTo}" completed` };
+  }
+
+  return {
+    status: 'failed',
+    output: '',
+    error: `Delegated skill "${step.delegatesTo}" ended with status: ${finalSubPlan.status}`,
+  };
+}
+
 /**
  * Executes a workflow plan to completion.
  *
  * Drives the orchestrator state machine by repeatedly calling getNextSteps,
  * dispatching each step (agent via provider, system via local commands),
- * and advancing the plan with the result.
+ * and advancing the plan with the result. Parallel groups are dispatched
+ * concurrently via Promise.all.
  *
  * @param {import('./orchestrator.js').ExecutionPlan} plan - Initial execution plan
  * @param {Object.<string, import('./orchestrator-io.js').StepDispatchInfo>} dispatchInfoMap - Dispatch info per step
@@ -108,6 +214,8 @@ function findStepInPlan(plan, stepId) {
  * @param {string} [options.skillBody=''] - Skill body text for context building
  * @param {Function} [options.onStepStart] - Callback before each step: (step, dispatch) => void
  * @param {Function} [options.onStepEnd] - Callback after each step: (step, result) => void
+ * @param {number} [options.delegationDepth=0] - Current delegation nesting depth
+ * @param {string} [options.profile='max'] - Model profile for delegation dispatch
  * @returns {Promise<import('./orchestrator.js').ExecutionPlan>} Final plan state
  */
 export async function execute(plan, dispatchInfoMap, options = {}) {
@@ -127,7 +235,6 @@ export async function execute(plan, dispatchInfoMap, options = {}) {
   while (!isPlanComplete(currentPlan)) {
     const { steps, skipped } = getNextSteps(currentPlan);
 
-    // Advance skipped steps first
     for (const stepId of skipped) {
       currentPlan = advanceStep(currentPlan, stepId, { status: 'skipped' });
 
@@ -140,7 +247,6 @@ export async function execute(plan, dispatchInfoMap, options = {}) {
       }
     }
 
-    // If no executable steps remain, check completion again
     if (steps.length === 0) {
       if (isPlanComplete(currentPlan)) break;
       if (++emptyIterations > MAX_EMPTY_ITERATIONS) {
@@ -151,30 +257,34 @@ export async function execute(plan, dispatchInfoMap, options = {}) {
     }
     emptyIterations = 0;
 
-    // v1.1: sequential execution — one step at a time
-    const step = steps[0];
-    const dispatch = dispatchInfoMap[step.id] || {};
+    const dispatchContext = {
+      currentPlan,
+      provider,
+      projectRoot,
+      skillBody,
+      executeOptions: options,
+    };
 
-    onStepStart?.(step, dispatch);
+    const settled = await Promise.all(
+      steps.map(async (step) => {
+        const dispatch = dispatchInfoMap[step.id] || {};
+        onStepStart?.(step, dispatch);
+        const result = await dispatchStep(step, dispatch, dispatchContext);
+        return { step, dispatch, result };
+      })
+    );
 
-    let result;
-    if (step.role === 'system') {
-      result = await executeSystemStep(step, { projectRoot });
-    } else {
-      const context = buildStepContext(step, currentPlan, { skillBody });
-      result = await provider(step, dispatch, context);
-    }
+    for (const { step, dispatch, result } of settled) {
+      currentPlan = advanceStep(currentPlan, step.id, result);
 
-    currentPlan = advanceStep(currentPlan, step.id, result);
+      if (trace) {
+        recordStepTrace(trace, step, currentPlan.stepStates[step.id], dispatch);
+      }
 
-    if (trace) {
-      recordStepTrace(trace, step, currentPlan.stepStates[step.id], dispatch);
+      onStepEnd?.(step, result);
     }
-
-    onStepEnd?.(step, result);
   }
 
-  // Mark plan as completed if all steps reached terminal state and plan is still running
   if (currentPlan.status === 'running' && isPlanComplete(currentPlan)) {
     currentPlan = { ...currentPlan, status: 'completed' };
   }

package/src/templates/agents/db-migration.md

@@ -1,51 +0,0 @@
----
-name: db-migration
-description: "Schema changes and safe migrations"
-tools: Read, Write, Edit, Bash, Glob, Grep
-permissionMode: bypassPermissions
-default-tier: execution
----
-
-# DB Migration
-
-You are the database specialist for [PROJECT]. Your job is to design and execute schema changes safely, ensuring existing data integrity and production performance.
-
-## Responsibilities
-
-- Design schema changes with up and down migrations
-- Verify impact on existing data before migrating
-- Consider production performance (large tables, locks, indexes)
-- Use the project's ORM and migration tools
-- Ensure every migration is reversible
-
-## What you do NOT do
-
-- You do not implement application logic -- that is the Developer's role
-- You do not define system architecture -- that is the Tech Lead's role
-- You do not validate functional behavior -- that is QA's role
-- You do not prioritize tasks -- that is the Product Owner's role
-
-## Process
-
-1. Read CLAUDE.md and SESSION.md to understand the project's migration tools
-2. Analyze the required schema change and its impact on existing data
-3. Design the migration: up (apply) and down (revert)
-4. Verify the migration is safe for production data
-5. Implement using the project's ORM tools
-6. Document performance considerations if applicable
-
-## Quality criteria
-
-- Every migration has functional up and down operations
-- Impact on existing data is verified (no data loss)
-- Locks and performance on large tables are considered
-- Indexes are created/modified concurrently when possible
-- Default values are handled correctly for existing rows
-
-## Behavior rules
-
-- Always read CLAUDE.md and SESSION.md before designing migrations
-- Never make destructive changes without a prior data migration
-- If the change affects tables with many records, warn about performance
-- Prefer small, incremental migrations over massive changes
-- Verify compatibility with the project's ORM and tools

package/src/templates/agents/platform-expert.md

@@ -1,92 +0,0 @@
----
-name: platform-expert
-description: "Diagnoses and resolves Claude Code integration issues -- permissions, subagents, hooks, settings"
-tools: Read, Write, Edit, Bash, Glob, Grep
-permissionMode: bypassPermissions
-default-tier: execution
----
-
-# Platform Expert
-
-You are the Platform Expert for [PROJECT]. Your job is to diagnose and resolve integration issues between Guild and Claude Code, including tool permissions, subagent configuration, hooks, and settings.
-
-## Responsibilities
-
-- Diagnose permission issues in subagents (Bash denied, tool access, etc.)
-- Configure agent frontmatter for correct tool access
-- Implement PreToolUse hooks for permission workarounds
-- Maintain compatibility with Claude Code versions
-- Document platform limitations and known workarounds
-
-## Specialized knowledge
-
-### Subagent Permission Model
-
-Claude Code subagents run in `dontAsk` mode by default. They do not inherit permissions from `settings.json`. To grant Bash access:
-
-1. **Frontmatter `tools` field:** Explicitly declare available tools
-2. **Frontmatter `permissionMode`:** Controls permission level
-3. **PreToolUse hooks:** Workaround to auto-approve tools
-
-### Agent configuration with Bash
-
-```yaml
----
-name: agent-name
-description: "Description for delegation"
-tools: Read, Write, Edit, Bash, Glob, Grep
-permissionMode: bypassPermissions
----
-```
-
-### Agent configuration without Bash (analysis)
-
-```yaml
----
-name: agent-name
-description: "Description for delegation"
-tools: Read, Glob, Grep
-permissionMode: plan
----
-```
-
-### PreToolUse Hook workaround
-
-If `permissionMode` does not work, use hooks:
-
-```yaml
-hooks:
-  PreToolUse:
-    - matcher: "Bash"
-      hooks:
-        - type: command
-          command: "echo '{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"permissionDecision\":\"allow\"}}'"
-```
-
-### Known Claude Code bugs
-
-- Issue #18950: Subagents do not inherit permissions from settings.json (OPEN)
-- Issue #14714: Subagents do not inherit tools from parent
-- Issue #21585: subagent_type "Bash" fabricates output instead of executing
-
-## What you do NOT do
-
-- You do not implement business features -- that is the Developer's role
-- You do not define application architecture -- that is the Tech Lead's role
-- You do not evaluate strategy -- that is the Advisor's role
-
-## Process
-
-1. Read CLAUDE.md to understand the current configuration
-2. Identify the permission/integration problem
-3. Research Claude Code documentation and known issues
-4. Propose a solution using frontmatter, hooks, or settings
-5. Test the solution with a test subagent
-6. Document the solution and workaround
-
-## Behavior rules
-
-- Always verify the Claude Code version before diagnosing
-- Prioritize official solutions over workarounds
-- Document ALL workarounds with a reference to the GitHub issue
-- Do not assume a platform fix works -- always test it

package/src/templates/agents/product-owner.md

@@ -1,52 +0,0 @@
----
-name: product-owner
-description: "Converts approved ideas into concrete, implementable tasks"
-tools: Read, Glob, Grep
-permissionMode: plan
-default-tier: reasoning
----
-
-# Product Owner
-
-You are the Product Owner for [PROJECT]. Your job is to translate ideas approved by the Advisor into concrete tasks with verifiable acceptance criteria that the team can implement without ambiguity.
-
-## Responsibilities
-
-- Convert approved ideas into implementable tasks with clear acceptance criteria
-- Break down large features into atomic, independent tasks
-- Prioritize the backlog by business value and impact
-- Define the "done" for each task in a verifiable way
-- Maintain traceability between the project vision and individual tasks
-
-## What you do NOT do
-
-- You do not define architecture or technical patterns -- that is the Tech Lead's role
-- You do not implement code -- that is the Developer's role
-- You do not evaluate domain coherence -- that is the Advisor's role
-- You do not validate functional behavior -- that is QA's role
-
-## Process
-
-1. Read CLAUDE.md and SESSION.md to understand the current state
-2. Receive the idea or feature approved by the Advisor
-3. Break it down into concrete tasks with defined scope
-4. Define verifiable acceptance criteria for each task
-5. Estimate relative effort and suggest implementation order
-
-## Output format
-
-For each task:
-
-- **Title**: Concrete action in imperative form
-- **Description**: What is needed and why (2-3 sentences)
-- **Acceptance criteria**: Verifiable list (checkboxes)
-- **Technical tasks**: Breakdown of implementation steps
-- **Estimate**: Small / Medium / Large
-
-## Behavior rules
-
-- Always read CLAUDE.md and SESSION.md before planning
-- Each acceptance criterion must be verifiable with yes/no
-- If a task is too large to implement in a single session, split it
-- Do not assume technical context -- leave implementation details to the Tech Lead
-- Prioritize delivered value over technical perfection