address-followups

Work Follow-ups

Invocation: Claude Code /gauntlet:address-followups; Codex $gauntlet:address-followups.

This skill is the TRIGGER. It is not the rules.

../campaign/references/followups.md owns the follow-up lifecycle, the three-tier autonomy threshold, the resume-by-state list, and every store transition. Read it before touching an entry, and read it from <skill-dir>/../campaign/references/followups.md, not from memory. This skill is the on-demand entry point to that loop: it works the queue when the user asks for it, rather than only when a campaign heartbeat has spare capacity to spend on it. An invocation from here holds no lease and drives no run, so two of that loop's steps cannot mean from here what they mean to a run's driver; followups.md, "WORKING A FOLLOW-UP", names both deviations, and Steps 2 and 7 below are where this file carries them.

NEVER reconstruct the threshold, the conditions, or the legal transitions from this file. It owns only what it says here: which entries get picked up, in what order, which worker runs each step, and what happens to the PRs at the end. Everything else is a pointer, deliberately.

Runtime adapter

• <checkout> is an input this skill receives, never a constant it knows. It is the checkout the user named with the invocation, and the repository the session is already running in when they named none — the same convention the sibling skills state (../followups/SKILL.md and ../ledger/SKILL.md, step 1 of each). Neither host supplies it in an environment variable, so NEVER read one for it. Step 0 resolves it to an absolute repository root once, and that one absolute result is what every later <repo-root>, every path derived from it, and every subagent prompt carries. No worker re-resolves it, and none is handed a relative path or left to infer one from its own working directory.
• Every gh call made under this skill NAMES the repository it is about — the driver's own calls and those of the subagents it dispatches alike. gh given no repository resolves in whatever checkout the process is standing in, which need not be <checkout> — ../campaign/references/ci-derivation-spec.md, "--repo IS NOT OPTIONAL", owns that rule and campaign's own call sites obey it (../campaign/references/pr-adoption.md pins the working directory; ../campaign/scripts/label-mirror.py passes --repo). Step 0 resolves the repository's <owner>/<name> once, as <repo-slug>, and every gh invocation this file tells an agent to run carries --repo <repo-slug> — this rule covers a gh call added here later exactly as it covers the ones written today. A subagent stands in its own working directory and cannot resolve the slug for itself, so <repo-slug> travels as data in the prompt of every worker this skill dispatches (Steps 3 and 5), and each of those prompts is bound by this rule for whatever gh calls that worker's job requires. The single exception is Step 0's own resolving call, which cannot name what it is resolving and is pinned by its working directory instead.
• Resolve <skill-dir> from the actual path of this active SKILL.md. NEVER depend on CLAUDE_PLUGIN_ROOT, PLUGIN_ROOT, the current working directory, or a repository-relative path.
• Campaign's bundled scripts are <skill-dir>/../campaign/scripts/; its references are <skill-dir>/../campaign/references/. Resolve both to absolute paths and pass those absolute paths to every subagent.
• Run every bundled script through its interpreter with that absolute path — python3 <abs-path>/followups.py …. NEVER invoke one bare (../campaign/SKILL.md, "Bundled Scripts", owns the rule and why).
• "Subagent" means a fresh, context-isolated worker launched through the active host's agent mechanism. Describe each worker's scope, permissions, and output in its prompt; do not require a host-specific agent type or model name.
• Logical model classes map to the active host through ../campaign/references/runtime-adapter.md, "Model classes".
• If the host has no fresh-worker mechanism, STOP and report that. Do not investigate inline and do not fix inline. Keeping those two steps out of the driver's context, and out of each other's, is the whole guarantee (followups.md, "The two subagents are the load-bearing part"); running either in the driver's context removes it.