Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add btspoony/mstar-harness --skill mstar-pr-loopgit clone --depth 1 https://github.com/btspoony/mstar-harnessWrote 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/btspoony/mstar-harness/mstar-pr-loop)<a href="https://agentmods.dev/skills/btspoony/mstar-harness/mstar-pr-loop"><img src="https://agentmods.dev/badge/skills/btspoony/mstar-harness/mstar-pr-loop/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/btspoony/mstar-harness/mstar-pr-loop"><img src="https://agentmods.dev/badge/skills/btspoony/mstar-harness/mstar-pr-loop.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.00046 | $0.01946 |
| Opus 5.5 | $0.00018 | $0.00778 |
| Sonnet 5.5 | $0.00009 | $0.00389 |
| Haiku 4.5 | $0.00005 | $0.00195 |
Grade A, and why
mstar-pr-loop 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 today.
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.
How it starts
The opening of the file, as written. The whole thing — 80 lines — stays where its author put it; the contents beside it link to each section on GitHub.
PR Review-Fix Loop
Load Order
mstar-harness-core— lifecycle and authorization authority.mstar-audit,prvariant →references/pr-review.md— review execution, re-review, verdict synthesis, posting and archival contracts.mstar-iteration→references/phase-4-5-pr-delivery.md§5.0 / §5.1a — iteration fix-worktree discipline and push cadence; §5.0 applies only to iteration Phase 5.mstar-branch-worktree— checkout authorization and the three-domain write table.mstar-dispatch-gates— Assignment fields, writable dispatch and leaf boundaries.
The project-manager orchestrates; implementers fix; review seats remain read-only. Loading the review variant does not authorize its seats to implement fixes.
Scope
Enter only on the user's explicit request to loop review → fix on an existing ready PR. This is not routine review or an automatic plan/iteration step.
- Resolve
pr:<n>preferentially, otherwise a branch with an open PR. If resolution fails or the PR is not ready, refuse with the actual cause and accepted forms:pr:<n>or a branch with an open, ready PR; supply that target or make the existing PR ready, then retry this entry. - Accept one optional tier:
quick,defaultordeep; otherwise use the review's own inference ladder (§ Review depth (tiers)), not a loop-specific default. - An optional user-supplied round budget has no default. Honor an explicit budget or interruption, retain the latest report and residuals, and name the user action needed to resume; never invent a numeric round ceiling.
The loop does not own CI babysitting, review-thread resolution or the merge-ready gate; those remain with iteration Phase 5 / its separately discovered babysit helper. Never submit APPROVE or REQUEST_CHANGES, merge a PR, or close a finding-capture issue. A deferred-PR tracking issue must still be closed through the existing closure authority at that PR's review completion (mstar-audit → references/pr-review.md § Batch sibling PRs). A ship it exit is review-loop success, not merge authorization or lifecycle Done.
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.
- today First seen · 80 lines · 46 tokens per session scan A c2c846b99364
mstar-pr-loop is a skill published in the GitHub repository btspoony/mstar-harness (65 stars, last pushed today), licensed MIT. It adds 46 tokens to every session and 1,946 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-23.
Other skills, from other repositories
comet-github-pr-review
A read-only review process for pull requests in Comet's GitHub repositories. A pull request is a proposed code change; the review checks its current code, related issue, comments, merge status, and automated checks.
code-review
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use…
comet-verify
Comet Phase 4: Verify and Close. Invoke with /comet-verify. Verify implementation matches design, handle development branch.
comet-review
A read-only review guide for checking the current Comet change, a managed software-change workflow. It focuses on correctness, security, and boundary problems without changing files or advancing the workflow.
finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup.
using-git-worktrees
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback.