dependabot-remediation

Dependabot Remediation

Turn one repository's open Dependabot security alerts into a few well-sized beads, then fix one bead at a time with native verification, separately confirmed publication and remote resolution observed rather than assumed. The objective is valuable security fixes, not zero alerts or dependency freshness. Routine Dependabot version-update PRs are out of scope.

/dependabot-remediation                 # plan: discover, triage, propose beads, create after confirmation, stop
/dependabot-remediation discover        # the same plan with no tracker write at all
/dependabot-remediation fix <bead>      # process one planned bead to a verified local commit, one push offer, one recheck
/dependabot-remediation recheck <bead>  # re-read alert state for one planned bead
/skill:dependabot-remediation [mode]    # Pi

Codex can request the skill by name. A fix bead picked through /next continues into fix for that bead; an investigation or follow-up bead runs its recorded read-only task and does not enter the fix pipeline. Nothing appended to the invocation widens source, tracker, or remote authority.

Two runs, not one campaign

A plan run fetches alerts, validates fixes, triages duplicates and existing owners, and proposes a small set of beads; after confirmation it creates them and stops. It never edits a dependency. A fix run takes one bead to a verified local commit, one publication offer and one alert recheck, then stops. Neither run starts the next bead, a next batch, a watcher, PR triage or any follow-on maintenance; a new request starts another bounded run.

• Urgent fixes. Each eligible critical outcome gets a dedicated bead. Several alerts on one package are still one outcome and one bead.
• Normal fixes. The remaining eligible outcomes form batches of up to 5 fixes, grouped by manifest so one batch is one lockfile, one diff and one verification cycle. At most 3 batch beads are created per plan run (--batch-size and --max-batches override).
• Follow-up. When eligible fixes remain beyond those beads, one deferred follow-up bead wakes in 7 days to run a fresh plan. It is reused on rerun, never duplicated, and waking it does not start fixes.
• Residual risk. Held, unpatched, deferred and failed outcomes stay visible in the plan and on the beads. "Ignore" means not now, with a reason: never a GitHub dismissal or a false-positive claim. Development-only scope lowers ordering but is not automatically irrelevant. No bead is created per held package; offer an investigation only when it could change a decision (§3).
• Exception budget. During a fix run at most 2 outcomes may fall out of the bead because of an incompatible API, failing check or hidden major bump. A third failure stops the run at the last safe checkpoint; what passed is still verified and finalized. A limit may stop between checkpoints; never abandon a half-applied dependency change because the budget ran out.
• Separate requests. Major upgrades and migrations, general version updates, triaging, closing or merging existing Dependabot PRs, validation worktrees and prolonged deployment monitoring each need a new explicit request.