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/sublimecoder/aios/github-deep-reviewnpx skills add sublimecoder/aios --skill github-deep-reviewgit clone --depth 1 https://github.com/sublimecoder/aiosWhat 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.00026 | $0.01269 |
| Opus 5 | $0.00013 | $0.00634 |
| Sonnet 5 | $0.00005 | $0.00254 |
| Haiku 4.5 | $0.00003 | $0.00127 |
Grade A, and why
github-deep-review 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 yesterday.
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 — 125 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GitHub Deep Review
Review rigorously: high-confidence, evidence-first, code-aware, and willing to say "not proven" when the trail is weak. The goal is not a generic summary. The goal is to understand the bug class, find the real cause if possible, decide the best fix after reading enough code, and call out whether a larger refactor would improve the design.
Start
Use gh, not web browsing, for GitHub refs:
gh issue view <n> --json number,title,state,author,body,comments,labels,updatedAt,url
gh pr view <n> --json number,title,state,author,body,comments,reviews,files,commits,statusCheckRollup,mergeStateStatus,headRefName,headRepositoryOwner,url
gh pr diff <n> --patch
Treat every author uniformly. For PRs, collect author context by default from the gh JSON above — you already have the author login, PR history, and commit list. When it helps the review, pull prior contributions with gh api users/<login> or gh search prs --author <login> --repo <owner>/<repo>, and include a short Author context: block near the top of the review.
For repo-local review, also inspect:
git status --short --branch
git fetch origin
git log --oneline --decorate -20
rg "<key symbol/error/config/endpoint>"
If the repo has local instructions, issue/PR skills, docs lists, test guidance, or maintainer runbooks, read those before deciding.
Review Contract
Always answer these, explicitly:
- URL/ref: issue or PR number and affected surface.
- What is the bug or behavior being fixed?
- Can we identify the root cause? If yes, where in code and why. If no, what evidence is missing.
- For regressions, who/what introduced it and when? Include commit/PR provenance when traceable by bounded history; say unknown instead of guessing.
- Is the current/proposed fix the best possible fix after reading adjacent code?
- Would a bigger refactor improve correctness, clarity, or future maintainability?
- What proof exists: tests, live repro, CI checks, docs, dependency docs/source, shipped/current behavior.
- What remains risky or unverified.
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.
- yesterday First seen · 125 lines · 26 tokens per session scan A 0b6187b2ad58
github-deep-review is a skill published in the GitHub repository sublimecoder/aios (2 stars, last pushed 1mo ago), licensed MIT. It adds 26 tokens to every session and 1,269 once invoked, about $0.0001 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
pos-verify
Use this immediately after files are created, edited, moved, deleted, or materially rewritten inside PersonalOS. Verifies that new truth was routed to the correct owner, written in the correct file shape, and still follows POS conventions. Do NOT use for whole-vault deep audits; use system-health-check.
skillify
Use this when {{username}} asks to skillify a repeated workflow, determine whether it deserves a reusable PersonalOS skill, or harden an existing workflow into a tested resolver-reachable capability. Do NOT use for one-off notes, ordinary execution, or already-specified skill authoring; use write-skill.
write-skill
Use this when the user wants to create a new shared PersonalOS skill under skills/ or revise a specified PersonalOS skill and the scope is already clear. Do NOT use for raw workflow capture or deciding whether work should become a skill; use skillify first. Do NOT use for repo-local or agent-local skills unless…
priority-dashboard
Use this to rebuild, inspect, or temporarily steer {{username}}'s current PersonalOS priority dashboard from canonical Actions, Attention Triggers, and owner context. Do NOT use it to create, complete, or independently manage tasks; use task-manager for Action and Trigger lifecycle changes.
lint-brain
Run health checks over the brain vault - find orphan notes, broken wikilinks, missing frontmatter, stale projects, and missing cross-links. Use when asked to "lint the brain", "health check", "vault hygiene", or "/lint-brain".
ingest-article
Ingest an article from a URL or raw text into the brain vault. Extracts key knowledge, determines placement, creates or updates notes, and links to relevant projects. Use when the user shares a URL or text and wants to absorb it into their knowledge base.