takayoshitoyoda05
UserClaude Code用 Planner/Generator/Evaluator 3分離パターンのテンプレー
Categories
Indexed Skills (27)
config-set
作業スコープや評価強制などを「〜に設定して」「settings.local.jsonの中身を作って」と言われたときに使う。settings.local.json はガードにより Claude からの直接書き込みができないため、貼り付け用のJSON下書きを提示するだけに留める。
cross-review
Codex CLI(OpenAIモデル)でClaude実装を別モデル視点でレビューする。CLAUDE_CROSS_REVIEW=1 のときevaluator実行前に必須。「クロスレビューして」と言われたときにも使う。
design-interview
実装前に設計を固めたいときや設計書に未確定の判断が残っているとき、「詰めて」「grillして」「深掘りして」と言われたときに必ず使う。
codex-delegate
独立した定型タスク(テストの量産、一括変換、CLI中心の操作)をCodexに委譲したいとき、Claudeのレート制限中に作業を退避したいとき、または「Codexにやらせて」「Codexに委譲して」と言われたときに必ず使う。
multi-seed
同じ実験を複数のseedで回して平均±標準偏差を出したいとき、または「seedを振って」「マルチシードで回して」「seed 42-46で実験して」と言われたときに必ず使う。長時間ジョブはバックグラウンドで走り、セッションを閉じても継続する。
adr
トレードオフを伴う設計判断や後から変更しづらい決定をしたとき、「この決定をADRに残して」と言われたとき、design-interview や planner が重要な決定を解消した直後に必ず使う。
architecture-check
コードベース全体の見直しやリファクタ候補の洗い出しをしたいとき、「アーキテクチャを見直して」「設計負債をチェックして」と言われたときに必ず使う。
brainstorm
方向性が定まらず選択肢を広げたいとき、「ブレストして」「アイディア出しして」「他にどんな方向性がある?」と言われたときに必ず使う。
config-explain
スコープ・評価強制の設定確認や意図しないブロックの切り分けをしたいとき、「今の設定を確認して」「なぜブロックされたか分からない」と言われたときに必ず使う。
diagnosing-bugs
原因不明のバグ・性能劣化・数値の食い違いが出たとき、「原因を調べて」「バグを直したい」「なぜこうなるか分からない」と言われたときに���ず使う。
fix-ci
GitHub Actions等のCIが失敗したとき、または「CIを直して」「テストが落ちている」と言われたときに必ず使う。
handoff
別セッション・別マシンで作業を再開するために区切るとき、「引き継ぎを作って」「handoffして」「ここで一旦区切りたい」と言われたときに必ず使う。
leakage-check
学習データと評価データの間で情報漏洩(データリーケージ)が起きていないか確認したいとき、または「リーケージチェック���て」「分割は正しいか確認して」と言われたときに必ず使う。
pre-mortem
今動いているコードに対して「将来どこがどう壊れるか」を予測したいとき、または「壊れそうな箇所を洗い出して」「pre-mortemして」と言われたときに必ず使う。
property-test
関数の入力パターンが多い・境界値が複雑なとき、ランダム入力で不変条件を網羅的に検証したいとき、または「プロパティテストして」「hypothesisでテストして」と言われたときに必ず使う。
python-standards
このプロジェクトのPythonコーディング規約(パッケージ管理・テスト・型ヒント等)を確認・適用したいとき、または新しいPythonファイルを作成するとき、evaluator-standardsがレビューの基準を確認するときに参照する。
regression-suite
重要な変更の完了後に影響範囲を広くカバーしたいとき、「網羅的にテストして」「リグレッションテストして」と明示的に言われたときに使う。自動では発火しない。
retrospective
テンプレートの改善点を洗い出したいとき、差し戻しや却下が溜まってきたと感じたとき、または「振り返りして」「改善提案を出して」「retrospectiveして」と言われたときに必ず使う。
security-review
コードの脆弱性やサードパーティ製スキルの安全性を確認したいとき、または「セキュリティをチェックして」「このスキルは安全か」と言われたときに必ず使う。
tdd
入出力が明確な新規関数・ユーティリティを追加するとき、「テスト駆動で実装して」「red-green-refactorで」と言われたときに必ず使う。
branch-naming
新しいブランチを作る前に、プロジェクトのブランチ命名規則を探して名前を決める。ml-pipeline の手順1.5 で自動で使われる。単独でも「ブランチ名を決めて」「命名規則を調べて」と言われたときに必ず使う。
literature-review
関連研究を体系的に調査したいとき、サーベイの範囲を決めて文献を整理したいとき、または「文献調査して」「関連研究をまとめて」「サーベイして」と言われたときに必ず使う。
mlflow-log
実験の結果をMLflowに記録したいとき、過去の実験を比較・検索したいとき、または「実験を記録して」「実験AとBを比較して」「MLflowで確認して」と言われたときに必ず使う。
mutation-test
テ��トが本当にバグを検出できるか(テストの質)を検証したいとき、または「ミューテーションテストして」「テストの質を確認して」と言われたときに必ず使う。実行時間が長いため自動では発火しない。
paper-writing
論文の原稿を書く・見直すとき、査読コメントに対応するとき、または「論文をチェックして」「この段落を推敲して」「査読対応を手伝って」と言われたときに必ず使う。
refactor-scout
パイプラインを使わずに、指定したコードをスカウト隊でリファクタリングしたいとき使う。「スカウト隊で見て」「リファクタの提案を出して」「命名と重複だけチェックして」と言われたときに必ず使う。
spec-checklist
設計書と計画が「良く書けているか」を実装前に検査する。/ml-pipeline の手順3.3(Planner後)で必ず自動実行される。単独でも「設計書をチェックして」「spec-checklistして」で使う。コードではなく設計書・計画の品質を検査する。
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.