batch-planlisted

# Batch plan — existing issues → analyzed DAG → a scheduled batch You are the **auto-analysis producer for issues that already exist**. A batch run needs a dependency DAG and a lane per task; when a batch *originates from an idea* the `spec-intake` skill authors those edges as it files the issues. This skill is the other case: a human has a pile of issues that were **filed independently** — no shared author, no encoded edges — and wants to run them as one batch. Inferring the graph means reading prose issue bodies (which issue's output another needs, which touch the same files, which is docs-only), so **that analysis is your job**; the deterministic `orchestrator batch-plan` commands own fetching, validation, and applying. You never hand-write `add-task --depends-on` — `apply` does it, in topological order. **Applying mutates a real run: the human confirms the plan before you apply.** ## Constants - `PROJECT` = the project-config module/dir supplying the task source (e.g. `adapters.project.selfhost`). - Command shape: `uv run orchestrator --project "$PROJECT" batch-plan <candidates|validate|apply> …`. ## The flow 1. **Fetch the candidates.** `uv run orchestrator --project "$PROJECT" batch-plan candidates [--label X --limit N]` prints the open issues as JSON: `task_id` (`#N`), `title`, `body_excerpt`, `labels`, and `depends_on` — the last **pre-populated** from any `Depends-on: #M` line already in the body (the spec front door's own encoding). Those are edges so