| name | drip |
| description | Pace PR creation — one PR open at a time per repo, one per org at a time, address feedback before pushing new. The skill matches tone, runs the codex lineup, and decides when to fold reviewer feedback in. Queue state, hard gates, gh I/O, and the heartbeat live in `sweep` CLI. |
| argument-hint | <repo> [--check] [--push] [--list] [--ingest] [--watch] |
| allowed-tools | Read, Write, Edit, Bash, Glob |
Drip: One PR at a Time
You were invoked by the harness on one repo. Your job is the LLM-shaped part of pushing a PR: tone-matching the description, running the codex AI-likeness lineup, and handling reviewer feedback on already-open PRs. Pacing math, gh fetches, hard gates, status transitions, and the queue file all belong in sweep drip — call it.
Eleven PRs in two days gets you banned. One PR per merge cycle builds gravity. The code is the same; pacing is what makes the inbox welcoming.
The CLI is the harness
| What you need | How to get it |
|---|
| List the queue | sweep drip list --repo … |
| Check whether it's time to push (runs every hard gate, returns the next pushable entry or a reason) | sweep drip check --repo … |
| Force-push the next queued entry | sweep drip push --repo … [--branch …] |
| Enqueue a new entry | sweep drip enqueue --repo … --branch … --issue N --test-cmd … |
| Run heartbeat (15-min check cycle) | sweep drip watch --repo … |
| Hard gates (test fail-on-master/pass-on-fix, staleness, org-gate, cooldown, dry-mode) | Run as part of sweep drip check — don't reimplement |
| Open PRs with new reviewer activity | sweep drip checkup --repo … |
If sweep drip check returns "blocked: ," read the reason and act on it — don't push past it. That's the skills-lack-determinism loop: deterministic gates return useful errors; the agent closes the loop. If a gate is mis-classifying, fix the gate, not this file.
The judgment part
Generating the PR description (tone match)
The CLI gives you the diff and 5 recently merged PRs from the repo. Your job: write a title and body that match. Match title format, body length, level of detail. Don't write a description; inhabit the repo's voice. The chameleon rule.
The receipt (deeper the reason, more explicit the receipt)
The body's content follows a fixed shape — receipt format. Voice/tone still matches the repo's, but the structure shows the work:
<terse one-liner conclusion>
- <reason why thing X doesn't work, natural language>
- <reason why thing Y doesn't work, different angle>
- <finally what worked, and why>
[HG](https://github.com/kimjune01/sweep/blob/master/repo-hypotheses/<owner>__<repo>__<issue>.md)
Three rules for the bullets:
- Each bullet is one sentence, in natural prose. Not a table, not "Hypothesis: ... Falsifier: ..." headers (that's bot prose; see wild#1924 retro).
- Lead with what didn't work — the maintainer sees that you searched the space, not just landed on an answer. Two dead ends and one survivor is the calibration: it tells them how much was tried.
- Each bullet names a concrete thing: a function, a flag, an observed behavior. "X doesn't work because Y" beats "we considered an alternative."
The [HG] link points at the full investigation trace in this repo's repo-hypotheses/ directory. The receipt is the curated headline; the HG is for the maintainer (or other contributors) who want to dig in. Most won't click; the existence of the link is the credibility signal.
The /investigate skill writes the HG file at ~/Documents/sweep/repo-hypotheses/<owner>__<repo>__<issue>.md before handing off to /drip. If the file is missing, omit the [HG] link rather than fake it.
Codex lineup (hard block; LLM-shaped)
After tone matching, shuffle the candidate description into 5 recently-merged PR descriptions from different contributors and ask /codex:
Here are 6 PR descriptions from a repo. One may be AI-generated. Which ones, and why? If you can't tell, say so.
- Can't pick: pass.
- Identifies the candidate: rewrite to fix the specific tells codex named. Do not give the rewriter a checklist or rubric — detection is a wasting asset under feedback; any rubric becomes the exploit surface. Re-shuffle, re-test.
- Still detectable after 5 rounds: surface to the human. Some repos have a voice Claude can't imitate; forcing it makes it worse.
Gemini volley (final review, LLM-shaped)
Send diff + generated description + issue link to /gemini:
You are a maintainer seeing this for the first time. Would you merge it?
Five rounds max. Won't converge to zero findings — iterate until structure is sound.
Reviewer feedback on open PRs (LLM-shaped)
sweep drip checkup reports new comments on your open PRs. For each one:
- Classify: requested change / question / style nit / approval.
- Requested changes and questions: address them with a follow-up commit. Re-run the gemini volley on the updated PR before pushing.
- Style nits: apply if trivial, reply explaining if not.
- Address feedback before pushing new PRs. A PR with unaddressed reviewer comments older than 24h is a driveby. The CLI gate enforces this; don't try to push past it.
- Never edit the diff in a way that changes the issue's intent. If a reviewer asks for a change the issue's commenter didn't ask for, surface — don't fold it in.
Rules (judgment, not mechanics)
- Fork only, never origin. PRs use
--head <user>:<branch>. You're a guest.
- Never force push. If the branch needs a rebase, the user does it manually; drip pushes, it doesn't fix.
- Never merge. The maintainer ships.
- Address feedback before pushing new. Inbox manners.
What this skill does not do
- Read or write
~/.sweep/drip-queue/*.jsonl. (sweep drip enqueue / the CLI does.)
- Run
gh auth status, gh pr list, gh pr view, gh issue view. (The CLI does, with the right cache and rate-limit handling.)
- Test attestation (fail-on-master / pass-on-fix), staleness check, org-gate, cooldown timer, dry-mode skip. All hard gates run inside
sweep drip check. The skill doesn't replicate them.
- Heartbeat loop. (
sweep drip watch or /loop 15m /drip.)
- Status enum, queue schema. (Harness owns it.)
- Decide
max_open or max_open_per_org. (Retro params, surfaced by the CLI.)
Output contract (machine-readable, REQUIRED)
After all narration, the last printed line must be a single JSON object matching this schema:
{
"pushed": false,
"pr_url": "https://github.com/owner/repo/pull/N or null",
"outcome": "pushed | rebased | checked | noop | failed",
"reason": "short string, ≤200 chars",
"rejected": false,
"reject_reason": null
}
pushed=true iff a commit or PR actually hit the remote on this run. outcome is the verb that happened (the checked branch corresponds to --check invocations that don't push). Set rejected=true with a reject_reason when the job is undeliverable (no fork remote, stale branch, missing PR — anything that means "this msg cannot be acted on"). Rejected jobs route to ~/.sweep/inbox/rejected.jsonl for operator review.
Print the JSON as the literal last line, no trailing prose, no markdown fence.
