slop-fix-batch git:20261011.e99f977A

Immutable. This exact content never changes and is served at /api/v1/blob/5e58c9034ec4f040.

---
name: slop-fix-batch
description: "Fix a fixed batch of open repository issues selected by human-supplied conditions using parallel subagents and scoped stack executors, group related fixes, publish each verified group immediately in dependency-based PR stacks without rebasing existing layers during construction, and directly manage ongoing repairs and conditional whole-stack merging after verified publication. Start only when the human explicitly invokes $slop-fix-batch."
---

# Slop Fix Batch

Start a new batch only on an explicit human `$slop-fix-batch` invocation with issue-selection conditions. Loading, editing, testing or planning this skill does not start a batch. Collect the complete canonical fixed list once; never add later discoveries. Existing `$bulk` and `$slop-fix-issue` workflows publish separately and are not batch workers. Never create implementation or repair sidebar chats.

The invocation authorizes scoped investigation/implementation, evidence-backed closure of already-resolved issues, verified stacked publication, and direct coordinator management of this batch's ready stacks. Complete multi-PR stacks prefer native whole-stack squash merging after all remaining layers pass current review/CI gates; sequential squash merging is allowed only when native capability is verified unsupported. Originally standalone PRs may enable auto-merge after review passes. Multi-PR stacks never enable auto-merge, even with one open layer left. No review records count as a pass only after complete reads; existing records must have no effective change request or unresolved non-outdated finding. Use [batch maintenance](references/batch-maintenance.md) for full gates and recovery.

The primary objective is to verify that implemented PRs are merged. Before each new assignment at a safe boundary, check ready stacks for due gate, merge and result-verification work. Do not delay that work for more implementation, a full inventory, other worker results or a delayed refresh. If only external CI/review waits remain, continue independent construction with available slots. PR creation or merge-request acceptance is not completion.

New batches run directly in this coordinator chat through construction, repair, conditional merging and verified completion. Do not create, update or schedule Codex automations, heartbeat jobs or background polling processes. At each safe boundary collect results and process due work; when only external waits remain, use interruptible waits of at most 30 seconds while honoring refresh deadlines and shared API cooldowns. Publication or implementation completion does not end management. On interruption, recover the same ledger and reconcile owners/effects before resuming.

## Roles and execution routing

- **Coordinator:** resolve selection and fixed-list coverage; confirm groups, dependencies and stack membership; allocate all runtime slots; approve scoped START/grants; close already-resolved issues; run the direct management loop and record stop/resume state; reconcile exceptions and product decisions. Use the scheduler at allocation boundaries. Do not execute each stack's integration/publication/maintenance tail after delegation.
- **Stack executor:** one bounded checked-group job per assigned building stack. Own its integration checkout, registration, Git integration, changed-integration checks, $create-pr publication/attachment, gh-stack prefix submission/verification and complete-stack ready transition. Invoke $create-pr directly, without another publication worker or coordinator approval at each step. Never merge or register maintenance.
- **Maintenance actor:** one bounded job per assigned ready stack. Own fresh gates, conditional merging/auto-merge, remote result verification and repair management under whole-stack ownership. Repair children require coordinator-reserved extra slots; with one available slot, return the repair signal and slot so the coordinator can dispatch repair directly.
- **Inventory actor:** one captured global inventory pass. Observe only assigned PRs, record complete versus partial coverage, coalesce checkpoints and return its slot. Never mutate GitHub.
- **Investigation, implementation and repair workers:** retain scoped acceptance, exact-SHA and validation requirements. Implementation/repair workers do not merge, register automations, change global assignments or write the ledger.

New execution batches explicitly enable [scoped delegation](references/delegation.md) at the idle pre-dispatch boundary. Existing ledgers remain coordinator-only until an explicit safe-boundary activation. All descendants inherit the parent's model/reasoning except the existing one-shot repair setting in maintenance. No default total concurrency cap is added.

Every active, reserved, nested or uncertain actor uses the human/runtime budget, including maintenance and inventory. Stack jobs use the publication lane and its measured ceiling. Schedule ready gate/merge/result-verification jobs first, then confirmed merge-blocking repairs, other repairs, publication, implementation, inventory, investigation and preparation. Preserve explicit human allocations. The single-slot construction progress exception applies only after gate/merge work and confirmed merge-blocking repairs. Do not keep an actor alive through implementation, CI or review waits. Return its slot only after known effects are recorded; pending/uncertain effects retain accounting and ownership for reconciliation. Retain build protection between stack jobs.

Read [helper contracts](references/helpers.md), [scheduling](references/scheduling.md) and [worker handoffs](references/worker-prompts.md) before collection/dispatch. Use collect-issues for exact-query collection, the shared github-request helper for authenticated requests, batch-ledger for coordinator or authorized scoped events, batch-stack for deterministic bounded construction steps, verify-publication for each prefix, batch-checkpoints for due work and render-handoff for assignments/reporting. Helpers validate facts and transitions; they do not decide root causes, resolve conflicting requirements or establish merge authority.

## Workflow references

- For preflight, fixed selection, overlap/group decisions, fresh independent bases, implementation, closure and reporting, read [construction](references/construction.md). Dispatch confirmed independent work while unrelated investigation continues. Preserve protected ancestry; never copy prerequisites across stacks or rewrite construction layers.
- For an execution assignment, role/grant validation, direct event submission, integration/publication or ownership handoff, read [delegation](references/delegation.md). Shared catalog mutations remain serialized through the entire command and reconciliation, without holding the ledger lock during network I/O. Only the same stack waits for that operation.
- Apply [validation policy](references/validation.md) to every worker and publication: automated checks run in the implementation worker; unchanged cherry-picks reuse their original coverage; integration changes require only relevant checks. No cumulative/final-tip validation. Skip manual launches, real-environment validation and validation screenshots, disclose them as not performed, and retain Closes for implemented issues. Direct issue closure still requires all acceptance evidence.
- During direct management or an explicit maintenance continuation, recover the existing ledger and follow [batch maintenance](references/batch-maintenance.md). Do not recollect, restart construction or invoke another maintenance skill. Separate inventory work from targeted ready-stack jobs so a slow stack does not block independent construction or maintenance. Ready handoffs/checkpoints enqueue work; the coordinator schedules it without waiting for CI/reviews or all workers.

Use one batch-scoped GitHub queue/cache/cooldown state across every role. Reuse complete observations where applicable, preserve all pages/identity checks, and never use cache TTL or queue hints as fresh merge evidence. Mutations invalidate representations before and after every attempt. Honor shared primary/secondary cooldowns and incomplete/busy results; never retry uncertain writes or rotate tokens to bypass limits. Shared gh-stack catalog and actual Git/stack ownership remain mandatory. Direct gh and extension-internal requests are not intercepted; record those coverage gaps and missing-header limits. Follow GitHub's [REST best practices](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api) and [rate-limit rules](https://docs.github.com/en/graphql/overview/rate-limits-and-query-limits-for-the-graphql-api).

## Plan Mode investigation and handoff

When the human invokes this workflow in Plan Mode, complete its investigation in that mode before returning an implementation plan. Apply the read-only parts of **Preflight and fixed selection** and **Assess and group**: resolve the repository and selection conditions, collect the complete canonical fixed list, and record the exact target SHA inspected. Missing or ambiguous conditions require an answer before searching. Failed, capped, partial, or incomplete collection remains a collection blocker; do not dispatch from a truncated list. An empty complete result ends planning with that result.

Use read-only investigation subagents and the [investigation assignment](references/worker-prompts.md#investigation-assignment), passing Plan Mode explicitly. Keep the existing model inheritance, shared API budget, concurrency accounting, and validation policy. Inspect every selected issue's body, complete discussion, relevant code and history, and existing fixing PRs. Collect results as they arrive and continue independent investigations, but recover every assignment's result and reconcile coverage of the entire fixed list before finalizing the plan. Do not defer investigation to execution or return only a generic description of this workflow.

For every issue, establish its classification, acceptance requirements, evidence, and proposed fix or reason no new implementation is needed. Reconcile overlaps and confirm actionable groups, directed dependencies, stack membership, implementation approach, and automated validation commands under the existing grouping rules. Ask for material product decisions that the issue and repository cannot resolve. Access failures or missing evidence remain explicit investigation blockers; do not describe the affected investigation as complete or finalize a decision-complete plan while required investigation or decisions remain outstanding.

Plan Mode permits investigation only. Do not implement, close issues, post comments, publish PRs, mutate source or Git refs, create construction worktrees, run stack mutations, acquire construction ownership, start maintenance or register automation, or merge. Use permitted read-only access to the target revision instead of executing mutation steps from preflight; report unavailable revision access as a blocker. Construction ledger fields and registrations belong to execution. Preserve permitted planning observations outside tracked source or in this chat without fabricating execution records. Rules that dispatch implementation while investigation continues, refill publication/repair lanes, or run maintenance checkpoints apply only in execution mode.

Return the final plan in a `<proposed_plan>` block. Include the original conditions, exact query, canonical issue list, repository/base and inspected SHA, per-issue classification and evidence, acceptance requirements, proposed changes, group-to-stack assignments, directed prerequisites, scheduling rationale, validation commands, and known blockers. Distinguish inspection and executed checks from planned checks and skipped real-world validation. Report existing fixing PRs without planning duplicates, and propose evidence-backed closure of already-resolved issues without closing them. Plan dependency constraints and scheduling rules, not a fixed total integration order; actual layer order still follows the existing dependency and completion policy.

After leaving Plan Mode, reuse the fixed list and completed investigation results. Revalidate the target SHA, issue/PR state, changed code, and evidence relevant to the planned groups before implementation or closure. Reconcile affected assessments and dependencies when those facts changed; do not repeat all completed investigations or collect later issues. Initialize the execution ledger from the planning observations and apply the normal preflight, ownership, implementation, publication, and maintenance gates. Planning observations do not satisfy execution-time checks or authorize writes while Plan Mode remains active.