agentleFS
Sign inStart free
aicodekingaicodeking/deepseek-stack/skills/ds-watch-pr/SKILL.md

ds-watch-pr

Skill80 starsChanged 15 days agoMITView on GitHub

Watches a pull request through CI and review, fixes real findings and stops when it is ready, merged or blocked. Use when the user asks to watch, monitor or babysit a PR, or /ds-watch-pr.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep one PR moving until it is green and reviewed, with as little noise as possible.

    line 6
  2. Distinctive:

    Start the watcher. Run it in the harness's background or monitor tool if it has one, so each line wakes you.

    line 19
  3. Very specific:

    If the base branch moved or the branch is behind, rebase, push with --force-with-lease and restart.

    line 24
  4. Distinctive:

    Before you call the PR ready, git fetch and read the PR again.

    line 25
  5. Distinctive:

    When an event needs no action, say nothing.

    line 37
  6. Distinctive:

    Keep the PR small. Prefer fixes that delete or narrow code.

    line 39

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Keep one PR moving until it is green and reviewed, with as little noise as possible.

The watcher is scripts/watch_pr.py in this skill's folder. Call it by absolute path. It needs python3 and a logged-in gh.

python3 <skill>/scripts/watch_pr.py <pr> [--repo owner/name] [--until ready|green|any] [--interval 30] [--max-minutes 60]

It prints one line per new check failure, finished check run, comment or review, then a final stop: line. Exit 0 means the condition is met or the PR merged. Exit 1 means you must act. Exit 2 means bad input. ready waits for green checks, a mergeable branch and no change request. green waits for checks only.

Steps

  1. Handle what already exists: failed checks and comments newer than the last push.
  2. Start the watcher. Run it in the harness's background or monitor tool if it has one, so each line wakes you. Otherwise run it as one long foreground command.
  3. On each event, read the source before you change code. Decide if the finding is real.
  4. For a real bug or CI failure: make the smallest fix, run the failing check locally, push, then restart the watcher.
  5. For a false positive or out-of-scope request: reply with a short reason through ds-pr-comments, resolve the thread and list it as a follow-up.
  6. Tell real test failures apart from infrastructure flakes. Re-run a flake once before you call it a flake.
  7. If the base branch moved or the branch is behind, rebase, push with --force-with-lease and restart.
  8. Before you call the PR ready, git fetch and read the PR again. It must not be BEHIND or DIRTY.

Stop when

  • The watcher exits 0. Report the PR as ready, or merged.
  • Five fix-and-push cycles pass without exit 0. Report what still fails.
  • Another PR makes this one obsolete. Stop and ask before closing it.
  • gh reports a rate limit. Check gh api rate_limit and wait for the reset once. Do not loop.

Rules

  • One watcher per PR. Never write your own sleep or polling loop.
  • When an event needs no action, say nothing. No "still waiting" messages.
  • Merge only if the user asked for it. Otherwise report ready.
  • Keep the PR small. Prefer fixes that delete or narrow code.

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.

Check your setup, free