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 agentmods add skills/mfmezger/ai_agent_dotfiles/github-pr-feedbacknpx skills add mfmezger/ai_agent_dotfiles --skill github-pr-feedbackgit clone --depth 1 https://github.com/mfmezger/ai_agent_dotfilesWhat 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 | $0.00088 | $0.01710 |
| Opus 5 | $0.00044 | $0.00855 |
| Sonnet 5 | $0.00018 | $0.00342 |
| Haiku 4.5 | $0.00009 | $0.00171 |
Grade A, and why
github-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 3d 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 — 198 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GitHub PR Feedback Triage
Turn GitHub pull request feedback into a concise, defensible markdown triage report. The goal is to help the user decide which comments require code changes and which can be safely declined, deferred, or answered without changing code.
Review Lens
Always keep the karpathy-guidelines skill in mind when judging PR feedback.
Bias toward simple, surgical fixes with clear success criteria:
- Do not accept feedback that adds speculative abstractions, broad refactors, or configurability the PR does not need.
- Do not reject feedback that identifies a concrete bug, unclear assumption, or missing verification just because the fix is inconvenient.
- Prefer the smallest code or documentation change that resolves the reviewer concern.
- Surface uncertainty directly in the reasoning instead of pretending the answer is more certain than the evidence supports.
Prerequisites
- Use
ghwhen feedback must be fetched from GitHub. ghmust be installed and authenticated for live PR access.- Run bundled Python scripts with
uv runwhen available. Useuvxonly for external Python command-line tools; this skill's local helper script should be run withuv run. - If the user pasted the feedback directly, do not fetch from GitHub unless they ask you to verify the current PR state.
Input Sources
Prefer the most direct available input:
- Pasted feedback in the conversation.
- A PR URL or PR number provided by the user.
- The PR associated with the current branch.
If no PR or feedback is available, ask the user for either a PR URL/number or the feedback text.
Fetching GitHub Feedback
Prefer the bundled fetch script because it collects the PR summary, top-level comments, reviews, inline review comments, review thread resolution state, file list, and checks in one repeatable command.
Run the bundled fetch script with uv run:
uv run scripts/fetch_pr_feedback.py <pr-url-or-number> --out /tmp/pr-feedback.json --summary
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.
- 3d ago First seen · 198 lines · 88 tokens per session scan A a2e60cca9fe8
github-pr-feedback is a skill published in the GitHub repository mfmezger/ai_agent_dotfiles (5 stars, last pushed 1mo ago), licensed MIT. It adds 88 tokens to every session and 1,710 once invoked, about $0.0004 per session on Opus 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-08-31.
Other skills, from other repositories
embedded-dev
Use when developing firmware on ESP32/STM32/RP2040/nRF52, experiencing DMA overflow, SPI timeout, LCD blank display, frame corruption, GPIO conflicts, sensor reading errors, Wi-Fi disconnect, or needing driver configuration, hardware debugging, display/GUI setup, protocol implementation, serial monitoring. Use even if…
embedded-dev
Guide for embedded systems development on ESP32, STM32, RP2040, nRF52 chips. Use this skill whenever the user mentions embedded systems, firmware development, MCU programming, hardware drivers, sensors, LCD displays, IMU devices, SPI/I2C/UART interfaces, compilation, debugging, remote monitoring, Wi-Fi/BLE/MQTT…
embedded-gui-feedback
Use for LCD/GUI projects after verification passes - captures display via camera, analyzes layout/font/color, detects display issues.
embedded-verification
Use after implementation complete - runs build-flash-monitor loop, verifies runtime behavior, no completion claims without fresh evidence.
embedded-brainstorming
Use before any embedded development - explores hardware requirements, confirms configuration, validates feasibility, saves design spec.
embedded-driver-design
Use when hardware configuration confirmed - creates detailed implementation plan with bite-sized tasks, exact file paths, complete code steps.