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 nanasess/eccube-dev-agents --skill validate-reviewgit clone --depth 1 https://github.com/nanasess/eccube-dev-agentsWrote 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/nanasess/eccube-dev-agents/validate-review)<a href="https://agentmods.dev/skills/nanasess/eccube-dev-agents/validate-review"><img src="https://agentmods.dev/badge/skills/nanasess/eccube-dev-agents/validate-review.svg" alt="Measured on agentmods" 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.00017 | $0.02318 |
| Opus 5 | $0.00009 | $0.01159 |
| Sonnet 5 | $0.00003 | $0.00464 |
| Haiku 4.5 | $0.00002 | $0.00232 |
Grade A, and why
validate-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 7d 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 — 187 lines — stays where its author put it; the contents beside it link to each section on GitHub.
レビューコメントの妥当性検証
GitHub PR のレビューコメントを取得し、対象コードを確認して指摘の妥当性を判断します。
この Skill は GitHub への書き込み(返信・投稿)を一切行いません。 返信は確認後に /eccube-dev-agents:reply-review でまとめて投稿します。
引数パターン
$ARGUMENTS に応じて対象を決定する:
| パターン | 引数 | 対象 |
|---|---|---|
| A | なし | 現在ブランチの PR のレビューコメントすべて |
| B | PR URL (.../pull/{n}) または PR 番号 |
その PR のレビューコメントすべて |
| C | レビューコメント URL (.../pull/{n}#discussion_r{id}) |
指定された 1 件のみ |
判定は URL に #discussion_r が含まれるかで行う。含まれない場合は「コメント指定なし」= 全件検証。
1. 対象 PR の特定
パターン A(引数なし)
gh pr view --json number,url,title,headRefName,baseRefName,state
gh repo view --json nameWithOwner
- 現在ブランチに紐づく PR が存在しない場合は、その旨を報告して終了(勝手に PR を作成しない)
- 複数リポジトリ構成の場合は先に
pwdとgit remote -vで対象リポジトリを確認する
パターン B / C(URL または PR 番号)
- URL から
owner,repo,pr_number, (あれば)comment_idを正規表現で抽出 - PR 番号のみが渡された場合は
gh repo view --json nameWithOwnerでowner/repoを補完
2. レビューコメントの取得
パターン A / B(全件)
レビュースレッド単位で取得し、解決状態と返信状況を把握する:
gh api graphql -f query='
query($owner:String!, $repo:String!, $pr:Int!) {
repository(owner:$owner, name:$repo) {
pullRequest(number:$pr) {
reviewThreads(first:100) {
nodes {
isResolved
isOutdated
path
line
comments(first:50) {
nodes { databaseId url author { login } body createdAt }
}
}
}
}
}
}' -f owner={owner} -f repo={repo} -F pr={pr_number}
コメント本文が長く切り詰められる場合や diff_hunk が必要な場合は、REST でも取得する:
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --paginate
検証対象の切り分け(すべて一覧に載せ、スキップしたものも理由を明記する):
- 検証する: 未解決(
isResolved: false)のスレッドの先頭コメント - スキップ:
isResolved: trueのスレッド(解決済み) - スキップ: 投稿者が PR 作成者自身のコメント(自分の返信)
- 文脈として読むのみ: スレッド内の 2 件目以降の返信(既に議論済みの内容を再指摘しない)
isOutdated: trueのスレッドは「該当コードが変更済み」の可能性があるため、現行コードとの差異を判定理由に明記する
パターン C(単一)
gh api repos/{owner}/{repo}/pulls/comments/{comment_id}
いずれの場合も以下を抽出:
body: コメント本文(指摘内容)path: 対象ファイルパスdiff_hunk: 対象コードの差分line/original_line: 行番号commit_id: コメント対象のコミット SHAuser.login/author.login: コメント投稿者html_url: コメント URL(報告と reply-review での参照に使う)
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.
- 7d ago First seen · 187 lines · 17 tokens per session scan A 95813662aaef
validate-review is a skill published in the GitHub repository nanasess/eccube-dev-agents (2 stars, last pushed 1mo ago), licensed MIT. It adds 17 tokens to every session and 2,318 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
a0-review-plugin
Full audit of Agent Zero plugins in usr/plugins/. Reviews manifest validity, directory structure, code patterns (Store Gating, notifications, imports), security, and duplicate detection against the community index. Use when asked to review, audit, validate, or check an existing plugin before using or contributing it.
execution-grounded-review
Execution-grounded review: run tests first, trace each acceptance criterion to execution evidence. Use when verifying an implementation meets spec.
dry-consolidation
Find and extract duplicated code into shared abstractions. Use when seeing repeated utilities, copy-pasted components, duplicated hooks, or boilerplate repeated across files.
adversarial-review
Adversarial second-pass review that tries to break code, designs, plans, or ADRs. Use when stakes are high and a normal review already ran.
code-antipatterns
Analyze a codebase for anti-patterns using ast-grep. Use when finding magic numbers, console.logs, var usage, excessive any, eval/innerHTML security issues, or deep nesting.
ast-grep-search
Find and replace code patterns structurally with ast-grep. Use when matching code by AST structure, finding functions with specific signatures, or detecting anti-patterns regex cannot match.