Menu
git差分を分析し、フォーマットに従ったコミットを自動作成する。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
いま進行中のセッションの会話の流れを5項目で要約し、コンテキストスイッチから戻った人間が状況を思い出すのを助ける。「catchup」「ここまで要約して」「どこまでやったか」「文脈を思い出したい」と指示されたときに使う。
CDK実装の一気通貫オーケストレーションワークフロー。CDK実装→コードレビュー→レビュー指摘修正→CI実行→CI指摘修正を人間への確認なしに自律実行する。CLAUDE.md の開発フロー Step 7（CDK実装）で使用。Issue番号を引数に指定すること（例: /cdk-dev 15）。frontend/backend実装には使用しない。
アプリケーション実装の一気通貫オーケストレーションワークフロー。実装（テスト変更を含む場合はTDD、含まない場合は直接実装）→コードレビュー→レビュー指摘修正→CI実行→CI指摘修正→設計書整合性チェック→設計書修正を人間への確認なしに自律実行する。CLAUDE.md の開発フロー Step 6（frontend/backend実装）で使用。Issue番号を引数に指定すること（例: /code-dev 15）。CDKには使用しない。
統合設計ワークフロー。GitHub IssueをもとにIssueを読み込み設計書（docs/design/）を更新し、自動レビューと修正まで実行する。仕様駆動開発のStep 4で使用。Issue番号を引数に指定すること（例: /design 15）
AWS CDK実装専用コマンド。GitHub IssueからCDK実装・テスト・CDK合成まで自動実行する。CDKインフラの実装を依頼されたときに使用すること。
AWS CDK インフラコードを詳細にレビュー。/cdk-review コマンドが呼ばれたとき、またはユーザーが CDK コードのレビューを依頼したときに使用する。cdk/ ディレクトリ内の TypeScript ファイルを対象に、型安全性・CDK ベストプラクティス・プロジェクトルール準拠を自動チェックする。
| name | git-commit |
| description | git差分を分析し、フォーマットに従ったコミットを自動作成する。 |
git の変更内容を分析し、適切なコミットメッセージを生成してユーザーに確認したうえで、コミットを実行するスキルです。サブエージェントを使わず、このスキル内で完結して処理します。
[!IMPORTANT] コミットメッセージの内容（なぜを書く・件名フォーマット・
(#issue番号)・本文の要否）、粒度、ブランチ命名、rebase 禁止といったルールはすべて docs/policy/git-policy.md で定義される。本スキルはそれを実行する手順だけを定義する。ルール本文はここに再掲しない（二重管理を避けるため）。判断に迷ったとき・本スキルの記述とポリシーが食い違うときは、常に git-policy.md を正とする。
作業開始前に git-policy.md を読み、以下のセクションを参照しながら進めること：
現在の状態を把握する：
git status --short
git diff --stat
git diff --cached --stat
git diff # 内容の理解に必要な範囲で
git log --oneline -5
ステータス出力の先頭2文字でステージ状態・変更タイプを判定する：
M file.ts # Modified（ステージ済み）
M file.ts # Modified（未ステージ）
A file.md # Added（ステージ済み）
?? file.txt # Untracked
type の語彙は git-policy.md「ブランチ命名規則」の prefix 表（feat / fix / refactor / chore / ci / test / docs）に従う。diff から type を推定する手順：
*.test.*, *.spec.*）のみ → testdocs/ または *.md のみ → docsfeatfixpackage.json, tsconfig.json, *.config.* など）のみ → chorerefactor / CI・GitHub Actions の変更 → ciA=feat・M=fix はあくまで目安。修正が機能追加のこともあるため、判断に迷う場合や複数解釈がある場合は AskUserQuestion でユーザーに確認する。
git-policy.md「コミットの粒度」（無関係なファイルを混ぜない）を実践する。ファイルを type × トップレベルディレクトリでグループ化し、2グループ以上に分かれる場合は分割を提案する：
docs と feat）→ type ごとに分割git-policy.md のルールに従って組み立てる。本スキルが担うのは「ポリシーを適用するための入力収集」である：
type: 説明。説明は変更内容が伝わるよう簡潔に（目安30文字以内）。(#番号) を付与する。番号はブランチ名等から推定し、不明な場合はユーザーに確認する。.env*, node_modules/, dist/・build/, .DS_Store/Thumbs.db, *.log。✓ を付ける。コミット実行前に必ずプレビューを表示し、承認を得る：
=== Git Commit Preview ===
Commit Type: feat
Message: feat: アカウント同期処理の実装 (#42)
Staged Files (will be committed):
✓ src/sync.ts
Unstaged Files (not included):
- CLAUDE.md (modified)
Warnings (if any):
⚠ .env is ignored (environment file)
Continue with commit? [Y/n]
分割する場合は各コミットの Type・Message・対象ファイルを順に列挙し、まとめて承認を得る。
承認後、グループごとに git add → git commit を実行する。
git log --oneline -n <件数> で結果を表示する。/git-commit