| name | executing-plans |
| description | Use when partner provides a complete implementation plan to execute — reviews the plan critically, verifies live PR state against plan assumptions, creates Linear tickets via plan-to-tickets, then routes to epic-team (≥3 tickets) or ticket-pipeline (1-2 tickets) |
| version | 2.0.0 |
| level | intermediate |
| debug | false |
| category | workflow |
| tags | ["planning","execution","linear","routing"] |
| author | OmniClaude Team |
Executing Plans
Dispatch Requirement
When invoked, dispatch to a polymorphic-agent:
Agent(
subagent_type="onex:polymorphic-agent",
description="Execute plan <plan-name>",
prompt="Run the executing-plans skill. <full context>"
)
CRITICAL: subagent_type MUST be "onex:polymorphic-agent" (with the onex: prefix).
Overview
Load a plan file, review it critically, create Linear tickets from it, then route to the
appropriate execution skill based on ticket count.
Core principle: Linear-native routing. Plans become tickets; tickets drive execution.
Announce at start: "I'm using the executing-plans skill to implement this plan."
The 5-Step Flow
Step 1: Review Plan
Load the plan file and review it critically before taking any action.
Plan file: If a plan path was passed as a positional argument (e.g., from design-to-plan Phase 3),
use it directly. Do not re-discover or re-summarize the plan.
- Read the plan file in full
- Identify any concerns:
- Missing acceptance criteria or definition of done
- Ambiguous or contradictory requirements
- Unclear dependencies between phases
- Missing repo label (required for architecture validation)
- Steps that reference external systems or secrets not yet available
- If concerns exist: raise them with your human partner and wait for resolution before proceeding
- If no concerns: proceed to Step 1.5
Do not proceed to ticket creation if the plan has unresolved questions.
Step 1.5: Verify Live PR State
If the plan references existing PRs or branches, verify their live state before proceeding.
Plans often assume a PR is open and mergeable, but reality may have changed since the plan
was written.
Run for each PR referenced in the plan:
gh pr view <PR-number> --json state,mergeable,mergeStateStatus,statusCheckRollup,headRefName
Classification and action:
| CI/Mergeability State | Classification | Action |
|---|
PENDING / checks still running | PENDING | Poll up to 3 times (30s interval). If still pending after 90s, report status and proceed -- do not block indefinitely. |
BEHIND (mergeable but needs rebase) | ACTIONABLE | Note in plan review; proceed. Rebase will happen during execution. |
CLEAN / UNSTABLE (mergeable, checks pass/flaky) | READY | Proceed normally. |
CONFLICTING (merge conflicts) | STOP | Stop and report: "PR #N has merge conflicts. Plan assumes it is mergeable. Please resolve conflicts or update the plan." |
Checks FAILURE (required checks failing) | STOP | Stop and report: "PR #N has failing required checks. Plan assumes CI is green. Please fix CI or update the plan." |
MERGED | STOP | Stop and report: "PR #N is already merged. Plan assumes it is open. Please update the plan to reflect current state." |
CLOSED (not merged) | STOP | Stop and report: "PR #N is closed without merge. Plan assumes it is open. Please update the plan." |
Rules:
- Only poll for PENDING state; all other states are immediately actionable or blocking.
- Never wait more than 90 seconds total for pending checks.
- If the plan does not reference any PRs or branches, skip this step entirely.
- After verification, proceed to Step 2.
Step 2: Dry-Run Preview
Call /plan-to-tickets with --dry-run to preview what tickets would be created.
/plan-to-tickets <plan-file> --dry-run [--repo <repo-label>] [--project <project>]
Review the dry-run output:
- Confirm the detected structure — expect
task_sections for plans produced by design-to-plan (## Task N: headers); other valid types: phase_sections (legacy ## Phase N:), numbered_h2, step_sections, milestone_table, priority_labels. If dry-run reports task_sections, that is correct — do NOT ask the user to reformat.
- Confirm the epic title that would be used
- Confirm the list of tickets that would be created
- Check that dependencies are correctly detected
If the preview looks wrong, stop and discuss with your partner before creating tickets.
Step 3: Create Tickets
Call /plan-to-tickets (without --dry-run) to create the Linear tickets under the epic.
/plan-to-tickets <plan-file> [--repo <repo-label>] [--project <project>] [--skip-existing]
After creation, record:
- The epic identifier (e.g., OMN-XXXX)
- The list of created ticket identifiers
- The total ticket count
Common flags:
--repo <label> — enables architecture dependency validation (recommended)--project <name> — assigns tickets to a Linear project--skip-existing — skip tickets that already exist instead of prompting--no-create-epic — fail if the epic does not already exist
Step 4: Route to Execution
Compute routing from the plan file content, not just ticket count:
| Condition | Route | Why |
|---|
| Multiple repos touched | /epic-team | Cross-repo needs orchestration |
| Migrations or deploy steps present | /epic-team | Infrastructure changes need coordination |
| 3+ distinct subsystems affected | /epic-team | Broad blast radius |
| 3+ tickets (fallback) | /epic-team | Parallel execution needed |
| 1-2 tickets, single repo, no migrations | /ticket-pipeline | Lightweight |
Log the routing decision: "Routing to {skill} because: {reason}"
epic-team route
/epic-team <epic-id>
epic-team orchestrates a team of parallel worker agents, one per repo. It handles
ticket assignment, worktree creation, and lifecycle notifications automatically.
ticket-pipeline route
/ticket-pipeline <ticket-id>
Run /ticket-pipeline for each ticket sequentially. Each pipeline handles the full
implement → review → PR → CI → merge workflow autonomously.
Verification Commands
After routing, verify progress:
/epic-team <epic-id> --resume
cat ~/.claude/pipelines/<ticket-id>/state.yaml
When to Stop and Ask for Help
STOP executing immediately when:
- Plan has critical gaps or missing context (before Step 1.5)
- A referenced PR is CONFLICTING, FAILING, MERGED, or CLOSED (Step 1.5)
- Dry-run output reveals structural problems (before Step 3)
plan-to-tickets fails with an architecture violation (before routing)- A ticket-pipeline run fails and cannot self-recover
Ask for clarification rather than guessing.
Post-Completion
When all tickets/tasks close:
- Discover open PRs:
gh pr list --head <branch> --json number,title,state
- If PRs have review comments: offer
pr-polish
- Offer: "All work complete. Run /finishing-a-development-branch? [Y/n]"
- If Y: invoke finishing-a-development-branch
This is an offer only — user must approve before dispatch.
Remember
- Review plan critically before creating any tickets
- Verify live PR state before dry-run if the plan references existing PRs
- Always dry-run first to preview ticket structure
- Routing threshold is 3 tickets:
epic-team for ≥3, ticket-pipeline for 1–2
- Stop and ask if any step surfaces unexpected errors
