Satoru Nishio

PR・コミット・差分・ファイルをレビューし、再現条件と根拠のある不具合、回帰、検証漏れを報告する。変更が差分の外で何を壊しうるか（影響範囲）を、安全の根拠をコードで証明して確かめるときにも使う。

Codex CLI（`codex exec`）に、モデル・reasoning effort・速度を指定して作業（調査、レビュー、相談、実装）を頼み、結果を受け取って要約する。「solで〜して」「astra xhighで調べて」「luna low fastで」「Codexで〜」「Codexに聞いて／やらせて」のように、呼び名（sol / astra / luna）やCodexを指定して作業を頼まれたときだけ使う。文中に普通の単語として「sol」「luna」が出てきただけのときは使わない。

エージェントが同じ間違いを繰り返すとき、履歴から間違いの種類を洗い出し、設計、型、lint・CI、テスト、文書の順に、効く範囲で最も上の層で再発を防ぐ。計画を承認してから実装し、各チェックが過去の実際の間違いで失敗することを証明する。'/correct'で使う。

アプリを利用者と同じ操作で動かして振る舞いを確かめる、プロジェクト専用の検証スキル（`.claude/skills/verify-<app>/`）と機能一覧を作る。言語、フレームワーク、Web・CLI・API・デスクトップを問わない。'/create-verification-skill'、'このリポジトリの検証スキルを作って'、UI・CLI・サービスの振る舞いを確かめる手順がリポジトリにないときに使う。

リポジトリにエージェント開発用の検証基盤を整える。`make check`、GitHub ActionsのCI、短いAGENTS.mdを、言語とツールを検出して作る。'harness-init'、'リポジトリを初期化して'、'検証コマンドを用意して'、新規リポジトリ作成直後や既存リポジトリへの導入時に使う。

既存のコードやシステムが今どう動いているか（仕組み、処理の流れ、どこに何があるか、どの層やモジュールが持つべきか）を、コードを読んで説明する。'どうなっているか'、'仕組みを教えて'、'この処理の流れ'、'これはどこに置くべきか'、変更の前に既存の仕組みを理解したいときに使う。なぜ今の形なのか（経緯）は`why`、技術の選定は`research`を使う。

知らない分野にキャッチアップするとき、汎用的な言葉から界隈の用語・中心の人・場（学会・雑誌・個人ブログ・動画・リポジトリ・一覧）を特定し、 引用・リンク・著者を芋づる式にたどって、当たりの原文（論文も個人の記事や動画の字幕も）を要約せずそのまま ~/research/<話題>/sources/ に落とす。 周ごとに地図（map.md）を育て、要る主張の全部に原文が付くか飽和したら止める。 見張りのモードでは、地図の場（Qiita・Zenn のタグ、note、YouTube、ブログ、arXiv）の新着を RSS で引いて原文の冒頭つきで並べる。 以下で使用:「芋づる式に調べて」「この分野をキャッチアップしたい」「界隈の用語と人から掘って」 「論文とか先行研究を漁って」「既存の技術を真似したいから元ネタを探して」「上手い人のやり方を集めて」「原文で落として」「/imozuru」 「〇〇って研究あるの？原典ほしい」「全然わからないから流れを掘って」「どういう界隈でどう呼ばれてるか知りたい」 「〇〇の新着見て」「今週の〇〇の記事まとめて」「キャッチアップ」「/imozuru watch」 "dig into this field", "find the canonical papers on X", "literature dive", "what's new in X this week"。 以下には使用しない: 答えが1つの事実の確認（年・有無だけ・仕様1つ → そのまま検索）／ 手元の PC の中の資料を探す／読んだ資料の要約や解説を書く。

プロジェクトの検証スキルと機能一覧を、アプリの現状に合わせて点検する。機能ごとにソースを読み、1回の実操作ですべての機能を動かし、証明できた修正だけをまとめる。'/maintain-verification-skill'、'検証スキルを点検して'で使う。

作業の種類（不具合の修正、機能の追加・変更、リファクタリング、性能の改善、調査）ごとの手順書。作業の重さを決めた直後に、当てはまる手順書を読んで、その順に進める。'このバグを直して'、'不具合'、'機能を追加して'、'リファクタリングしたい'、'遅い'、'速くして'、'/playbook'で使う。

技術選定、仕様比較、実装への影響を調査し、根拠付きのレポートを.tmp/research/に保存する。

生成文書や画面から会話・制作指示の混入を取り除き、読者向けの成果物に整える。

実装前に、受け入れ条件と確かめ方を決めた契約を作る。作業の重さがレベル1（短い契約）か2（仕様書）のとき、公開挙動を変えないリファクタリングの計画、受け入れテストを先に書くときに使う。'/spec'、'仕様書を書いて'、'仕様をまとめて'、'リファクタリングしたい'、'責務を分けたい'で使う。

技術的な不確実性が大きい実装（方式が使えるか、仕様やライブラリが実際にどう振る舞うか、性能や精度が足りるかが動かさないと分からない）を、調査→使い捨てMVP→精査と実験→仕様→MVPの破棄→再実装→報告の順に進める。作業の重さがレベルRのときに使う。'MVPを作ってから作り直して'、'一度試作して捨てて'でも使う。要件が曖昧なだけの作業、既知のパターンで書ける作業、調査だけの依頼には使わない。

既存のコードや設計がなぜ今の形なのか、なぜその選択をしたのか、退行や障害の経緯、しきい値の根拠を、git・GitHub・Notion・Slackなどの記録から調べ、確からしさを区別して出典付きで答える。'なぜこうなっているのか'、'この値はどこから来たのか'、'この設計にした理由'、コードを変える前に経緯を確かめたいときに使う。コードが今どう動くかの説明（howを使う）や、新しい技術の選定（researchを使う）には使わない。

AIが生成した日本語を推敲するスキル。利用者が yomiyasu の名前を出して頼んだとき（「/yomiyasu」、「$yomiyasu:yomiyasu」、「yomiyasu で推敲して」など）と、スキルを使った日本語の推敲をはっきり頼んだときだけ使う。CLAUDE.md、AGENTS.md、カスタム指示などで yomiyasu を使うよう求められているときも、名前を出して頼まれたものとして扱う。名前を出さずに日本語の文章を書かせる依頼や、コード、設定、ドキュメントの更新では使わない。意味と条件を保ち、不自然な比喩、曖昧な主述関係、不要な装飾やコピー調を整える。使用トリガー：'/yomiyasu', 'yomiyasuで推敲して', 'この文章を推敲して', '文章を自然にして', 'AI臭さを消して', '文章をリライトして'。