Sadoku

Skill hayashiii-ghub/hikizan/skills/sadoku

Claude Code plugin / Agent Skills pack — verb-split skills for design, review, TDD, and PR flow, with deterministic git hooks as safety floors

Install

npx -y skills add hayashiii-ghub/hikizan --skill sadoku

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

コード、差分、PR、実行可能なプロジェクト指示のレビューや簡略化案を求める依頼に使う。正しさ、既存コードとの整合、セキュリティ、より単純な表現を確認し、レビュー中は対象を変更しない。

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

5.7 KB, as published. Nobody here has run it

査読（sadoku）

本番コードとエージェントが実行するMarkdownを、実装者の説明から独立してレビューする。レビュー中は対象を変更しない。

共通ルール

全スキル共通。正本はscripts/contract.mdで、scripts/gen-contract.shが各SKILL.mdのこの区間に書き込む（手で編集しない）。

各スキルを起動したら、そのスキルの作業を始める直前に1行だけ🌲 <スキル名>（日本語名）：<今回の目的>と伝える。複数スキルを1行にまとめず、まだ始めないスキルを予告しない。同じスキル内の局所作業では繰り返さない
調査、相談、設計、レビューだけの依頼では対象を変更しない。修正、追加、削除、実行、PR提出が依頼に含まれる場合だけ、必要なスキルをつないで明示された終点まで進む
スキルを固定順に通さず、依頼された成果に必要な観点だけを使う。明示済みの終点へ向かう途中で、形式的な承認を追加しない
検証はリスクに比例させ、未検証の状態を成功や完了と書かない
人へ渡す日本語は結果か判断を先に置き、簡潔で分かりやすく書く。文章の表現や構成自体が成果ならhoukokuを使う
停止するときに意味のある次の進め方があれば、最大3件を推奨順にA（あ）、B（い）、C（う）で示し、英字とひらがなのどちらの回答も同じ選択として扱う

使い分け

レビュー：バグ、回帰、セキュリティ、既存コードベースとの不整合を探す
簡略化：振る舞いを変えずに減らせる分岐・層・重複・不要コードを探す

手順

対象時点を固定する。ブランチ全体の比較元は利用者・PR指定、なければ選んだリモートの既定ブランチとし、機能ブランチの上流ブランチを比較元にしない。merge-baseからのコミット済み・ステージ済み・未ステージ・未追跡ファイルを含め、途中で別の対象範囲へ読み替えない
変更意図、関連テスト、近隣の類似実装、リポジトリ規約を必要な範囲だけ読む
リスクで深さを決める。局所的で可逆なら軽量、振る舞い・API・複数モジュールへ波及するなら標準、セキュリティ・権限・スキーマ・移行・データ損失・並行性・取り消し費用が高い変更なら重点とする
正しさ、失敗経路、既存パターン、より単純な表現、追加行への秘密情報・個人情報混入を確認する。行数やファイル数だけでレビュー担当を増やさない
独立した専門性が結果を改善する場合だけreferences/persona-catalog.mdの契約で専門レビューを行う
UI・スタイル・配置・操作に触れる場合は、対象リポジトリに設定済みのShimonがあるときだけ次の契約で視覚確認する

信頼できる対象にShimonとレビュー済みのshimon.config.mjsがある場合だけ使う。自動インストールや別ツールへの切替は行わない。ChromeやPlaywrightなどのブラウザー実行ファイルを直接起動して代替しない
今回必要なケースだけを.shimon/task.mjsへ書く。サーバー起動とブラウザー確認はリポジトリ所定の固定コマンドへ集約し、なければ./node_modules/.bin/shimon verify --task .shimon/task.mjs --jsonを使う。終了後に一時ファイルを削除する
JSONのpassと各自動検査を確認し、返された全スクリーンショットをintentとreviewに沿って見る。visualReviewRequired: trueを視覚確認済みとは扱わない
スクリーンショットとログへ秘密情報・個人情報を残さない。実行条件を満たさなければ、理由を添えて視覚未確認と報告する

指摘の重複を除き、利用者が判断できる順に並べる。指摘がなければ余分な「該当なし」一覧を作らない

指摘の書き方

各指摘に重要度、file:line、問題になる具体的な入力または状況、影響、最小の修正案を含める。好み、根拠のない将来不安、実装者の意図を読み違えただけの指摘は出さない。

簡略化

references/simplify-checklist.mdを使う。自分では直さず、修正する価値があるものと据え置きでよいものを分ける。

次の進め方

依頼の終点がPR提出なら、修正すべき指摘をjikkouへ渡して最終変更を再レビューし、指摘が解消した時点でteishutsuへ進む。停止する場合は、次の候補から意味のあるものだけを選ぶ。

指摘をjikkouで修正
前提や方針をsekkeiで見直す
重大な指摘がなければteishutsuでPR提出

禁止事項

レビュー対象や比較対象を確認せず一般論で指摘する
サブエージェントの指摘を裏取りせず採用する
レビュー中に対象を修正する