kasiopeiya
kasiopeiya/claude-dev-template
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/kasiopeiya/claude-dev-template --skill git-commit命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
RFC等の入力資料をもとに対話しながら要求を引き出し、requirements.md（PRD）を作成する。顧客が書いた「解決策」を「目的」に還元し、「制約」とされた事項が本当に制約かを疑いながら、目的の認識を合わせて要件を確定する。要求分析・要件定義・requirements.md作成を依頼されたとき、または「elicit-requirements」と指示されたときに使う。
要件定義書（docs/requirements.md）を requirements-doc-policy の基準でレビューし、凍結してよい品質かを合否判定する。「requirements-review」「要件定義書をレビューして」と指示されたとき。
アプリの設計・アーキテクチャの「質」をレビューする。UI/DB/外部サービス/言語などの詳細を差し替え可能に保てているかを検査する。「arch-review」「設計をレビューして」「アーキテクチャをレビューして」と指示されたとき。
正在显示 SKILL.md
| name | git-commit |
| description | git差分を分析し、フォーマットに従ったコミットを自動作成する。 |
git の変更内容を分析し、適切なコミットメッセージを生成し、自律的にコミットを実行するスキルです。サブエージェントを使わず、このスキル内で完結して処理します。
work（ワーキングツリーのみ）／stage（stagedのみ）で範囲を限定できるAskUserQuestion で確認してよいが、基本は自律的に判断してコミットする[!IMPORTANT] （AI・必須） コミットメッセージの内容（なぜを書く・件名フォーマット・
(#issue番号)・本文の要否）、粒度、ブランチ命名、rebase 禁止といったルールはすべて docs/policy/git-policy.md で定義される。本スキルはそれを実行する手順だけを定義する。ルール本文はここに再掲しない（二重管理を避けるため）。判断に迷ったとき・本スキルの記述とポリシーが食い違うときは、常に git-policy.md を正とする。
作業開始前に git-policy.md を読み、以下のセクションを参照しながら進めること：
引数に応じて対象範囲を決定する：
| 引数 | 対象範囲 |
|---|---|
| なし（デフォルト） | ワーキングツリー・staged 双方の差分 |
work | ワーキングツリー（未ステージ）の差分のみ |
stage | staged の差分のみ |
同じ作業ツリーを別の Claude セッションが編集していると、既定スコープは無関係な変更まで巻き込む。巻き込まれた側は自分の作業が別 Issue のコミットに紛れたことに気づけない。そこで、範囲を決めたらまず claude プロセスの数を数える。
ps -eo comm= | grep -cx claude # 自分を含む claude CLI のプロセス数（起動フラグに依存しない）
2以上なら並行セッションがある。このとき既定スコープを「このセッションで自分が Edit/Write したファイルのみ」に切り替える（引数 work / stage の指定も、この絞り込みの中で適用する）。切り替えたことと、除外したファイルのパスを Phase 5 の出力に列挙する。
1なら単独セッションなので、既定スコープをそのまま使う。
範囲を決めたら現在の状態を把握する。スコープに不要なコマンドは実行しない（work なら staged 側、stage なら worktree 側は取得不要）。依存関係のないコマンドは1回の Bash 呼び出しにまとめる：
git status --short # 常に取得
git diff --stat # スコープが「なし」または work のときのみ
git diff --cached --stat # スコープが「なし」または stage のときのみ
git diff（内容）と git log --oneline は無条件に取得しない。Phase 2 の type 判定・Phase 3 の本文執筆で実際に必要になった時点で、必要な対象だけに絞って取得する（type がファイル名だけで判定できるならどちらも不要）。
ステータス出力の先頭2文字でステージ状態・変更タイプを判定する：
M file.ts # Modified（ステージ済み）
M file.ts # Modified（未ステージ）
A file.md # Added（ステージ済み）
?? file.txt # Untracked
type の語彙は git-policy.md「ブランチ命名規則」の prefix 表に従う（末尾の / を除いたものが type）。まずファイル名・パス・ステータス（A/M）だけで判定を試み、それで確定しない場合のみ diff 内容を取得する：
| 材料 | type |
|---|---|
テストファイル（*.test.*, *.spec.*）のみ | test |
docs/ または *.md のみ | docs |
設定ファイル（package.json, tsconfig.json, *.config.* など）のみ | chore |
| CI・GitHub Actions の変更 | ci |
| ソースの新規追加（A）による機能拡張 | feat |
| ソースの修正（M）によるバグ修正 | fix |
| 振る舞いを変えない構造変更 | refactor |
A=feat・M=fix はあくまで目安。修正が機能追加のこともあるため、ファイル名だけでは判断がつかない場合に限り diff 内容（該当ファイルのみ）を読む。それでも判断に迷う場合や複数解釈がある場合は AskUserQuestion でユーザーに確認する。
git-policy.md「コミットの粒度」（無関係なファイルを混ぜない）を実践する。ファイルを type × トップレベルディレクトリでグループ化し、2グループ以上に分かれる場合は分割して進める：
docs と feat）→ type ごとに分割分割方針は基本的に自律的に決定する。グループ分けの妥当性にどうしても迷う場合のみ AskUserQuestion で確認してよい。
git-policy.md のルールに従って組み立てる。本スキルが担うのは「ポリシーを適用するための入力収集」である：
type: 説明。説明は変更内容が伝わるよう簡潔に（目安30文字以内）。(#番号) を付与する。番号はブランチ名等から推定し、不明な場合はユーザーに確認する。work/stage 指定範囲）に含まれるソース・ドキュメント・設定・テストの各変更ファイルを対象に含める。単独セッションなら、セッション内で編集したかどうかは問わない。.env*, node_modules/, dist/・build/, .DS_Store/Thumbs.db, *.log。並行セッションを検出したときは、このセッションで Edit/Write していないファイルも除外して警告表示する。✓ を付ける。ユーザー承認は求めず、自律的に実行する。グループごとに git add → git commit を行う。
=== Git Commit Summary ===
Commit Type: feat
Message: feat: アカウント同期処理の実装 (#42)
Committed Files:
✓ src/sync.ts
Excluded (warnings):
⚠ .env is ignored (environment file)
⚠ docs/guide/foo.html — 並行セッションを検出したため除外（このセッションで編集していない）
分割する場合は各コミットの Type・Message・対象ファイルを順に列挙する。
git log --oneline -n <件数> で結果を表示する。/git-commit # デフォルト：ワーキングツリー＋staged全差分が対象
/git-commit work # ワーキングツリー（未ステージ）のみ対象
/git-commit stage # stagedのみ対象