Create a durable implementation plan with scout discovery, reviewer critique, and optional SDD orchestration.
From workflow-orchestrationnpx claudepluginhub mikecubed/agent-orchestration --plugin workflow-orchestrationThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Implements structured self-debugging workflow for AI agent failures: capture errors, diagnose patterns like loops or context overflow, apply contained recoveries, and generate introspection reports.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Use this skill when a developer wants a disciplined planning workflow before implementation, especially for feature-shaped work that may need specification, planning, task generation, or explicit execution handoff.
Persistent team, squad, or fleet-style long-lived orchestration is out of scope for this skill. Use a separate orchestration layer if persistent coordination is needed.
This skill is for planning and orchestration, not direct implementation. It may optionally compose with sdd-workflow, but it must fall back cleanly when SDD is unavailable.
Activate when the developer asks for things like:
Use a lighter path or skip this skill when the work is already narrow and fully scoped, such as a single-file bug fix or a straightforward review follow-up.
Before you start, identify:
sdd-workflow is available in the current runtime;.sdd/ planning workspaces or expects another temporary planning sink.Use separate roles for:
All roles may receive the discovery brief as factual context — file lists, task boundaries, validation commands, and known dependencies. Do not pass one role's conclusions or assessments to another; the reviewer must form an independent judgment from the plan artifact itself.
Resolve the active model for each role using this priority chain:
.copilot/models.yaml.claude/models.yamlplanner: <model-name>
reviewer: <model-name>
scout: <model-name>
See docs/models-config-template.md for ready-to-copy runtime templates.
| Runtime | Role | Default model |
|---|---|---|
| Copilot CLI | Planner | claude-opus-4.6 |
| Copilot CLI | Reviewer | gpt-5.4 |
| Copilot CLI | Scout | claude-haiku-4.5 |
| Claude Code | Planner | claude-opus-4.6 |
| Claude Code | Reviewer | claude-opus-4.6 |
| Claude Code | Scout | claude-haiku-4.5 |
Do not run a heavy planning workflow for a narrow, fully scoped change. Use scout discovery to decide whether the request needs:
Create one discovery brief per planning session when possible. The brief should capture shared facts, not conclusions:
If sdd-workflow is available and the task is feature-shaped, the planner may orchestrate:
/sdd-workflow:sdd.specify/sdd-workflow:sdd.plan/sdd-workflow:sdd.tasksIf SDD is unavailable or overkill for the task, use the fallback planning flow instead.
The planning session is not complete until one durable planning artifact or planning summary has been produced. Chat-only planning is not sufficient.
If discovery, planning, or review stalls:
Before delegating to expensive planning or review work, run one lightweight discovery pass using the scout model.
The scout MUST produce a short factual brief covering:
sdd-workflow appears available.Use the discovery brief template from docs/workflow-artifact-templates.md.
Skip condition: Skip discovery only when the request is already narrow and fully scoped. If skipped, record the skip reason in the brief.
Based on the brief, the planner chooses one of these modes:
sdd-workflow is available.Record the chosen mode and rationale in the planning artifact.
At this gate (after the planning mode is chosen and scope is confirmed), write
.agent/SESSION.md with the current session state using the canonical schema
(docs/session-md-schema.md). Record:
current-task: the overall task descriptioncurrent-phase: "requirements-confirmed"next-action: the exact next step after this gateworkspace: the active branch or PR referencelast-updated: current ISO-8601 datetime## Decisions: decisions confirmed during requirements review (including chosen planning mode)## Files Touched: files read so far## Open Questions: unresolved questions for the developer## Blockers: active blockers (empty if none)## Failed Hypotheses: (empty — not applicable for this skill)If the write fails (permission error, no .agent/ directory): log a warning and continue.
The write must not block the skill's primary workflow.
If using SDD-backed planning, orchestrate:
/sdd-workflow:sdd.specify/sdd-workflow:sdd.plan/sdd-workflow:sdd.tasksThen normalize those outputs into one planning summary that captures:
If using fallback planning, produce the same information directly without SDD.
Send the plan artifact to a separate reviewer and ask for only substantive issues:
If the reviewer finds substantive issues:
Allow at most 2 resend attempts. If the plan still does not converge after the second resend, escalate to the developer or stop the planning session.
If planning stalls — discovery remains unclear, SDD orchestration fails, or review churn continues without convergence:
Before stopping, publish one durable planning artifact or summary that records:
The artifact MUST use a repository-appropriate durable sink — for example, a committed document, PR description, issue comment, or task tracker entry.
When appropriate, recommend the next workflow explicitly:
/workflow-orchestration:parallel-implementation-loopA planning session is not complete until:
Before marking the planning session complete, confirm ALL of the following.
If any item is FAIL: surface the uncovered requirement or unresolved issue. Do not mark the plan as accepted.
Before stopping because a planning loop stalled, always attempt rescue first: narrow scope, reduce context, or switch from SDD-backed planning to fallback mode.
Task summary: Add a planning skill and umbrella marketplace layout
Planning mode: fallback planning
Relevant files: plugin.json, .github/plugin/marketplace.json, skills/planning-orchestration/SKILL.md
Validation commands: npm test, npm run validate:runtime
Task boundaries: In scope = plugin layout, planning skill, marketplace metadata; out of scope = persistent orchestration service
Dependencies: marketplace naming decision complete
Recommended next action: invoke /workflow-orchestration:parallel-implementation-loop for implementation
Unresolved questions:
- Whether to keep the current plugin name during the first migration phase
Workflow outcome measures:
- discovery-reuse: yes
- rescue-attempts: 0