スキルを探す

論文・研究概要の体裁・形式を自動チェック。LaTeX(.tex)・Word(.docx)・PDF(.pdf)に対応。表記ゆれ・参考文献体裁・相互参照整合性・未記入セクション等を検出。1〜2ページの概要・梗概・アブストラクト（固定尺）は --fixed（またはページ数で自動判定）で紙面配分（参考文献が本文を圧迫していないか等）も診断する。提出直前の最終確認に使用。卒論・研究論文・学会投稿論文・研究概要すべてに対応。旧 abstract-format-check を統合。

研究概要・中間発表予稿の「研究としての筋」を、論理の鎖(L1背景→L2関連研究と限界→L3課題(差分)→L4仮説→L5評価→L6位置づけ)として1リンクずつ採点し、さらに端点間の整合(掲げた構成概念=旗と評価指標=物差しのズレ=construct validity)を照合するスキル。各文の綺麗さ(→articulation-check)でも汎用の弱点(→weakness-analyze)でもなく「リンク間が繋がっているか／旗と物差しが一致しているか」を見る。骨子・位置づけ・仮説・課題設定・研究の一貫性を見てほしい、research framing を見て、と言われたとき。旧名 research-framing-check。

教員向けの研究概要レビュー(research-review等の出力.md)を入力に、学生に直接渡せる「前向きだけど抑えめ・シンプル・self-contained・優先順つき」の中間発表コメント1枚に書き換えるスキル。厳しい分析を、学生が萎えず手を動かせる建設的な行動リストへ翻訳する層。レビュー結果を学生向けに書き換えて、学生向けコメントにして、と言われたとき、または research-review --student から連鎖呼び出しされる。

研究文書（概要/梗概/アブストラクト・研究論文・卒業論文）を種別自動判別し、研究の骨子・グローバル一貫性・当てどころ・関連研究・説明不足・弱点・体裁の各面から一括レビューして教員向け統合1ファイルに集約するメタスキル。framing-check(骨子＋一貫性)・aim-check(当てどころ)・articulation-check(5W)・weakness-analyze(弱点)・lit-survey(関連研究)で検出し、shepherd で内容面を整形、format-check(概要は --fixed で紙面配分)で体裁を見る。--student で student-comment に渡し学生向け1枚も生成。論文・概要・卒論・中間発表予稿を「レビューして」「総合的に見て」と言われたときに使う。旧 abstract-review / paper-review / thesis-review / review を統合。

スクリーンショットに赤枠・矢印・注釈を重ねて、見せたい箇所を一目で分かるようにする（Skitch 風）。 資料・ドキュメント・不具合報告・レビューに画像を貼るとき、画面のどこを見ればいいかを 画像だけで伝えたいときに使う。画面に写らないもの（設定値・レスポンス・ログなど）を 図にして注釈を足す手順も含む。トリガー: 「スクショに赤枠を入れて」「注釈を足して」 「どこを見ればいいか分かるようにして」「証拠画像を作って」。

世の中のベストプラクティスをWeb検索・SNS検索・ツール検索で調査し、鮮度・信頼性・多角的視点を 考慮して構造化レポートにまとめる。「ベストプラクティスを調べて」「best practice」「最適な方法」 「推奨される方法」「どうするのが正解か調べて」「世の中ではどうやっているか」等で使用。 技術・ビジネス・教育・デザイン等あらゆるドメインに対応。

セッション間のコンテキストを構造化して保存する。 「引き継ぎ」「セッション保存」「handoff」「コンテキスト保存」等で使用。 通常は自動保存（L1/L2）で十分。明示的に高品質な保存をしたいときに呼ぶ。

対話または既存トークンファイル（W3C DTCG / CSS variables など）をもとに、プロダクトに合った DESIGN.md を生成する。AIがつくるUIに一貫性を。

多分野の専門家を動的に選定し、構造化された議論で多角的な評価・提言をまとめる。 「専門家に聞きたい」「レビューして」「多角的に評価して」「議論して」等で使用。 Webサイト、コード、事業戦略、デザイン、組織設計等あらゆるドメインに対応。

別系統のモデル（Claude Code なら Codex、Codex なら Claude Code）に問題だけを渡して 独立に解かせ、自分の案と突き合わせる。実装前の設計判断や、同じ箇所で修正が 2 回続いて抜けられないときに使う。「セカンドオピニオン」「別のモデルに聞いて」 「他の見方」「行き詰まった」等で使用。コードレビューには使わない（/codex:review 等を使う）。

Claude Code のセッション記録（~/.claude の履歴・セッションログ・memory）から、週ごとの問い（questions.json）に答える「ナレッジカード」を下書きし、本人が確認・修正したうえで機密スキャンを通し、Notion の「ナレッジカード」DB に提出する。引数なしなら先週（月曜〜日曜）の記録を集計し、確認のうえ Notion に提出する。「Claude Code の履歴をナレッジカードにまとめて」「先週のログからナレッジカードを作って」「ナレッジカードを提出したい」「今週のカードを出して」「週次の振り返りカードを作って」などの依頼で使う。週次のカード提出であり、個人の採点や評価ではない（セッション 1 本の採点は evaluate-session の領域）。

週ごとに Notion「ナレッジカード」DB に集まったカードを読み、問いをまたいで親和図にまとめ、正（worked）と反（failed）の対立から合（提案）を出し、次の問いを決めて、「合成テーマ」DB と週の行の配下の「まとめ」ページに書き込む。「今週のカードを合成して」「W43 のまとめを作って」「ナレッジカードの合成」などの依頼で使う。カードの提出は knowledge-cards、個人の採点は evaluate-session の領域。個人別の件数ランキングや「誰が何を失敗した」は出さない。

DeepSeek Harnessのdsh webをCLI・HTTP RPCで操作する。起動、会話の検索・状態・履歴・回答の読取、新規チャット、依頼・追記・中断、ワークスペースや設定の操作に使う。起動中のwebへの操作をheadlessの別実行と取り違えない。

pstackの開発手順とthermosの二方向レビューで、調査・設計・実装・検証を進める。pstack、poteto-mode、thermosの指定、開発全体の進行、変更の正しさと保守性のレビュー、初回設定に使う。

features.json を読み込み、pending な機能を1件ずつ tdd-guide エージェント（内部で tdd-cycle を使用）で実装するスキル。 Context anxiety（トークン上限接近による焦り）と Context rot（情報劣化）を防ぐため、 機能単位のループ・状態管理・implementation-notes.md への記録を担う。 builder エージェントが実装フェーズを開始するときは必ずこのスキルを呼ぶ。

t-wada式TDD（テスト駆動開発）でRED→GREEN→REFACTORサイクルを使ってテストファーストで開発を進めるスキル。 ユーザーが「TDDで実装して」「テストファーストで」「t-wada式で」「REDから始めて」「失敗するテストを先に」と言った場合は必ずこのスキルを使うこと。 FizzBuzz、スタック、認証、バリデーションなど、あらゆる実装タスクにTDDアプローチを適用できる。 ユーザーが実装を始めようとしているときは積極的にTDDを提案すること。

Planner→Builder→EvaluatorのLong-Runningエージェントハーネスで複雑なタスクを実装します。plannerがfeatures.jsonに機能を分解し、builderがTDDで1機能ずつ実装し、evaluatorがPASSするまでbuilderを繰り返します。「〇〇を作って」「実装して」「long-running」などのリクエストで起動します。

フレーキーテスト（不安定なテスト）を検出・分類・修正支援するスキル。 以下のような状況で使う： - 「テストが時々失敗する」「CI が時々落ちる」 - 「同じコードなのにテスト結果が変わる」 - 「flaky test」「不確定」「再実行すると通る」 - 「テストが不安定」「テストの信頼性が低い」 t-wada式TDDの信頼性基盤を守るために使用する。 引数で実行回数を指定可能（デフォルト: 5回）。

Uncorrelated Evaluator — 4軸ルーブリック専門エージェント（functionality-reviewer・code-reviewer・design-reviewer・originality-reviewer）と security-reviewer を5並列実行し、成果物を多面的に独立評価します。PASS / NEEDS WORK / BLOCKED 判定を返します。Self-leniency 防止のため、実装エージェントのコンテキストを引き継がない新規エージェントとして起動します。「レビューして」「評価して」「実装を確認して」などのリクエストで起動します。

任意のタスク（GitHub Issue・自由記述リクエスト・口頭要件）を起点に、受け入れ条件確認・スコープ定義・影響分析・テスト戦略を含む実装計画（15セクション）と、builder エージェントへ渡す features.json を生成します。「〇〇を作って」「実装計画を作って」「Issue

テストカバレッジのギャップを体系的に分析し、実際に動くテストコードを提案するスキル。 以下のようなときに使う： - テストカバレッジを改善したい・不足テストを特定したい - 「テストが足りない」「カバレッジを上げたい」「どこをテストすべき」 - 「未テストの関数」「what tests am I missing」「improve test coverage」「coverage gap」 t-wada式TDDの原則に基づき、テストの抜け漏れを特定して優先度付きで補完する。 引数: 分析対象ファイル・ディレクトリ（省略時はプロジェクト全体）

会話の成果 (調査・比較・解説など) を人が判断するための HTML レポートにまとめ、crit preview で開いてコメント対応まで往復するスキル。ユーザーが「HTML にまとめて」「レポートにして」「crit で開いて」「/crit で表示して」など、HTML 化して crit で見る意図を示したら必ず使用する。dev パイプラインの成果物 (research / plan / report.html) は対象外。

LPやWebサイト用の短い漫画画像を生成・修正する。既存キャストを保ち、1画像で一つのストーリーを伝える。

生成動画を元プロンプト・参照素材・用途と照合し、構図、形状、接触、動作の連続性、必要な文字を根拠付きでレビューする。生成結果の採用可否、破綻の診断、修正方針の判断に使う。内容要約や文字起こしだけの依頼には使わない。