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 krzysztofsurdy/code-virtuoso --skill pr-feedbackgit clone --depth 1 https://github.com/krzysztofsurdy/code-virtuosoWrote 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/krzysztofsurdy/code-virtuoso/pr-feedback)<a href="https://agentmods.dev/skills/krzysztofsurdy/code-virtuoso/pr-feedback"><img src="https://agentmods.dev/badge/skills/krzysztofsurdy/code-virtuoso/pr-feedback/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/krzysztofsurdy/code-virtuoso/pr-feedback"><img src="https://agentmods.dev/badge/skills/krzysztofsurdy/code-virtuoso/pr-feedback.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.00053 | $0.01449 |
| Opus 5.5 | $0.00021 | $0.00580 |
| Sonnet 5.5 | $0.00011 | $0.00290 |
| Haiku 4.5 | $0.00005 | $0.00145 |
Grade A, and why
pr-feedback 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 2d 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.
How it starts
The opening of the file, as written. The whole thing — 95 lines — stays where its author put it; the contents beside it link to each section on GitHub.
PR feedback
A reviewer left comments and CI is red. The job is to get the PR to a state where every comment has an honest answer and every check passes, without agreeing by reflex and without gaming the pipeline. Treat each comment as a claim to test against the code, not an order.
Never resolve a thread you did not address. Never go green by skipping or deleting tests.
Procedure
- Collect. Fetch unresolved review threads and check status in one pass. Commands for
gh(GitHub) andglab(GitLab) are in commands. Note the PR head commit so replies can cite it later. - Triage. Put every unresolved thread into one bucket (table below). Write the bucket and a one-line reason before touching code.
- Fix CI first if it blocks review. A red pipeline hides new problems, so reproduce failures locally (see below) before or alongside comment fixes.
- Fix with tests. For each "agree" comment, change the code and add or update a test that would have caught the issue. Keep one commit per concern so replies can point at a single SHA.
- Verify. Run the project's lint, type check, and tests locally. Apply
verification-before-completion: only output from this session counts. - Push and reply. Push, then reply on each thread with what changed and the commit SHA. Resolve a thread only when you addressed it and the host's convention is that the author resolves.
- Loop. Wait for CI, re-fetch threads and checks. New comments or new failures restart at step 1. Stop when all checks pass and no thread is unanswered, or when you are blocked (see below).
Triage buckets
| Bucket | When | What to do |
|---|---|---|
| Agree and fix | The comment is correct, or the risk is real and cheap to remove | Fix, add a test, reply with the change and SHA |
| Disagree | The suggestion is wrong, out of scope, or breaks a constraint the reviewer may not know | Reply with the technical reason and evidence (code path, test, doc). Offer an alternative or a follow-up ticket. Leave the thread open for the reviewer |
| Needs clarification | The intent is unclear, or two readings lead to different fixes | Ask one specific question. Do not guess and implement |
| Already done | The code already handles it or an earlier commit fixed it | Point to the line or SHA |
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 2d ago First seen · 95 lines · 53 tokens per session scan A 9d531146f095
pr-feedback is a skill published in the GitHub repository krzysztofsurdy/code-virtuoso (36 stars, last pushed yesterday), licensed MIT. It adds 53 tokens to every session and 1,449 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-22.
Other skills, from other repositories
specification-compliance-review
Use this skill when an implementation is described as partial, passing, or complete and the task is to determine whether it actually satisfies an explicit specification. This is not a generic code review and not a re-run of the test suite. The central question is: does every normative requirement have both a correct…
code-review
Review .NET changes for bugs, regressions, architectural drift, missing tests, incorrect async or disposal behavior, and platform-specific pitfalls before you approve or merge them. USE FOR: reviewing a pull request or patch in a .NET repository; checking for behavioral regressions, API misuse, or missing tests…
pre-pr-audit
Pre-PR confidence audit with 5-dimension scoring. Use when: final check before commit/push/PR, evaluating PR readiness, assessing test quality + risk + coverage holistically. Triggers: pre-pr, readiness check, confidence audit, final verification, ready to PR, how confident. Not for: code review (use…
vibe-spec-sync
Keeps specification documents and code in agreement. Audit mode finds every divergence when an implementation is claimed complete; sync mode detects spec drift in staged changes and updates the spec after user approval, so each commit is a reconciled snapshot of spec, tests, and code. Use when an implementation is…
vibe-gap-analysis
Assesses production readiness or audits a codebase against its specs. Supports quick static mode, deep 17-dimension audit, or single-dimension focus. Use before a production launch, after a major refactor, when inheriting a codebase, or when someone asks how done the project is.
walkthrough
Generate a Phase-2 Walkthrough artifact (walkthrough.md) once implementation and verification are complete. Captures a Change Summary, Verification Steps (commands + unit tests + automated browser testing outcomes), Visual Proof (screenshots/recordings embedded directly in the file), and a Review Gate (final diff + PR…