multi-track-orchestration

Governs central-controller behavior for multi-track parallel story pipeline dispatch and gating.

10|3|Updated Mar 7, 2026
One-click install
npx skills add https://github.com/Cynthia1070711/PHYCOOL_Tools --skill multi-track-orchestration-cynthia1070711
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: multi-track-orchestration
Source: https://github.com/Cynthia1070711/PHYCOOL_Tools/tree/main/config-templates/claude/skills/multi-track-orchestration
Command: npx skills add https://github.com/Cynthia1070711/PHYCOOL_Tools --skill multi-track-orchestration-cynthia1070711

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When acting as the central controller of a multi-track parallel Story pipeline, it is easy to misjudge execution carriers, misread manual-track status, skip GATE evidence checks, delay commits, or kill healthy workers. This Skill codifies the behavioral discipline (SOP-1 through SOP-7) that prevents those failures. ## Core Features & Use Cases - Execution Carrier Judgment: Decide whether a card goes to a dispatched worker sub-window or a manual track based on whether it modifies pipeline machinery itself. - Dispatch Loop & GATE Evidence Chain: Run the event-driven five-step dispatch loop and verify the six-item GATE evidence chain (status file, DB lifecycle, tasks, PID exit, red flags, deep checks) before advancing. - Commit Wave Timing & Cross-Window Coordination: Commit per-card immediately after CR passes GATE using pathspec, coordinate freeze windows with manual tracks, and follow a 7-case anomaly handling manual. - Use Case: While orchestrating parallel dev cards, you check the manual track's lifecycle timestamps before dispatching, detect a four-dimension overlap (build/verify/load/self-run) between two cards, and sequence them instead of dispatching in parallel. ## Quick Start Act as the central controller for the multi-track pipeline and plan the dispatch order for these story cards, checking manual-track status and overlap before each dispatch.

Frequently Asked Questions about multi-track-orchestration

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide between dispatching a worker sub-window and using a manual track?

Check whether the card modifies pipeline machinery itself, such as worker scripts, stop-report.ps1, settings.json hooks, or UserPromptSubmit. If it does, route it to the manual track; otherwise dispatch it. Record the judgment in the card's pipeline_notes.

How do I check manual track status before dispatching workers?

Query lifecycle timestamps (create_started_at, started_at, completed_at) from the stories table rather than regex-matching pipeline_notes markers. Check both start and completion, and read completion marker content since it often specifies freeze scope.

What evidence is required before passing a stage GATE?

Six items are mandatory: status file showing completed with empty error, DB lifecycle fields written, zero unchecked tasks, wrapper PID exited, red-flag review, and deepened checks for high-risk cards. Skipping any item is prohibited.

When should the central controller commit during multi-track work?

Commit each card's file_list via pathspec immediately after its CR passes GATE, never waiting for milestone wrap-up. During parallel manual-track work, commit dev stages separately so the other track sees a clean tree.

Why is comparing file_list alone insufficient for parallel card overlap analysis?

File intersection only covers the build dimension. Cards can also conflict through verification (one card's AC runs a tool another card modifies), loading (a rule another card's workflow loads), and self-run surfaces (tools every stage executes).

Should I kill a worker when the monitor times out?

No. Timeout or low CPU is not proof of a hung worker. Check DB updated_at, IPC status files, and actual sub-window output before deciding to wait or intervene; force-killing a working worker wastes completed work and corrupts state.