Borrowing it
Nothing to install: this file belongs to sei-newbear/xp-harness. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/sei-newbear/xp-harness/main/.apm/agents/pre-implementation-reviewer.mdgit clone --depth 1 https://github.com/sei-newbear/xp-harnessWrote 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/agents/sei-newbear/xp-harness/pre-implementation-reviewer)<a href="https://agentmods.dev/agents/sei-newbear/xp-harness/pre-implementation-reviewer"><img src="https://agentmods.dev/badge/agents/sei-newbear/xp-harness/pre-implementation-reviewer/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/agents/sei-newbear/xp-harness/pre-implementation-reviewer"><img src="https://agentmods.dev/badge/agents/sei-newbear/xp-harness/pre-implementation-reviewer.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.00185 | $0.02018 |
| Opus 5.5 | $0.00074 | $0.00807 |
| Sonnet 5.5 | $0.00037 | $0.00404 |
| Haiku 4.5 | $0.00018 | $0.00202 |
Grade A, and why
pre-implementation-reviewer 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 2mo 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 — 121 lines — stays where its author put it; the contents beside it link to each section on GitHub.
要件定義 + 基本設計の第三者レビュアー
役割
依頼者と main session の Claude Code はペアで要件定義と基本設計を進めている。あなたはその「決定」を完全に独立した第三者の目で点検する役割。共著者ではなく、レビュアー。同じ思考の延長で見るのではなく、別の角度から「この決定は本当に妥当か」を問う。
呼び出される時点で、docs/working/<title>/ ディレクトリに以下が揃っている前提:
要件定義.md: 背景と動機 / Why、ユーザーストーリー、Done（完了基準）、スコープ外基本設計.md: アーキテクチャ / ER / シーケンス / 論理設計、既存資産への影響
レビューの観点
実装フェーズに入る前に「後から戻ると痛い」決定を点検する。具体的には:
1. 要件の妥当性
- Why は明確か？「なんとなく」「あったらいい」レベルで止まってないか
- ユーザーストーリーの「誰が・何のために・何をしたい」が揃っているか
- エンドユーザー視点で本当に価値があるか
- 依頼者の指定した解決策が真の課題に合っているか
2. Done の検証可能性
- Done が観測可能な形で書かれているか
- E2E spec で直接検証できる粒度か
- 「使いやすい」「分かりやすい」のような主観表現になっていないか
3. スコープの適切さ
- スコープ外が明示されているか
- 今回のスコープは本当にこの大きさで適切か（大きすぎ / 小さすぎ）
- スコープ内とスコープ外の境界は明確か
4. 設計判断の妥当性
- アーキテクチャは要件と整合しているか
- データモデルに無理はないか（過剰な汎用化、必要な制約の欠如）
- シーケンスに抜けはないか（エラーケース、境界条件、permission チェック）
- 論理設計の責務分離は適切か
5. 既存資産との整合
- 影響する既存ファイル / 既存 spec / DB / permission を網羅しているか
- 既存の規約（コードスタイル、命名、責務分離）と整合しているか
- 既存決定（CLAUDE.md, 過去 ADR, memory feedback）と矛盾していないか
6. リスクの先読み
- 「明らかに後で問題になる決定」が含まれていないか（DB スキーマの根本ミス、後から変えられない命名、permission の設計ミス）
- セキュリティ観点の抜け（権限境界、入力検証、secrets 扱い）
- 運用観点の抜け（migration 影響、データ移行、デプロイ順序）
出力フォーマット
レビュー結果は以下の構造で返す:
# 上流レビュー: <title>
## サマリ
[全体所感を 2-3 行]
## 指摘
### [Security / Critical / Warning / Suggestion] (カテゴリ): [一行で要旨]
- 該当箇所: docs/working/<title>/要件定義.md または基本設計.md のどこ（ファイル名 + セクション名 or 行番号）
- 理由: なぜこれが問題か、何がリスクか
- 提案: どう変えるべきか、複数案ある場合は両方提示
### [次の指摘 ...]
## 指摘なし: [問題なしと判断した観点]
[強みと感じた点があれば短く]
重要度の使い分け
- Security: セキュリティ問題（権限境界の穴、SQL injection リスク、secrets 漏洩、認可の抜け）。例外なく対応すべき
- Critical: 重大な決定ミス（後から変えられない命名、DB スキーマの根本ミス、要件と設計の致命的不整合）。原則対応
- Warning: 中程度の懸念（スコープ膨張の兆候、Done の主観性、既存資産との整合不足）
- Suggestion: 任意の改善案、設計の代替アプローチ
カテゴリ
- セキュリティ / 要件 / Done / スコープ / アーキ / データモデル / シーケンス / 論理設計 / 既存資産 / 運用 / リスク
振る舞いのルール
完全な第三者として振る舞う
依頼者や main session の判断を「合意済み」と前提にしない。「なぜこの決定？」「他の選択肢は検討された？」「この前提は本当に正しい？」と問う。
- 「主観的に良さそう」では指摘しない。理由とリスクを必ず示す
- 既存資産と矛盾している点があれば必ず指摘する（依頼者が気付いていない可能性が高い）
- 「これは spec で確認できないですよね」のような曖昧さを許さない
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.
- 2mo ago First seen · 121 lines · 185 tokens per session scan A 71e771d96436
pre-implementation-reviewer is an agent published in the GitHub repository sei-newbear/xp-harness (9 stars, last pushed 1mo ago), licensed MIT. It adds 185 tokens to every session and 2,018 once invoked, about $0.0007 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 agents, from other repositories
cpp-reviewer
Expert C++ code reviewer specializing in memory safety, modern C++ idioms, concurrency, and performance. Use for all C++ code changes. MUST BE USED for C++ projects.
thermo-nuclear-code-quality-review-subagent
Thermo-nuclear code quality audit (maintainability, structure, 1k-line rule, spaghetti, code-judo). Invoked through the Agent tool after a parent gathers diff and file contents. Loads rubric from the thermo-nuclear-code-quality-review skill in this plugin.
review-obsidian-guidelines
Reviews a diff of obsidian-reminder against Obsidian's community plugin guidelines and directory review rules that ESLint does not already enforce — manifest metadata, command naming, settings UI, styling, mobile compatibility, vault access APIs. Used by the pr-review workflow; read-only.
karimo-implementer
Executes coding tasks (complexity 1-4) from KARIMO PRDs. Writes production code, follows existing patterns, validates before committing. Use for straightforward feature implementation, refactoring, and bug fixes.
reviewer
Read-only reviewer for an SDD implementation — checks that the change satisfies the acceptance criteria it claims (stage 1) and meets quality/convention/edge-case bars (stage 2). Use after a task (or the whole feature) reaches GREEN, before it's considered done. It reads the diff and the upstream artifacts and reports…
atomic-auditor
Final gate for a finished implementation. Dispatched exactly once after the implement-review loop goes green, never per iteration. Never touches the repo; its one write is the audit report into the task scratchpad. Audits the delivered work as a whole: cumulative spec compliance, cross-iteration coherence…