From jmichaelschmidt-skills-public
Execute an existing PRD or implementation plan by acting as the orchestrator. Reads the plan, determines runnable threads, spawns bounded subagents when appropriate, tracks status, integrates results, and verifies completion. Use when users say "execute this PRD", "run this plan", "orchestrate these threads", "delegate this implementation plan", or "work through this PRD".
npx claudepluginhub jmichaelschmidt/skills-public --plugin skills-publicThis skill uses the workspace's default tool permissions.
Execute an existing PRD as the orchestrator. This skill assumes the plan already exists and is written as discrete threads with dependencies, verification steps, and reasoning levels.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Execute an existing PRD as the orchestrator. This skill assumes the plan already exists and is written as discrete threads with dependencies, verification steps, and reasoning levels.
Use this skill after prd-planner, or whenever the user already has a thread-based plan.
The main session is the orchestrator. It owns:
Subagents are disposable workers, not permanent personas. Specialization comes from thread scope, file ownership, reference material, and risk level.
Workflow skills support this role system. They do not replace the core starter-pack roles or their boundaries.
Use prd-executor when the user wants to:
If the plan does not exist yet, use prd-planner first.
Read the PRD fully. Extract:
If the PRD is missing dependency or verification detail, repair the execution view before spawning agents. Do not delegate from a vague plan.
If a sibling execution manifest exists, use it as a compact routing aid for status, dependencies, owner hints, and output artifacts. The PRD still wins if the two disagree.
For complex plans, create a compact execution ledger using references/execution-ledger-template.md.
Use one of three modes:
Prefer the smallest amount of parallelism that still improves throughput.
Use this default routing:
| Thread type | Recommended owner |
|---|---|
| Investigation / read-only tracing | explorer subagent or local if urgent |
| Minimal / low implementation | worker subagent |
| Medium implementation | worker subagent with explicit file ownership |
| Medium-high cross-cutting change | usually one worker, reviewed by orchestrator before integration |
| High-risk security / architecture / rollout | orchestrator-led, with optional explorer sidecars |
Do not delegate the immediate blocking step if the orchestrator needs that result right away to keep moving.
Each subagent prompt must be self-contained. Include only:
Use references/thread-prompt-template.md as the default shape.
If a manifest is present, include only the current thread's manifest entry plus the exact PRD thread section, not the full manifest.
For each runnable thread:
Do not allow multiple workers to edit the same files unless the overlap is trivial and intentional.
Every thread must pass:
For security-sensitive, rollout, or production-impacting plans, add an orchestrator-owned verification pass even if a subagent already tested its own thread.
Track each thread as one of:
PENDINGIN_PROGRESSBLOCKEDDONEFor each thread, record:
The ledger can live in a separate doc or as completion logs appended to the PRD. Keep it concise and current.
If a manifest exists, update its thread status values alongside the ledger or PRD completion log.
Do not mark a thread DONE unless you have concrete evidence for both:
Confidence, plausible summaries, or "should work" reasoning are not completion evidence.
These patterns from gsd-build/get-shit-done are worth adopting:
Do not copy XML-heavy plan formats or build a command framework inside the skill. Reuse the existing markdown PRD format.
Reasoning effort in the PRD is a routing hint, not a guarantee of a specific model in this interface.
Use it to decide:
Default policy:
Before spawning any subagent, estimate the total context the thread requires:
Apply these routing rules based on context volume:
| Context Volume | Routing |
|---|---|
| Under 50KB total input | Standard delegation -- any model handles this |
| 50-100KB total input | Prefer Opus; Sonnet may work if output is short |
| Over 100KB total input | Require Opus, or keep the thread in the orchestrator session where context is already loaded |
| Synthesis threads (must read all upstream deliverables) | Always Opus or orchestrator-local. These threads are the most likely to fail on smaller context windows. |
A thread is a synthesis thread if any of these are true:
Synthesis threads should be flagged in commentary before dispatch. If the orchestrator already has upstream context loaded from reviewing prior threads, keeping the synthesis local is often faster and more reliable than delegating.
explorer for read-only repo questions.worker for bounded implementation with disjoint ownership.prd-planner