drive
Skill185 starsChanged 5 months agoApache-2.0View on GitHub
Drive the Polis agent pipeline end-to-end from the terminal — list issues/PRs and their stage, create issues, apply any agent:* trigger label (plan / spec / code / fix / review), watch the Actions run, read review feedback, and merge — without touching the GitHub web UI. Use when the user wants to run, drive, advance, or check the Polis pipeline.
6 other projects use a version of this.
Adopted by
Most recently taken up by
- sidmanale643/pekka-bottheir own version, first seen Nov 8, 2026
- disler/mac-mini-agenttheir own version, first seen Oct 8, 2026
- HaipingShi/coderailtheir own version, first seen Jul 8, 2026
- hsigstad/research-kittheir own version, first seen Jul 5, 2026
- callmeradical/skillstheir own version, first seen Jun 11, 2026
- CodeWithBehnam/cc-docstheir own version, first seen Mar 15, 2026
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- disler/mac-mini-agent★ 272same name
- HaipingShi/coderail★ 8same name
- CodeWithBehnam/cc-docs★ 2same name
- sidmanale643/pekka-bot★ 2same name
- callmeradical/skills★ 0same name
- hsigstad/research-kit★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repositoryOne other file it gives its agents.
- CLAUDE.mdCLAUDE.md
The file
We split this skill into the rules it gives an agent
9 rules. 0 are common, 4 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
Ask the user what to do (AskUserQuestion) — offer the suggested next action first.
- Very specific: line 18
Run the chosen action via gh.
- Distinctive: line 19
If it triggered a run and the user wants, watch it.
- Distinctive: line 53
Always offer the on-demand review triggers too (next section).
- Very specific: line 57
All label changes: gh issue edit <n> --add-label "<label>" (remove with --remove-label).
- Very specific: line 76
Only the repo owner (or vars.PIPELINE_OWNER) can trigger the pipeline — if the user isn't the owner, applying a label will no-op in Actions.
- Very specific: line 113
Never apply pipeline-applied status labels (needs-human-review, tests-failing, arch-review, spec-review, agent:cap-reached, agent:failed) — …
- Very specific: line 116
Read-only commands (list/view/watch) need no confirmation.
- Distinctive: line 120
When the user is finished, summarize what was triggered this session (issues touched, labels applied, merges) and any runs still in …
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Drive the Polis pipeline
An interactive cockpit for the Polis pipeline. Run it as a loop: show the state panel →
the user picks an action → apply it via gh → (optionally) watch the run → refresh the panel.
The goal is to drive everything from Claude Code; the user never opens github.com. You only
trigger and report — the actual work runs in GitHub Actions (workflow "Agent Pipeline").
Loop
Repeat until the user says they're done:
- Render the State panel (below).
- Ask the user what to do (AskUserQuestion) — offer the suggested next action first.
- Run the chosen action via
gh. Confirm before any action that triggers a cloud run or merges. - If it triggered a run and the user wants, watch it; otherwise refresh the panel.
Step 0 — Preflight
command -v gh— if missing, tell the user to install it and stop.gh auth status— if not logged in, ask them to run! gh auth login, then re-check.- Resolve the repo:
gh repo view --json nameWithOwner -q .nameWithOwner(run from the repo, or pass--repo OWNER/NAME). Confirm it's a Polis repo before triggering anything —gh api repos/{owner}/{repo}/contents/scripts/pipeline.sh >/dev/nullmust succeed; if it doesn't, stop (wrong repo).
State panel
Build it from gh (read-only):
- Issues:
gh issue list --state open --json number,title,labels --limit 30. - PRs:
gh pr list --state open --json number,title,labels,headRefName,isDraft,reviewDecision --limit 30.
For each issue/PR show: number, title, current agent:* + status labels, the computed stage,
and the suggested next action from the stage graph below. Group by "needs you" (has a
status label awaiting a human) vs "in flight".
Stage graph (what to suggest next)
| Current signal | Stage | Suggested next |
| New issue, no PR, reads like a big idea | idea | agent:arch (plan) or agent:spec (single unit) |
arch-review label / open arch/* PR | arch drafted | agent:rearch (revise) or agent:decompose (make issues) |
| Generated issue, no spec PR yet | ready to spec | agent:spec |
spec-review label / draft agent/* PR with a spec | spec drafted | agent:respec (revise) or agent:code (implement) |
Open agent/* PR, needs-human-review, tests passing | code ready | review feedback → merge, or agent:fix |
PR with tests-failing | tests red | agent:fix (no comment = make tests pass) |
PR with agent:cap-reached | review loop capped | read verdicts → agent:fix, or re-run AI review with agent:code_review[:<profile>], or merge |
agent:failed | run errored | gh run view <id> --log-failed to see the error, fix the cause, then re-apply the original trigger label |
Always offer the on-demand review triggers too (next section).
Actions
All label changes: gh issue edit <n> --add-label "<label>" (remove with --remove-label).
The pipeline triggers on the labeled event, so adding the label is the trigger.
- Kick off from an idea:
gh issue create --title "<title>" --body "<idea>", then offeragent:archoragent:specon the new issue. - Planning:
agent:arch/agent:rearch/agent:decompose(on the parent issue). - Execution:
agent:spec/agent:respec/agent:code/agent:fix(on the generated issue). - On-demand review:
agent:code_review/agent:spec_review/agent:arch_review, optionally with a:<backend|profile>suffix. Read the valid suffixes frompolis.ymlso you only offer real ones: list backend names underbackends:(plus the built-inclaude) and profile names underreview_profiles:. (Read the file directly and parse it; if there is nopolis.yml, the only suffix isclaude.) Present them as a submenu. Note:agent:arch_review(underscore, a trigger) is different fromarch-review(hyphen, a pipeline status label) — don't conflate them. - Merge (terminal human gate): for a PR the user is satisfied with,
gh pr merge <n> --squash(ask squash/merge/rebase). Always confirm first — show the PR title + reviewDecision. - Escape hatch: apply or remove any arbitrary label the user names — except the pipeline status labels listed under Safety (those are outputs; applying them by hand corrupts state). If the user asks for one of those, decline and explain.
Only the repo owner (or vars.PIPELINE_OWNER) can trigger the pipeline — if the user isn't the
owner, applying a label will no-op in Actions; mention this if their runs don't start.
Watch a run
The labeled event starts a run of "Agent Pipeline". Runs are not tagged with the issue number and several can be in flight at once, so do NOT just watch the latest run — anchor on the moment you applied the label and confirm the matched run before watching:
BEFORE=$(date -u +%Y-%m-%dT%H:%M:%SZ)
gh issue edit <n> --add-label "<label>" # the trigger
ID=""
for _ in 1 2 3 4 5; do # allow a few seconds' lag for the run to appear
ID=$(gh run list --workflow "Agent Pipeline" --event issues \
--json databaseId,createdAt,displayTitle \
--jq "[.[] | select(.createdAt >= \"$BEFORE\")][0].databaseId // empty")
[[ -n "$ID" ]] && break
sleep 3
done
[[ -n "$ID" ]] && gh run watch "$ID" --exit-status || echo "run not found yet — check 'gh run list'"Show the matched run's displayTitle so the user can confirm it's theirs before watching. The
// empty keeps an empty result truly empty (never gh run watch null). Report success/failure;
on failure offer gh run view "$ID" --log-failed to surface the error.
Show review / PR feedback
To decide rearch/respec/fix/merge without leaving the terminal:
gh pr view <n> --json title,reviewDecision,comments,reviews \
--jq '{title, reviewDecision, reviews: [.reviews[] | {author: .author.login, state, body}], comments: [.comments[].body]}'Summarize the agent's review verdicts and any human comments, then suggest the next label.
Safety
- Confirm before applying a trigger label (it spends a cloud run) and before merging.
- Never apply pipeline-applied status labels (
needs-human-review,tests-failing,arch-review,spec-review,agent:cap-reached,agent:failed) — those are outputs, not triggers. - Removing the trigger label is unnecessary; the pipeline removes it itself at run start.
- Read-only commands (list/view/watch) need no confirmation.
Done
When the user is finished, summarize what was triggered this session (issues touched, labels applied, merges) and any runs still in progress they may want to check later.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

