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 kyto64/codex-pr-review-toolkit-minimal --skill pr-test-analyzergit clone --depth 1 https://github.com/kyto64/codex-pr-review-toolkit-minimalWrote 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/kyto64/codex-pr-review-toolkit-minimal/pr-test-analyzer)<a href="https://agentmods.dev/skills/kyto64/codex-pr-review-toolkit-minimal/pr-test-analyzer"><img src="https://agentmods.dev/badge/skills/kyto64/codex-pr-review-toolkit-minimal/pr-test-analyzer/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/kyto64/codex-pr-review-toolkit-minimal/pr-test-analyzer"><img src="https://agentmods.dev/badge/skills/kyto64/codex-pr-review-toolkit-minimal/pr-test-analyzer.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.00025 | $0.00811 |
| Opus 5.5 | $0.00010 | $0.00324 |
| Sonnet 5.5 | $0.00005 | $0.00162 |
| Haiku 4.5 | $0.00003 | $0.00081 |
Grade A, and why
pr-test-analyzer 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 1mo 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.
What it actually says
PR Test Analyzer
新規・変更機能に対するテストの質とギャップをレビューする。行カバレッジの数値ではなく behavioral coverage（振る舞いと契約がテストされているか、回帰を捕まえられるか）を見る。pr-review の test-coverage 観点として使う。
レビュー手順
- PR の変更内容を読み、新規・変更された振る舞いを列挙する
- 対応するテストを読み、振る舞いとテストをマッピングする
- 壊れたら本番障害につながる未テスト経路を特定する
- テストの質を評価する（下記）
- 既存の統合テストでカバー済みの経路を除外する
ギャップの重点チェック
- エラーハンドリング経路（サイレント障害の温床）
- 境界値・バリデーションの negative case
- 重要なビジネスロジック分岐
- 非同期・並行の挙動（該当する場合）
- 統合ポイント（外部 API、DB、他モジュールとの境界）
テストの質チェック
ギャップだけでなく、既存テストの brittleness も指摘対象。
- 実装詳細ではなく振る舞い・契約をテストしているか
- 妥当なリファクタリングに耐えるか（実装が変わっただけで落ちるテストは brittle）
- 将来のコード変更による意味のある回帰で実際に落ちるか
- テスト名・構成が何を検証しているか読み取れるか
重要度の目安
| 状況 | 重要度 |
|---|---|
| データ損失・セキュリティ・重大障害を見逃す | P0–P1 |
| ユーザー向けエラーや重要ロジックの欠落、brittle で回帰を捕まえないテスト | P1 |
| エッジケース・混乱を招く欠落 | P2 |
| completeness のための軽微な追加 | P3（除外） |
出力
### P1: [タイトル]
- File: `path/to/source.ts` (and `path/to/test.ts` if applicable)
- Lines: N-M
- Category: test-coverage
- Problem: [何がテストされていないか / なぜ brittle か]
- Impact: [このテストがあれば防げる障害・回帰の具体例]
- Suggested test: [何を入力し、何を検証するテストか具体的に]
ルール
- DO: 各 Finding に「このテストが防ぐ具体的な障害」を書く（書けないなら指摘しない）
- DO: 追加コストと得られる価値のバランスを考慮する
- DO: よくテストされている部分は短く肯定的に言及してよい
- DO NOT: getter/setter 等の自明なコードにテストを要求する
- DO NOT: 100% カバレッジやメトリクスを目的にした指摘をする
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.
- 1mo ago First seen · 63 lines · 25 tokens per session scan A 200568b9df74
pr-test-analyzer is a skill published in the GitHub repository kyto64/codex-pr-review-toolkit-minimal (1 stars, last pushed 3mo ago), licensed Apache-2.0. It adds 25 tokens to every session and 811 once invoked, about $0.0001 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-08-31.
Other skills, from other repositories
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…
vibe-quality-loop
Runs the Implement→Review→Test→Fix cycle until the work is actually clean, with evidence. Use after any non-trivial implementation and before claiming it is done.