dotfiles

Gitコミットを適切な粒度に分割し、有用なメッセージを付けて作成するスキル。「コミットして」「commitして」「変更をコミット」「まとめてコミット」など、コミット操作を依頼されたら必ず使う。

指定したスキルを3回繰り返し適用します。レビュー・計画・実装など、ファイルを変更するスキルに使います。「iterateで<スキル名>して」「<スキル名>を繰り返し適用して」のように使います。

既存テストをレビューして改善するスキル。「テストをレビューして」「テストを改善して」「テスト名を直して」のように頼まれたら使う。新規にテストを書くのではなく、`.claude/docs/test-implementation.md` のルール（テスト名・AAA構造・アサーション設計・テストダブル・非決定性制御・テスト間独立性・Testing Library 等のフロントエンド固有ルールまで全観点）に既存テストが沿っているかを見直す。対象は `.test.ts` / `.test.tsx` / `.spec.ts` ファイルと、テストコードブロックを含む `.md` ドキュメントファイル。

作った成果物について、ユーザーがその振る舞いと目的を確実に理解できているかを問いかけで確認します。細かな実装ではなく、何をするものか・目的にかなうかに焦点を当て、あらゆる可能性を踏まえてエージェントが判断して問いを立てます。「理解できているか確認して」「振る舞いを確認して」「目的にかなっているか見て」「作ったあとのすり合わせをして」と要望された際に必ず使用します。実装や変更が一段落したとき、作ったものの理解をすり合わせたいと感じたら積極的に提案してください。

`/compact`で要約する前に、残したい情報をユーザーに選んでもらい`/compact`の引数を組み立てます。 「compact前に整理したい」「コンテキストを圧縮したい」「/compactの引数を作って」 「会話が長くなってきたので整理したい」「重要な情報を引き継ぎたい」のように使います。

マージ済みのローカル・リモートブランチを整理するスキル。「ブランチ掃除」「マージ済みブランチを削除」「ブランチ整理」「gh poiを実行」「不要なブランチを片付けて」「リモートのブランチも消したい」「mainだけ残して」のような依頼で必ず使う。gh-poi拡張がインストール済みであることを前提とする。mainなどベースブランチは絶対に削除しない。

大きな計画や実装タスクを、依存関係順に並んだ最小単位のステップに分解します。各ステップは単独でレビュー・コミットできる粒度にします。「分解して」「ステップに割って」「細かく割り当てたい」「着手前に整理したい」「段階的に進めたい」「タスクを整理して」と要望された際に使用します。

UC表を入力として振る舞いの検証ケースを設計し、テストコードを生成するスキルです。 「テスト計画を立てたい」「テストケースを設計したい」「どんなテストを書くべきか」 「テストを書いて」「.test.ts を作って」「e2eだけで十分？」 「このコンポーネントのテスト何を書けばいい？」「テストが多すぎる気がする」のように使います。 3層検証（自動テスト / Agentic Verification / 手動検証）の割当てを行い、 テスト種別ごとに章分けしたテスト計画を作成、テスト対象の特性に応じた reference で テストコードを生成します。テストファイルには VERIFY コメントで3層の検証情報を埋め込みます。 ユースケース設計は別スキル`x-designing-usecases`で扱います。

テストの抜け漏れを防ぐためにユースケースを設計するスキルです。 「ユースケースを書きたい」「テスト観点が足りているか確認して」「受け入れ条件を整理したい」 「テスト戦略を整理したい」「何をテストすればいいかわからない」のように使います。 対象 × インターフェースで系統分け（E: エンドユーザー / D: 開発者 / O: 運用者）し、 各UCに観点と適用される状況軸を紐づけて、テスト計画への入力となるUC表を作ります。 明示的に「ユースケース」と言われなくても、テスト観点・抜け漏れに関する相談が来たら積極的に起動します。 テスト計画とテストコードの生成は別スキル`x-designing-testcases`で扱います。

Figma MCPから実装に必要なデータを取得し、プロジェクトのCSSフレームワークに合わせてトークンを引き当て、マッピングファイルに記録するスキルです。 FigmaのURLやnode-idが渡されたとき、デザインと表示の差分を確認するとき、「スタイルが違う」「デザイン通りか確認して」「Figmaと比較して」のような依頼でも積極的に起動してください。 Figma MCPを呼び出す前に、必ずこのスキルの手順に従ってください。

x-figma-extractが生成したマッピングファイルとスクリーンショットをもとに、Figmaのデザインに合わせてコンポーネントやページを実装するスキルです。 「このFigmaのデザインを実装して」「Figmaに合わせてコンポーネント作って」「デザインを再現して」「Figmaどおりに実装して」 「マッピングファイルから実装して」「extractしたデータで実装を進めて」「Figmaのnode-idを実装して」のように依頼されたとき、 またはx-figma-extractの直後に実装フェーズへ進むときに必ず起動してください。 Figma URLが渡されて実装まで一気に依頼された場合は、まずx-figma-extractで取得・マッピングを終えてから本スキルを起動します。 デザイン取得・トークン引き当て・マッピングファイル作成自体は本スキルでは扱いません。それらはx-figma-extractで実行してください。

計画や設計について、共通認識に至り、意思決定ツリーのすべての分岐が解消されるまで、ユーザーを徹底的に問い詰めてください。これは、ユーザーが計画の「ストレステスト」を行いたい場合や、設計について厳しく追及されたい場合、あるいは「厳しく問い詰めて（grill me）」と要望した際に使用します。

git logのhotspot分析・循環参照・デッドコード・不安定性メトリクスを組み合わせて リファクタリング優先候補を提案する。「hotspot」「リファクタリング提案して」 「どこを直すべき」「技術的負債を調べて」のように使う。

計画ファイル（docs/frontend/plans/*.md など）のパスを受け取り、その計画に従って実装を行うスキル。 実装・リンター・テスト・コードレビュー・計画ファイル更新を一連で実行し、完了報告まで行う。 「plans/〇〇.md の計画に従って実装して」「この計画を実装して」「計画どおりに実装して」 「Acceptance Criteria を全部パスした状態で終わらせて」「計画ファイルのパスを渡すから実装して」 「じゃあ実装に移って」「さっきの計画でお願い」のような依頼で使う。 計画ファイルのパスが引数に含まれていれば積極的に起動する。 直前の会話で x-planning-implementation スキルが計画ファイルを生成した場合も積極的に起動を提案する。

別のAIコーディングエージェントが実行できる粒度の実装計画を作成するスキル。 口頭説明・要件定義書・断片的な依頼など、曖昧なタスクを実行可能な計画ファイルに変換する。 「計画を立てて」「実装計画を作って」「要件を整理して」「これをプランに落として」 「タスクを整理して」「スコープを決めて」「何から手をつければいい」「どう実装する」 「設計してから進めたい」「計画を見直して」「計画をブラッシュアップして」 「計画を改善して」「実装直前だが一度整理したい」「要件が走り書きなので計画に落として」 のような依頼で使う。 明示的に「計画を」と言われなくても、依頼が大きすぎる・曖昧すぎてそのまま実装できない場合は 積極的にこのスキルを起動する。`x-grill-me` でユーザーへの確認を行い、 品質ゲートを通過するまでイテレーションする。

計画や設計に着手する前に、それが失敗した未来を想定して原因を逆算で洗い出します。一方向で失敗シナリオを列挙し、対策を提案します。「pre-mortemして」「事前に失敗要因を出して」「失敗シナリオを洗い出して」「リスクを洗い出して」「計画の穴を探して」と要望された際に必ず使用します。計画ファイルや設計書が示されたとき、着手前にリスクを確認したいと感じたら積極的に提案してください。

フィーチャーブランチをベースブランチ（main/master/developなど）にリベースし、リモートに反映するまでを1タスクとして実行するワークフローを提供します。「リベースして」「mainを取り込んで」「mainに追従して」「rebase」といった依頼、またはフィーチャーブランチがベースブランチから乖離している場合に使用します。

セッションのふりかえりをKPTA形式で実施し、設定の改善提案と即時実施を行う。 「ふりかえり」「レトロスペクティブ」「retrospective」「振り返り」「KPT」「KPTA」 「今日のセッションを振り返って」「改善提案して」のように使う。

ドキュメント・実装・アーキテクチャを、調査・推測・実地検証を踏まえて段階的に解説し、その過程と結論をMarkdownドキュメントとして書き出すスキル。「〇〇の仕組みを理解したい」「コードベースを読み解きたい」「設計の意図まで把握したい」「他の人に説明できるレベルで学びたい」「調査結果をドキュメントに残したい」など、深い理解や学習記録の作成を目的とする依頼に使用する。複数ファイルにまたがる調査や、Markdownドキュメントとして残す必要がある場合は積極的に起動する。「〇〇って何？」「ざっくり教えて」など2〜3文で答えられる一問一答の質問には使わない。

コードレビューを実施する。GitHubのPRをレビューするか、ローカルブランチの変更をレビューするかを選択できる。「PRレビューして」「#123をレビュー」「このブランチをレビューして」「変更内容を見て」のように使う。PR番号が引数にない場合も起動してよい。

報告相手に推測をさせない報告を組み立てる。結論を先に置き、完了を待たずに早く返し、 相手が抱く疑問に先回りして答える。報告だけで結論を出せない場合は相談を足す。 作業結果やステータスを報告するとき、ブロッカーや判断待ちが起きたとき、 チームや上長やSlackなどへの報告や共有の文面を整えたいときは、 明示的に指示されなくても必ずこのスキルを使う。 「報告して」「報告文を書いて」「共有文を作って」「ステータスを伝えて」 「Slackに投げる文面を作って」「PRの説明を書いて」「上長に報告したい」 「進捗を伝えて」「ブロッカーを共有したい」「相談したい」「判断を仰ぎたい」 のように使う。