ship
検証済みの作業をステージング、コミット、およびオプションでプッシュできます。複数ファイルのキャンペーン、コミットのグループ化、メッセージの作成、テンポラリファイルや機密ファイルの除外に対応しています。
description の原文を見る
Stage, commit, and optionally push validated work. Handles multi-file campaigns, commit grouping, message drafting, and exclusion of temp/sensitive files.
SKILL.md 本文
Ship — コミット & デリバリー
検証済みの作業をクリーンな git コミットにパッケージ化します。ステージング、コミットメッセージの作成、ファイルグループ化、およびコミットすべきでないファイルの除外を処理します。
push を除くすべてのコマンドは自動的に完了まで実行されます。push は常にユーザーに先に確認します。
設定: .claude/skills/project.toml — プロジェクト固有のパス、コマンド、モジュール
コマンド
| コマンド | 使用方法 | 目的 |
|---|---|---|
commit | /ship または /ship commit | 現在のすべての変更をステージして 1 つのコミットで確定 |
split | /ship split | 関心事ごとに変更をグループ化して複数のコミットを作成 |
preview | /ship preview | ドライラン: コミットせずに何がコミットされるかを表示 |
push | /ship push | 現在のブランチをリモートにプッシュ (先に確認) |
コマンドが指定されない場合は commit がデフォルトです。
セットアップ: 設定を読み込む
すべてのコマンドの前に、プロジェクト設定を読み込みます:
.claude/skills/project.tomlを読み込むsplitモードでのファイルグループ化用に[modules]を抽出- プロジェクト固有の除外および警告用に
[ship]セクションを抽出:exclude-extra— ユニバーサル除外を超えてコミットしないよう追加パスwarn— ステージするがレビュー用にフラグを立てるファイル
- 追加の除外用に
.gitignoreを読み込む
project.toml が存在しない場合は、ユニバーサル除外リストを使用し、ディレクトリ構造からファイルグループを自動検出します。
コマンド: commit — 単一コミット
すべての変更をステージして、構造が整った 1 つのコミットを作成します。
手順:
-
ワーキングツリーを調査:
git status --short git diff --stat HEAD -
すべてのファイルを次のいずれかに分類:
カテゴリ アクション 例 ship ステージしてコミット ソースファイル、設定、ドキュメント skip ステージしない テンポラリファイル、ビルド出力、シークレット、DB ファイル warn ステージするがフラグを立てる [ship].warn設定のファイルユニバーサル除外 (いかなるプロジェクトでもコミットしない):
__pycache__/,*.pyc— Python バイトコード.env,credentials.*,*.key,*.pem— シークレットnode_modules/— JS 依存関係dist/,bin/,obj/— ビルド出力*.db,*.db-wal,*.db-shm— データベースファイル.gitignoreにマッチするファイル
project.toml の
[ship].exclude-extraからのプロジェクト固有の除外。project.toml の
[ship].warnからの警告ファイル。 -
カテゴリごとにファイルをステージ。
git add -Aではなく明示的なファイルパスを使用:git add <file1> <file2> ...大規模な場合はディレクトリごとにバッチ処理:
git add agents/*.md git add tests/test_*.py -
コミットメッセージを作成。 ステージされた変更を分析して以下を決定:
- 型: 変更の種類 (feature、refactor、fix、test、docs、chore)
- スコープ: コードベースのどの領域
- サマリー: 1 行の説明 (72 文字以下)
- 本文: 変更内容と理由の箇条書き
プロジェクトの既存のコミットスタイルに従う (
git logから):<サマリー行 — 何が変わり、なぜか> - 詳細 1 - 詳細 2 -
HEREDOC を使用してコミットを作成:
git commit -m "$(cat <<'EOF' サマリー行 - 詳細 1 - 詳細 2 EOF )" -
検証:
git log --oneline -1 git status --shortコミットハッシュと残りのステージされていないファイルをレポートします。
コマンド: split — 関心事ごとの複数コミット
変更を論理的なコミットにグループ化し、関心事ごとに 1 つのコミットを作成します。
手順:
-
ワーキングツリーを調査 (
commitの手順 1 と同じ)。 -
ファイルをグループに分類。 project.toml から
[modules]を利用可能な場合は使用します — 各モジュールカテゴリがコミットグループになります。モジュール設定が存在しない場合は、ディレクトリ構造からグループを推測:ヒューリスティック グループ名 ルートレベルのソースファイル coretests/ディレクトリtestsdocs/、ルートの*.mddocsscripts/ディレクトリscripts設定ファイル ( .gitignore、requirements.txtなど)infraその他のディレクトリ ディレクトリ名をグループとして使用 ファイルが複数のグループに属する場合は、最も影響が大きいグループに割り当てます。大規模で混在したコミットより、小規模で焦点を絞ったコミットを優先します。
-
各グループについて (依存順 — infra 優先、state 最後): a. そのグループのファイルのみをステージ b. そのグループ固有のコミットメッセージを作成 c. コミットを作成 d. 成功を検証
-
作成されたコミットの完全なリストをレポート:
git log --oneline -N
グループの順序:
各コミットが前のコミットの上に構築されるように、この順序でコミット:
infra— 設定、依存関係- コアソースファイル (バックエンド、ライブラリ)
- API / ルーティングレイヤー
- フロントエンド / UI
- スクリプト / ツール
- テスト
- ドキュメント
- エージェント仕様 (存在する場合)
- 状態/トラッカーファイル (常に最後)
エッジケース:
- グループに重要でないファイルが 1 つだけ含まれている場合は、最も関連のあるグループにマージ
- すべての変更が 1 つのグループに含まれている場合は、単一コミットにフォールバック (
commitと同じ) - 空のコミットを作成しない
コマンド: preview — ドライラン
変更を加えずに何がコミットされるかを表示します。
手順:
-
ワーキングツリーを調査。
-
すべてのファイルを分類 (ship / skip / warn)。
-
splitモードが適用される場合は、提案されたグループとコミットメッセージを表示。 -
レポート:
- コミットするファイル (分割する場合はグループ割り当て付き)
- スキップするファイル (理由付き)
- 警告するファイル
- 提案されたコミットメッセージ
- 問題 (コミットされていないシークレット、大規模ファイルなど)
ステージ、コミット、または変更を行わない。
コマンド: push — リモートにプッシュ
現在のブランチをリモートにプッシュします。常にユーザーに先に確認します。
手順:
-
デフォルトブランチを検出してリモートステータスを確認:
git remote -v BASE=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||') || BASE="main" git rev-list --count "origin/$BASE..HEAD" 2>/dev/null -
プッシュされる内容を表示:
git log --oneline "origin/$BASE..HEAD" -
プッシュの前にユーザーに確認を要求。 以下を表示:
- コミット数
- ブランチ名
- リモート名
- 強制プッシュのリスク
-
確認時:
git push -u origin <branch> -
プッシュ結果をレポート。
安全ルール:
- ユーザーが明示的にリクエストしない限り 強制プッシュしない
- main/master へのプッシュ時に 常にユーザーに警告
- プッシュを実行する前に 常に何がプッシュされるかを表示
- このコマンドはユーザー確認が必要な唯一のコマンド
ファイル分類
ユニバーサル除外 (ステージしない):
__pycache__/,*.pyc— バイトコード.env,credentials.*,*.key,*.pem— シークレットdist/,bin/,obj/— ビルド出力node_modules/— 依存関係*.db,*.db-wal,*.db-shm— データベースファイル.claude/worktrees/— エージェントワークツリー.gitignore内のファイル
プロジェクト固有の除外:
project.toml の [ship].exclude-extra から読み込みます。これらはコミットすべきでないプロジェクト固有のパス (テンポラリディレクトリ、ローカル設定など)。
警告ファイル:
project.toml の [ship].warn から読み込みます。これらのファイルはステージされますが、ユーザーがレビュー用にフラグを立てられます (状態ファイル、トラッカーファイルなど)。
その他すべて:
ソースファイル、設定、ドキュメント、テスト — 通常通りステージしてコミット。
規約
- プロジェクトの既存のコミットメッセージスタイルに従う (
git logから確認) - HEREDOC をコミットメッセージに使用してフォーマットを保持
- git フックをスキップしない (
--no-verify) - 明示的なリクエストなしにコミットを修正しない
- プロジェクトまたはユーザーが明示的に要求しない限り共著者行を含めない
git add -Aよりgit add <file>を優先- プロジェクトスタイルの規約ファイルを読み込む (project.toml の
[project].conventions)
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- espensev
- リポジトリ
- espensev/ai-skills
- ライセンス
- MIT
- 最終更新
- 2026/3/25
Source: https://github.com/espensev/ai-skills / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。