oma-commit

コミットスキル - Conventional Commits

使用するタイミング

• ユーザーから「これをコミットして」「コミットして」「変更を保存して」と依頼されたとき
• /commit コマンドが実行されたとき

設定

プロジェクト固有の設定：.agents/skills/commit/config/commit-config.yaml

コミットの種類

種類	説明	ブランチのプレフィックス
feat	新機能	feature/
fix	バグ修正	fix/
refactor	コードの改善	refactor/
docs	ドキュメントの変更	docs/
test	テストの追加・変更	test/
chore	ビルド、設定など	chore/
style	コードスタイルの変更	style/
perf	パフォーマンスの改善	perf/

コミット形式

<type>(<scope>): <description>

[optional body]

Co-Authored-By: First Fluke <[email protected]>

ワークフロー

ステップ 1：変更を分析する

git status
git diff --staged
git log --oneline -5

ステップ 1.5：機能ごとに分割する（必要な場合）

変更されたファイルが複数の機能や領域にまたがる場合は、機能ごとにコミットを分割します。

分割の基準：

• スコープが異なる（例：ワークフロー、スキル、ドキュメント）
• 種類が異なる（例：feat と fix と docs）
• 論理的に独立した変更

例：

# Changed files:
.agents/workflows/*.md (7 files)     → fix(workflows): ...
.agents/skills/**/*.md (4 files)     → fix(skills): ...
USAGE.md, USAGE-ko.md               → docs: ...

# Split into 3 commits

分割しない場合：

• すべての変更が単一の機能に属する
• 変更されたファイルが少ない（5 つ以下）
• ユーザーが単一のコミットを依頼した

ステップ 2：コミットの種類を決定する

変更を分析 → 適切な種類を選択：

• 新しいファイルの追加 → feat
• バグの修正 → fix
• リファクタリング → refactor
• ドキュメントのみ → docs
• テストの追加 → test
• ビルド／設定の変更 → chore

ステップ 3：スコープを決定する

変更されたモジュール／コンポーネントをスコープとして使用します：

• feat(auth)：認証関連
• fix(api)：API 関連
• refactor(ui)：UI 関連
• スコープなしも有効です：chore: update dependencies

ステップ 4：説明を書く

• 72 文字以内
• 命令形を使用する（add、fix、update、remove など）
• 先頭の文字は小文字にする
• 末尾にピリオドを付けない

ステップ 5：コミットを実行する

コミットメッセージを表示し、確認を求めずにすぐ実行します：

📝 Committing:

feat(orchestrator): add multi-CLI agent mapping support

- Add user-preferences.yaml for CLI configuration
- Update spawn-agent.sh to read agent-CLI mapping
- Update memory schema with CLI field

Co-Authored-By: First Fluke <[email protected]>

git add <specific-files>
git commit -m "<message>"

参考資料

• 設定：config/commit-config.yaml
• ガイド：resources/conventional-commits.md

重要な注意事項

• 明示的な許可なしに、git add -A または git add . を絶対に使用しないでください
• シークレットが含まれている可能性のあるファイル（.env、認証情報など）を絶対にコミットしないでください
• ステージングには必ず具体的なファイル名を使用してください
• 複数行のコミットメッセージには必ずHEREDOC を使用してください