agentleFS
paultyngpaultyng/skill-issue/skills/push-and-watch/SKILL.md

push-and-watch

Skill8 starsChanged 3 months agoMITView on GitHub

Push local commits to the remote, ensure a draft PR exists, and monitor the GitHub Actions run until completion. Use when the user says "push and watch", "push it", or asks to push and monitor CI.

  • Commits and pushes

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 9 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Verify the working tree is clean (git status).

    line 12
  2. Distinctive:

    Verify there are local commits ahead of the remote (git status should show "Your branch is ahead").

    line 13
  3. Distinctive:

    If the push fails (e.g. rejected, no access), stop and report the error.

    line 21
  4. Distinctive:

    Check whether a PR already exists for the current branch:

    line 27
  5. Distinctive:

    If no PR exists, create one in draft mode:

    line 33
  6. Distinctive:

    Wait a few seconds for CI to pick up the push, then list runs for the current branch:

    line 43
  7. Distinctive:

    If no run appears after 30 seconds of polling, report and stop.

    line 49
  8. Very specific:

    Use gh run watch <run_id> --exit-status to stream the run status until completion.

    line 53
  9. Distinctive:

    After the run completes, report:

    line 57
  10. Very specific:

    Failures: if any job failed, fetch its logs with gh run view <run_id> --log-failed and include the relevant error output (truncated to the …

    line 61
  11. Distinctive:

    If the run passed, report success concisely.

    line 63

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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

Push and Watch

Push local commits to the remote and monitor the CI run until completion.

1. Pre-flight Checks

  • Verify the working tree is clean (git status). If there are uncommitted changes, stop and ask.
  • Verify there are local commits ahead of the remote (git status should show "Your branch is ahead"). If not, report "nothing to push" and stop.

2. Push

git push -u origin HEAD

If the push fails (e.g. rejected, no access), stop and report the error.

3. Ensure Pull Request Exists

Skip this step if on main or master.

Check whether a PR already exists for the current branch:

gh pr view --json url 2>/dev/null

If no PR exists, create one in draft mode:

gh pr create --draft --fill

Report the PR URL.

4. Wait for Run

Wait a few seconds for CI to pick up the push, then list runs for the current branch:

gh run list --branch $(git branch --show-current) --limit 1

If no run appears after 30 seconds of polling, report and stop.

5. Watch

Use gh run watch <run_id> --exit-status to stream the run status until completion.

6. Report

After the run completes, report:

  • Status: passed or failed
  • Jobs: list each job with its status and duration
  • Failures: if any job failed, fetch its logs with gh run view <run_id> --log-failed and include the relevant error output (truncated to the last 50 lines per failed job)

If the run passed, report success concisely. If it failed, include enough log context to diagnose the failure.

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.