메뉴
Sift through candidates surfaced by /scout — fetch issues, screen for receipts, deposit survivors into /triage's inbox. Dedupes against ~/.sweep/seen/issues.txt to avoid resurfacing. Renamed from /prospect (and earlier /actionable).
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | sift |
| description | Sift through candidates surfaced by /scout — fetch issues, screen for receipts, deposit survivors into /triage's inbox. Dedupes against ~/.sweep/seen/issues.txt to avoid resurfacing. Renamed from /prospect (and earlier /actionable). |
| argument-hint | ["--dry-run"] |
| allowed-tools | Read, Write, Edit, Bash, Glob, Grep |
Sift through scout's candidates for work worth doing. Start from intent, not repos. Renamed from /prospect (and earlier /actionable) — same shape, name better describes the role (filter through noise to find value worth extracting, hand off to /triage).
Work worth doing is anything the maintainer wants done — bugs are a subset. The full space is desirable improvements: bugs, planned features, roadmap items, conformance gaps, performance targets, doc holes. The common thread is maintainer pre-commitment: they signaled they want this, nobody's doing it, and the acceptance criteria are readable.
An item where:
Maintainer signaled intent — they opened it, commented, labeled it, added it to a milestone, listed it in a roadmap, pinned it, or wrote "PRs welcome"
Receipts of reasoning are producible — the work can be defended with a hypothesis graph (reasoning trace) and test attestations (evidence). The real outcomes are value delivered to maintainers and learning extracted by the pipeline. Both are unmeasurable. Merge rate is the most legible proxy, but optimizing the proxy is Goodhart.
When a category of work hits high merge rate, that's a signal it's saturated, not a signal to do more of it. Saturation means the pipeline isn't learning anymore and the maintainer isn't getting marginal value beyond the obvious. The mix should ratchet toward harder work over time, the same way the detector floor ratchets up. Two tracks coexist:
Diff size doesn't gate. Information-content does. Pick work where the maintainer gains real queue relief and the pipeline gains real evidence about what it can and can't do. Watch the merge rate, but don't optimize for it.
Calibration target: 50% merge rate. Under shifting constraints (the criterion keeps ratcheting up), 50% is the rate that maximizes outcome entropy — each PR is genuinely uncertain, so each merge or close delivers the maximum bit of learning. Above 50% means the bar is too low (we're picking saturated work). Below 50% means over-reach (the work is wrong or the standing isn't there). Hold the rate near 50% by ratcheting difficulty up as the pipeline gets better. Same principle as active learning's uncertainty sampling: label the uncertain examples first because they teach the most.
Nobody's working on it — no assigned contributor, no open PR addressing it
The repo has a harness — CI + bench that gives a definitive yes/no before you submit
Estimated fix fits the merge ceiling — check the repo's merged PR size distribution (from review schema or retro). If the median external merge is ~30 lines and the fix looks like 500+, score it down hard. Prior PRs at 10-50x the merge ceiling don't land regardless of quality.
Failure paths produce receipts too. An investigation that can't reproduce the bug isn't waste. The hypothesis graph (here's what we tried, here's why each branch failed) plus a recommendation to close (or to mark "needs more info") is a real contribution to the maintainer's queue. Don't filter out issues just because reproduction looks uncertain — investigate, document, and either ship a fix or post the receipts and recommend close. Both outcomes reduce the issue backlog. The only true waste is investigating without producing artifacts.
| Signal | Where to find it | Strength |
|---|---|---|
| Maintainer opened the issue | Issue author = repo owner/collaborator | Very strong — they defined the problem |
| Milestone assignment | gh issue view --json milestone | Strong — scheduled, not aspirational |
| Roadmap / tracking issue | Pinned issues, ROADMAP.md, TODO.md, project boards | Strong — published plan |
enhancement + maintainer comment | Issue labels + comment authors | Medium — acknowledged want |
help wanted / contributions welcome | Issue labels | Medium — explicit invitation |
planned / accepted / next-release labels | Issue labels | Medium — intent without urgency |
CONTRIBUTING.md listing areas of help | Repo docs | Weak — general, not specific |
good first issue | Issue labels | Weak — high competition, but standing-builder |
Bugs with reproducers are the safest entry point. Roadmap items with specs are the highest-leverage. Features without maintainer endorsement are noise — inventing problems.
Only other people's repos. Never your own — you don't need a pipeline to work on your own code.
gh api graphql -f query='{ viewer { contributionsCollection { pullRequestContributions(first: 100) { nodes { pullRequest { repository { nameWithOwner } } } } } } }'
Filter: not owned by you, still active, has open issues, not on cooldown. You have context, the maintainer knows your name.
For repos with high merge rates, check the same org, same dependency graph, same topic tags. Retro says what "good" looks like — actionable finds more of it.
Keyword trawling alone fails for niche skillsets. Use all of these:
a. Label search (broad sweep)
gh search issues --label "good first issue" --language <lang> --sort created --limit 200
gh search issues --label "help wanted" --language <lang> --sort created --limit 200
gh search issues --label "enhancement" --label "accepted" --language <lang> --sort created --limit 100
gh search issues --label "planned" --language <lang> --sort created --limit 100
Cast wide — 200 results per language per label. Score by issue quality. At 1000 slots, false positives are cheap; false negatives are expensive.
b. Intent search (roadmap mining)
Find items the maintainer already wants done — not just bugs, but planned improvements, conformance gaps, and accepted enhancements.
# Milestone items with no assignee — scheduled work nobody's claimed
gh api "repos/OWNER/REPO/milestones" --jq '.[].number' | while read ms; do
gh api "repos/OWNER/REPO/issues?milestone=$ms&assignee=none&state=open&per_page=20" \
--jq '.[] | "\(.number) \(.title)"'
done
# Pinned issues — maintainer's priorities
gh api "repos/OWNER/REPO/issues?state=open&per_page=100" \
--jq '[.[] | select(.labels[]?.name | test("tracking|roadmap|planned|accepted|meta"))] | .[] | "\(.number) \(.title)"'
# Tracking issues with unchecked items
gh api "repos/OWNER/REPO/issues?state=open&per_page=50" \
--jq '.[] | select(.body | test("- \\[ \\]")) | "\(.number) \(.title)"'
Roadmap files (ROADMAP.md, TODO.md, project boards) are also intent signals but aren't API-searchable across repos. Check them per-repo after the repo enters the roster.
d. GitHub trending
gh api /search/repositories?q=stars:>1000+pushed:>$(date -v-7d +%Y-%m-%d)&sort=updated&per_page=100
Active high-star repos. Filter for open good-first-issues. These repos have review bandwidth.
e. Dependency graph traversal For repos where you've merged PRs, check their dependency tree:
gh api repos/OWNER/REPO/dependency-graph/sbom
Upstream dependencies often share maintainers. If you have standing in ruff, check astral-sh/uv, astral-sh/ty, etc.
f. "Used by" expansion GitHub shows repos that depend on a project. High-star dependents of projects you've contributed to are warm leads — you understand the dependency.
g. Topic cluster search
gh search repos --topic=parser --topic=formatter --language=Go --sort=stars --limit 50
gh search repos --topic=linter --topic=type-checker --language=Python --sort=stars --limit 50
Find repos in the same domain as your highest-merge repos.
h. Overwhelmed maintainer search (maintainer-first)
Instead of "what's broken," ask "who needs help." Search for solo maintainers with popular repos and growing issue backlogs. The issue is secondary — any bug on their queue is welcome.
Profile: personal account (not org), top contributor has >80% of recent commits, open issues growing, last external PR was merged (proving they accept contributions).
# Search for CLI/TUI tools by personal accounts with issue backlogs
gh api search/repositories -X GET \
-f "q=topic:cli stars:>200 pushed:>$(date -v-30d +%Y-%m-%d)" \
-f "sort=updated" -f "per_page=20" \
--jq '.items[] | "\(.full_name) (\(.stargazers_count)★, \(.open_issues_count) issues)"'
For each candidate, verify the solo-maintainer signal:
# Check if top contributor dominates
gh api "repos/OWNER/REPO/contributors?per_page=5" --jq '.[0].contributions, .[1].contributions // 0'
# Check if external PRs merge
gh pr list --repo OWNER/REPO --state merged --limit 5 --json author --jq '[.[] | .author.login] | unique'
Solo maintainer + popular tool + issue backlog + merge history = high-receptivity target. These maintainers appreciate the small stuff — cosmetic fixes, error messages, edge cases — because they don't have time for it themselves.
Big repos are fine. The pipeline has landed PRs on godot (90k★), pytorch (90k★), hyper, VictoriaMetrics, envoy, and polars. Large repos with active CI and clear contribution norms are often easier — they have established review processes, fast CI, and maintainers who expect external PRs. The constraint is merge ceiling (diff size vs repo norms), not repo size or star count. A 10-line fix on a 50k★ repo is more likely to merge than a 500-line fix on a 500★ repo.
Retro note (2026-05-09): Compiler/optimizer niche is too narrow for generic labels. But general bug fixes, error messages, and docs span all domains. The pipeline's skillset is "read code, find root cause, write fix" — not limited to compilers. Expand the search to any well-maintained repo with mechanical acceptance criteria.
Retro note (2026-05-10): Maintainer-first search found pvolok/mprocs (2.5k★, 65 issues, solo Rust maintainer) via ecosystem graph from existing roster repos. Issue-first search misses repos where the maintainer hasn't labeled issues yet.
Retro note (2026-05-10): Maintainer-first repos have 50-100+ open issues — pick the easiest, not the most interesting. On mprocs (65 issues) and onecli (228 issues), triage agents picked domain-heavy bugs (config-vs-state, security defaults) and gemini killed both. The maintainer doesn't need you to redesign their state model. They need the 30 boring items off their plate: typos, error messages, missing edge cases, doc fixes. For first contribution to a solo-maintainer repo, filter issues by estimated complexity ≤10 lines and labels like docs, error-message, typo, good-first-issue. Standing first, ambition second.
Retro note (2026-05-14): Standing tier unlocks ambition. Cold repos still need mechanical first contributions. But once standing exists (3+ merges, no warnings, recent reviewer engagement), the hypothesis-graph format itself is the gate, not diff size. A 200-line refactor with H0/H1/H2 + perturbations + evidence is more contributable than a 5-line typo at a hostile repo. The reader of the PR is the hypothesis graph; reviewers who accept that format absorb larger work because the graph reduces their review cost. Use the warm/hot tier to take on architecturally substantive issues that still close cleanly under investigation. Tier table:
| Standing | Issue criteria |
|---|---|
| Cold (0-2 merges) | mechanical only, ≤30 lines, label-tagged (good first issue, bug, docs) |
| Warm (3+ merges, no warnings) | hypothesis-graph-tractable bugs and maintainer-acknowledged features, ≤150 lines |
| Hot (5+ merges, recent positive review) | architecturally substantive issues with a closeable graph, no hard line cap; bug-hunt unlocked |
gh pr list --repo OWNER/REPO --search "KEYWORD" --state open before scoring. If a PR exists and was updated in the last 30 days, skip. If stale (>30 days, no reviews), note as opportunity to pick up the stalled work. Retro 2026-05-09: gemini-cli #25693 and #25689 both had competing PRs (#25728, #25729) that triage agents discovered only after full investigation.process_depth: shallow in their review schema — the pipeline produces investigation-backed PRs. Shallow-review repos can't absorb them. Only add shallow repos if the issue is trivial enough that investigation depth is unnecessary (1-line fix, obvious bug, failing test with known cause).~/.sweep/bin/body-count <repo> <issue-number>. If verdict is "skip" (3+ distinct unmerged authors), the issue is a honeypot. The signal isn't "nobody solved it yet," it's "the maintainer is tired of closing these."~/.sweep/bin/ai-policy <owner/repo>. If detected: true, don't add to roster. Unless --dry-run, run ~/.sweep/bin/offer-slop-filter <owner/repo> — it checks the banlist, dedupes against existing issues, opens the slop filter issue from the template, and logs to candidates.jsonl. One script, idempotent. In dry-run, log the candidate but don't open the issue.Updated ~/.sweep/repos.jsonl. Log additions and removals to ~/.sweep/actionable/candidates.jsonl.
Don't just rank by quality and take the top-k. That clusters — you'd end up with 10 Python ML repos. The pipeline learns faster from diverse repos than correlated ones.
After scoring candidates, select the final set using DPP-style diversity. Each candidate repo gets a feature vector:
| Feature | Why it matters |
|---|---|
| Language | different toolchains, different review norms |
| Domain | ML, systems, web, infra, devtools |
| Process depth | mix of shallow and deep tests different hypotheses |
| Org size | solo maintainer vs large team, different dynamics |
| Issue type | bugs, perf, correctness, docs |
| Hypothesis gap | which of H0-H6 does this repo test that existing repos don't? |
Hypothesis-driven selection (retro 2026-05-09): The pipeline is an experiment, not a merge optimizer. Each repo is a perturbation. Select repos that fill gaps in the hypothesis coverage, not just feature-vector distance. Ask "which hypothesis does this test?" before "will this merge?" Specifically: fast-review repos test H3 (pacing), solo maintainers test H2/H5, AI-friendly repos test H4. A repo that fills a hypothesis gap is worth more than a high-merge-probability repo that duplicates an existing condition.
Selection: diversify strategies, not just results. Each parallel agent uses a different search strategy — one does label search, one does trending, one does dependency graph, one does topic clusters. Strategy diversity prevents correlated search spaces.
Three dice, three axes. Roll all three, build the query, fetch results, filter deterministically. No learning, no posterior, no feedback loop. The dice don't learn — you can't overfit a d20.
# Roll 3 queries (each is a d12 × d8 × d6 = 576 combinations)
python3 ~/.sweep/bin/roll-search.py 3
Dice tables live in ~/.sweep/bin/roll-search.py:
Each roll outputs a query + sort. Search with REST:
python3 ~/.sweep/bin/roll-search.py 3 | while IFS=$'\t' read -r query sort; do
gh api search/issues -X GET -f "q=$query" -f "sort=${sort#sort:}" -f per_page=30 \
--jq '.items[] | "\(.repository_url | split("/")[-2:]|join("/")) #\(.number) \(.title)"' 2>/dev/null
done
Three rolls per invocation. Each /actionable run rolls the dice three times, producing three independent queries. Results are pooled, deduped against repos.jsonl, then filtered deterministically (competing PRs, maintainer responsiveness, hypothesis coverage, merge ceiling, AI policy).
Re-roll on empty. If a roll returns zero new repos (all already in roster or filtered out), re-roll that leg. Max 3 re-rolls per leg. If still empty, that leg produced nothing — move on.
No jitter, no weighting, no memory. The dice are uniform. The filter is deterministic. The exploration comes from the dice. The quality comes from the filter. They don't talk to each other.
When standing is high enough on a repo (3+ merged PRs, no warnings, no cooldown), the pipeline unlocks a new mode: run /bug-hunt on the repo blind — no issue required. Find bugs the maintainer doesn't know about, open the issue yourself, fix it yourself.
This is the endgame. The issue is your hypothesis. The PR is your fix. Your standing means the maintainer trusts your judgment about what's worth fixing.
Threshold: 3+ merged PRs on the repo, no active cooldown, no warnings in retro log. Check via drip queue history.
Process: spawn a /bug-hunt agent on the repo. If it finds something, open an issue with a reproducer, then file the fix as a separate PR linked to the issue. Same pipeline — issue-first — but you're creating the issue instead of claiming one.
Risk: this is exactly what got you banned on tinygrad — finding bugs without standing. The threshold gate prevents that. Don't skip it.
~/.sweep/repos.jsonl and ~/.sweep/retro-params/*.jsonl. Read ~/.sweep/banlist.txt — these repos are permanently banned. Never add, investigate, or re-add a banned repo. The banlist is human-edited only.repos.jsonl and candidates.jsonl.The roster grows. It shouldn't grow forever. Evict repos that aren't producing value.
Eviction triggers (check on every actionable tick):
| Trigger | Threshold | Action |
|---|---|---|
| No activity in 7 days | latest repos.jsonl entry for this repo > 7d old, no open PRs, no pending items | re-evaluate; if nothing changed upstream, evict |
| No merged PR in 30 days | last merge > 30d ago | evict |
| All issues KILLED or BLOCKED | zero PENDING or CONFIRMED items | evict |
| Cooldown active with no end date | permanent ban | evict |
| Three consecutive rejections | 3 closed-without-merge in a row | evict |
| Repo archived or deleted upstream | gh repo view fails | evict |
| Process depth downgraded to shallow | retro reclassified after rejections | evict |
Eviction means: status → evicted in repos.jsonl. Drip queue drains naturally (don't abandon open PRs). State files kept in ~/.sweep/repos/<owner>-<repo>/ for reference. The repo can be re-added manually with --add but doesn't come back automatically.
Soft eviction (demotion): repos that aren't evicted but aren't producing get deprioritized. If a repo has open issues but no progress in 14 days, it drops below new candidates in the ranking. It stays on the roster but stops getting agent time until something changes (new issue, maintainer activity, retro parameter update).
ready. No pending_review gate. Cold repos go straight to ready status. Eviction prunes repos that don't produce — the gate is downstream, not upstream.--dry-run reports changes without writing.Filter recent Hacker News for live threads on June's topics and hand him the list. Separately, flag the rare subset where work he has already done settles a specific quoted claim, and draft that comment as a plain argument with no link to his own writing. Use when June asks to check HN or find threads worth reading or commenting on.
Scan blog posts for AI writing tics and missed opportunities for human voice. Reports subtractions (AI patterns to remove) and additions (wordplay, arc, and claims to strengthen).
Poll June's Hacker News feeds, report what is new since the last run, and idempotently arm a background watch for replies to his comments. State persists in ~/Documents/sweep/ so it survives across sessions. Use when June asks what is new on HN, whether anyone replied, or to start watching a thread.
Argument-level compression by a strengthened absence test (does the argument stand with the same force, clarity, evidence, scope, pacing, and misreading-resistance?). Removes passages that fail it (self-referential cruft, cross-section restatement, self-recap, re-derivation, scaffolding, expired reader-orientation, stakes inflation, inert hedges, redundant examples); grafts good rhetoric onto an adjacent essential point rather than deleting. Idempotent. The structural cousin of /tighten (word-level) and /not-but (negation).
Audit a technical candidate's resume/CV by verifying its claims against the public contribution graph instead of taking the text at face value. Sorts every claim onto the self/peer/world attestation lattice, applies a cost-and-stake filter so cheap proxies (stars, downloads, backlinks) don't count, runs LIVE checks (GitHub, arXiv, package registries, CVEs), and reports two separate axes — merit (staked acceptance of the candidate's specific work) and attention (timestamped output) — plus a verifiability score in [0,1]. For technical recruiters and hiring managers. Invoke when given a candidate — a GitHub handle, a resume/CV, an arXiv author, a personal site — and asked to verify, audit, vet, or check their claims. Runs at two depths — a quick triage scan or a deep per-claim audit — and elicits which. Checks the provenance of a personal site or self-hosted resume (Internet Archive + git history) as an un-backdatable anti-tailoring anchor. Needs tool access (Bash/curl or WebFetch).
Find and defuse "not X but Y" / "isn't X; it's Y" / "X — not Y" constructions. Deterministic grep for detection (no LLM blind spot), the not-but subagent for triage. Split-or-cut tail negations ("X, not Y") aggressively — promote the point to its own sentence or delete it; recast in place only mid-clause "not X but Y" that genuinely can't be split; keep just the rare iconic thesis line literal.