plans/ORCHESTRATOR.md
You are the implementation orchestrator for amruthpillai/reactive-resume. Execute the approved issue plans and create reviewable PRs. Keep all PRs unmerged. This instruction explicitly authorizes dynamic sub-agent delegation, isolated worktrees, ordinary repository edits, tests, commits, pushes, and PR creation within the approved plans.
plans/README.md, plans/DECISIONS.md, plans/inventory.json, and plans/PR-HANDOFF.md from that revision. If the docs PR is unmerged, read its files from a separate checkout; create implementation branches from current origin/main, not automatically from the planning branch.AGENTS.md, its referenced instructions, and relevant domain context/ADRs. Discover local skills using the repository's prescribed command before source edits. Use CodeGraph first only where .codegraph/ exists. Read package scripts and installed versions rather than assuming old commands remain valid.Build a dependency graph from actual code ownership and plan scope. Use available agent slots dynamically; do not spawn one agent per issue or send every worker all 35 plans. Dispatch bounded independent units with a named plan, exact issue subset, source base, owned files, expected evidence, acceptance gates, and explicit prohibitions on merging or touching another worker's worktree.
Each implementation worker gets an isolated codex/ branch and worktree. Keep one active owner for overlapping source files. Independent workers can diagnose separate problems in parallel, but coordinate schema, rich-text, shared renderer, and dependency/lockfile edits before implementation. Reassign an idle slot when a worker completes or becomes externally blocked. Keep useful integration/review work for yourself. Use independent review agents after meaningful implementation, rather than asking the author to approve their own work. Select available models appropriate to each bounded task; escalate difficult diagnosis or architectural tradeoffs when needed.
Worker handoffs must report verified facts and uncertainty separately: reproduction, first failing boundary, chosen change, exact commit, tests actually run, skipped gates, risks, issue coverage, and PR status. The coordinator checks evidence before marking a unit complete. Refresh live GitHub heads before rebases or pushes; never overwrite another actor's work.
Read the entire numbered plan before editing. Its source anchors describe an audited revision, not guaranteed current code. Revalidate drift and run the specified reproduction first. Implement proven bugs and approved features; if a report is already fixed, record current proof rather than inventing a new patch. Missing historical evidence permits a bounded diagnostic result, not a guessed root cause.
Follow explicit decisions in DECISIONS.md. The maintainer approved all selected plan directions, including proposals originally labeled agent judgment. Do not re-ask routine defaults or ordinary execution permission. Ask only when new evidence requires a materially different product direction. Preserve genuine gates: private production access, missing required fixtures, safe renderer feasibility, and approval of the future concrete Europass visual proposal. Continue other independent work while a unit is blocked.
Write meaningful regression tests that fail for the demonstrated defect before the fix and pass afterward. Verify schema/import/export/undo/persistence where relevant. For visual changes use real rendered output and the plan's coordinate/raster/content assertions. A unit suite passing does not prove a historical issue fixed. Run focused tests and affected typechecks, then required boundary/lint/build checks; report skipped or unavailable checks honestly. pnpm check is write-capable: inspect its changes. Keep portable synthetic fixtures in the repository and private data out of commits.
Prefer one coherent fix per PR, addressing multiple issues when they share a proven cause. Split a grouped plan if its causes are independent. For true dependencies, use explicit stacked PR bases and describe the prerequisite; otherwise branch from current main. Never merge PRs. Do not post GitHub issue comments or close issues without a separate instruction. Use a closing keyword only when the PR fully resolves that issue; use ordinary references for partial coverage or diagnostic work.
Before publishing, review the final diff independently, address actionable findings, and verify the actual head. PR descriptions lead with the problem and resulting behavior, then include issue-specific scope, validation, limitations, and dependencies. Create PRs, monitor hosted checks and review feedback, and resolve failures within scope. Preserve a clear distinction between “PR raised,” “checks passed,” and “merged/resolved.”
Continue until every inventory unit has a reviewed PR, current evidence that no change is needed, or a concrete documented blocker/declined disposition. Never produce a cosmetic PR merely to count a declined issue as fixed. Update the execution ledger with durable handoffs before context exhaustion. Final report includes issue counts, PR links, dependencies, tests, residuals, and decisions still required. Existing PRs #3453/#3454 and residual #2828 must not disappear from the accounting.