agentleFS
permit0-aipermit0-ai/permit0/.claude/skills/drive/SKILL.md

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

  • Other versions6 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 6

    1. disler/mac-mini-agent★ 272same name
    2. HaipingShi/coderail★ 8same name
    3. CodeWithBehnam/cc-docs★ 2same name
    4. sidmanale643/pekka-bot★ 2same name
    5. callmeradical/skills★ 0same name
    6. 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.

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
  1. Distinctive:

    Ask the user what to do (AskUserQuestion) — offer the suggested next action first.

    line 17
  2. Very specific:

    Run the chosen action via gh.

    line 18
  3. Distinctive:

    If it triggered a run and the user wants, watch it.

    line 19
  4. Distinctive:

    Always offer the on-demand review triggers too (next section).

    line 53
  5. Very specific:

    All label changes: gh issue edit <n> --add-label "<label>" (remove with --remove-label).

    line 57
  6. Very specific:

    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.

    line 76
  7. Very specific:

    Never apply pipeline-applied status labels (needs-human-review, tests-failing, arch-review, spec-review, agent:cap-reached, agent:failed) — …

    line 113
  8. Very specific:

    Read-only commands (list/view/watch) need no confirmation.

    line 116
  9. Distinctive:

    When the user is finished, summarize what was triggered this session (issues touched, labels applied, merges) and any runs still in …

    line 120

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

  1. Render the State panel (below).
  2. Ask the user what to do (AskUserQuestion) — offer the suggested next action first.
  3. Run the chosen action via gh. Confirm before any action that triggers a cloud run or merges.
  4. 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/null must 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 signalStageSuggested next
New issue, no PR, reads like a big ideaideaagent:arch (plan) or agent:spec (single unit)
arch-review label / open arch/* PRarch draftedagent:rearch (revise) or agent:decompose (make issues)
Generated issue, no spec PR yetready to specagent:spec
spec-review label / draft agent/* PR with a specspec draftedagent:respec (revise) or agent:code (implement)
Open agent/* PR, needs-human-review, tests passingcode readyreview feedback → merge, or agent:fix
PR with tests-failingtests redagent:fix (no comment = make tests pass)
PR with agent:cap-reachedreview loop cappedread verdicts → agent:fix, or re-run AI review with agent:code_review[:<profile>], or merge
agent:failedrun erroredgh 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 offer agent:arch or agent:spec on 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 from polis.yml so you only offer real ones: list backend names under backends: (plus the built-in claude) and profile names under review_profiles:. (Read the file directly and parse it; if there is no polis.yml, the only suffix is claude.) Present them as a submenu. Note: agent:arch_review (underscore, a trigger) is different from arch-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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.