Borrowing it
Nothing to install: this file belongs to julien777z/code-review-action. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/julien777z/code-review-action/main/.agents/skills/ci-watch/SKILL.mdgit clone --depth 1 https://github.com/julien777z/code-review-actionWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/julien777z/code-review-action/ci-watch)<a href="https://agentmods.dev/skills/julien777z/code-review-action/ci-watch"><img src="https://agentmods.dev/badge/skills/julien777z/code-review-action/ci-watch/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/julien777z/code-review-action/ci-watch"><img src="https://agentmods.dev/badge/skills/julien777z/code-review-action/ci-watch.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00063 | $0.01133 |
| Opus 5 | $0.00032 | $0.00566 |
| Sonnet 5 | $0.00013 | $0.00227 |
| Haiku 4.5 | $0.00006 | $0.00113 |
Grade A, and why
ci-watch scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
100% identical to ci-watch — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 46 lines — stays where its author put it; the contents beside it link to each section on GitHub.
CI Watch
Monitor a pull request through the delayed-review window and act on valid feedback instead of merely reporting it.
Workflow
- Resolve the pull request from an explicit number or URL, or from the current branch and repository. If the current branch is the repository default branch and changes are needed, create a new work branch before editing; after making and verifying changes, commit, push, create a PR if one does not already exist for that branch, then poll CI for that PR. If the current non-default branch has no PR, inspect open PRs and local branch relationships; ask only if multiple candidates remain plausible.
- Record a baseline containing the head SHA, review submissions, conversation comments, inline review threads, resolution state, and latest finding timestamp. Prefer thread-aware GitHub reads so duplicate, outdated, and resolved findings are distinguishable.
- Check and investigate existing review threads, comments, and issue/PR conversation items as part of the baseline, not only new findings. Classify each unresolved or recently-updated item as legitimate, duplicate, already fixed, stale/outdated, ambiguous, or incorrect before deciding whether the watch can be quiet.
- Start a 15-minute quiet timer from the most recent finding, from the latest baseline item that still needs investigation, or from the baseline check when no findings exist.
- Poll every 30–60 seconds while checks are pending, failing, or review threads remain unresolved. If all GitHub checks are green and all review findings are resolved or outdated, treat the PR as merge-ready and stop the watch loop immediately; do not do extra quiet-window polling or a final boundary poll.
- On every existing, new, or updated finding:
- Reset the quiet timer.
- Read the cited code and relevant surrounding behavior.
- Classify it as legitimate, duplicate, already fixed, stale/outdated, ambiguous, or incorrect.
- Fix legitimate issues with the smallest behaviorally complete change.
- Run focused checks proportional to the change.
- Commit and push verified fixes to the PR branch promptly. Re-read remote state before pushing if the branch changed concurrently.
- Resolve review threads that are fixed, stale/outdated, duplicates, false positives, not applicable, or otherwise incorrect; leave ambiguous or still-actionable threads unresolved.
- After every push, restart the 15-minute quiet timer from the push time and continue polling because new automated reviews may target the new commit.
- Stop the watch loop when the PR is ready to merge: either all available code-review bots approve or report no findings, or the only remaining review items are unactionable, false positives, stale/outdated, or otherwise incorrect and GitHub checks are green. For cleanup-only feedback, apply the counted-review-round completion rule:
- A round counts only after every review/check for its head finishes, or after the full 15-minute quiet window expires and a boundary poll captures all findings available at that time. Never count a still-pending review before that boundary.
- Stop after two consecutive counted review rounds (three at most) contain only code-simplification suggestions and no correctness bugs. Do not keep pushing cleanup solely to trigger another review round.
- Fully investigate every finding in the final counted round and fix every legitimate one. If any correctness bug appears, reset the cleanup-only streak and review the resulting head under this rule.
- Use the 15-minute quiet window only while checks/reviews are still not fully settled; do not apply it after the PR is green and merge-ready.
- After the watch loop stops in a merge-ready state, run the repo-local code-simplifier/code-simplify pass across the PR diff. Investigate and fix legitimate simplification or maintainability issues it finds, preserve unrelated changes, run focused checks, then commit and push any verified fixes.
- After the post-watch code-simplifier push, perform one final CI/review poll for the updated PR head. Apply the counted-review-round completion rule from step 8: a pending bot review is not a final result, so keep polling until it finishes or the full 15-minute quiet window expires and a boundary poll completes. Address legitimate new failures or findings with the same rules above; if no changes were made by the code-simplifier pass, do the final poll against the existing head.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 46 lines · 63 tokens per session scan A ed7650ef771e
ci-watch is a skill published in the GitHub repository julien777z/code-review-action (2 stars, last pushed 4d ago), licensed MIT. It adds 63 tokens to every session and 1,133 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to ci-watch, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
review-implement-phase
Implements triaged review actions, commits focused fixes, and posts Done plus resolves threads. Use when the user wants only the implementation phase of the review-framework workflow.
engram-branch-pr
PR creation workflow for Engram following the issue-first enforcement system. Trigger: When creating a pull request, opening a PR, or preparing changes for review.
verify-behavior
Verify or reproduce visible product behavior by driving the real UI with pi-computer-use's checked tools, requiring verified expect postconditions and durable state evidence for meaningful UI flows. Use when triage needs visual reproduction, implementation needs behavioral proof, review needs interactive confirmation…
github-contributor
End-to-end playbook for shipping high-quality pull requests to open-source projects you don't maintain — discovery, CONTRIBUTING compliance, PR-size check, minimal-diff implementation, PR description with AI-assisted disclosure, conflict resolution, and post-submission maintainer interaction. Use whenever creating…
revdiff
Review diffs, files, and documents with inline annotations in a TUI overlay, or answer questions about revdiff usage, configuration, themes, and keybindings. Opens revdiff in agterm/tmux/zellij/herdr/kitty/wezterm/cmux/ghostty/iterm2/emacs-vterm, captures annotations, and addresses them. Works in git, hg, and jj repos…
write-pr
Reference standards for writing pull request titles and descriptions in the tldraw repository, plus the pre-flight comment sweep over the diff. Use as supporting guidance when another skill or workflow needs PR content standards, not as the user-facing create/update PR workflow.