app-do-prd

Orchestrates autonomous execution of all slice issues in a PRD via worktree-isolated workers.

Updated May 7, 2026
One-click install
npx skills add https://github.com/Pieter-1337/Euricom-tsz --skill app-do-prd-pieter-1337
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: app-do-prd
Source: https://github.com/Pieter-1337/Euricom-tsz/tree/main/.claude/skills/app-do-prd
Command: npx skills add https://github.com/Pieter-1337/Euricom-tsz --skill app-do-prd-pieter-1337

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Executing a full PRD means manually tracking which slice issues are unblocked, spawning workers for each, watching CI, and recovering from failures one at a time. This Skill automates that entire orchestration loop so a whole PRD can be executed end-to-end without babysitting each slice. ## Core Features & Use Cases - Dependency-aware scheduling: Parses each child issue's ## Blocked by field into a DAG, detects cycles, and launches only slices whose blockers have merged. - Worktree-isolated parallel workers: Spawns one agent per ready slice (running /app-do-work) in its own git worktree, with automatic agent routing to backend-engineer, frontend-engineer, or documenter based on touched paths. - Deterministic finisher and recovery: When a worker bails before opening a PR, the orchestrator runs validation, commits, pushes, and opens the PR itself; failed slices get one diagnostic re-spawn while independent siblings continue. - Optional auto-merge: With --auto-merge=true, merges PRs itself once CI is green, review threads are resolved, and no reviewer findings remain. - Use Case: Given a parent PRD issue like #33 with eight child slice issues, run the orchestrator to ship all mergeable slices in parallel, then receive a final report of merged, failed, and skipped slices. ## Quick Start Ask the AI to run the app-do-prd skill on PRD issue #33 with default parallel worktree workers and continue-siblings failure handling.

Frequently Asked Questions about app-do-prd

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

FAQPage Schema
How do I run a whole PRD autonomously across its slice issues?

Invoke the orchestrator with the parent PRD issue reference, such as #33 or a full GitHub issue URL. It fetches child issues via gh issue list, builds the dependency DAG from each child's Blocked by section, and spawns one worktree-isolated worker per ready slice until everything is merged or failed.

How does the orchestrator decide which agent type runs each issue?

Routing is based on file paths in the issue body: api-only paths go to backend-engineer, web-only paths to frontend-engineer, docs-only to documenter, and mixed paths to backend-engineer. The --agent flag overrides routing for the whole run, and issues with no path signal halt for human re-scoping.

What happens when a worker finishes without opening a PR?

The orchestrator runs a deterministic finisher node instead of re-spawning an agent. It checks the worktree, runs the validation suites, adds a missing CHANGELOG entry, commits, pushes, and opens the PR itself, only re-spawning the worker once if validation is red.

Can the orchestrator merge PRs automatically without human review?

Yes, but only when --auto-merge=true is passed. It then runs gh pr merge itself once CI is green, all review threads are resolved, no reviewer findings are unaddressed, and GitHub reports the PR mergeable. By default, human review stays in the loop.

What happens when a slice fails and cannot be recovered?

The orchestrator gives one diagnostic re-spawn with the previous error context. If it still fails, the default continue-siblings mode marks the slice failed, preserves its worktree and branch, and keeps launching independent slices; --on-failure=halt stops everything instead.

When should I use single-issue execution instead of PRD orchestration?

Use the per-slice /app-do-work skill directly when you only want to implement one issue at a time. The orchestrator is for running an entire PRD; it does not decompose a single oversized issue across multiple workers, which signals the issue should be re-sliced instead.