Ship It
出荷の完全なライフサイクルを処理します: ステージング、コミット、プッシュ、PRのオープン、マージ後の決定記録のアーカイブ、クリーンアップ。
概要
すべての変更はブランチとPRを経由します。 メインに直接プッシュすることは決してありません。このスキルは、マージ後のドキュメントアーカイブを含む、完全なラップアップサイクルを処理します。
コミットメッセージはドキュメントです。 PRタイトルはメインへのスカッシュマージコミットになり、チェンジログに表示されます。PR作成時に正しく設定しましょう。
マージ後にアーカイブし、決して前にしません。 仕様と計画はPRがマージされるまでアクセス可能です。マージ後にのみ、それらをコンパクトな決定記録に変換します。
使用するタイミング
- ユーザーが「push」「ship it」「let's ship」「open a PR」「create a PR」と言ったとき
- PRがオープンされた後、ユーザーが「merged」「it's merged」「pull and cleanup」と言ったとき
- ユーザーが実装を完了し、まとめたいとき
- 計画を完了し、次のステップとして作業を提出するとき
使用すべきでないタイミング
- ユーザーが明示的にメインに直接プッシュしたい場合（まず意図的であることを確認してください）
- リポジトリにリモートが設定されていない場合
- ユーザーがまだプッシュする準備ができていない作業中の変更の場合
- ユーザーが出荷せずにコミットだけしたい場合（
conventional-commits-and-releasesを使用してください）
プロセス
フェーズ0: 検証と検出
レッドスイートは決してPRになりません。 プロジェクトの完全なテストスイートを最初に実行します。何か失敗した場合は、失敗を報告して停止します — コミット、プッシュ、PRのオープンは行いません。このゲートはハウスポリシーであり、委任されません。
環境検出（通常のリポジトリ vs. 名前付きブランチのワークツリー vs. detached HEAD）とベースブランチの決定は、superpowers:finishing-a-development-branch に委任されます。このスキルは既に3つのケースすべてを処理しています。
正しい方法で利用可能性を確認します：自身の利用可能なスキルリストで finishing-a-development-branch を探します。 リストにあれば呼び出し可能です。リストになければ呼び出せません — フォールバックに進みます。
ファイルシステムを調査してはいけません。
~/.claude/plugins/cache/には、これまでにフェッチされたすべてのバージョンが保存されていますが、インストールされているが無効なプラグインも含まれ、スキルはプラグインキャッシュ以外のメカニズムでも提供される可能性があります。キャッシュ下にパスが存在することは、スキルを呼び出せるかどうかの証明にはなりません。
利用可能な場合 — テスト検証、環境検出、ベースブランチ決定のためにそれを呼び出し、そのオプションメニューの前で停止します。
統合の決定はハウスルールによって既に確定しており、ユーザーが再決定するものではありません：このプロジェクトはPRを通じてのみマージします。なぜならPRがプレビューデプロイメントを生成し、CIゲートとなるからです。その 「ローカルで
<base>にマージバックする」 オプションは利用できません。その 「ブランチをそのまま保持する」 オプションは有効です — それは先延ばしにする決定であり、ゲートを迂回するものではありません。
見つからない場合 — フォールバックします。正当性をゲートするものは失われません：
- テストスイートを直接実行します。
- ブランチの上流、または
mainをベースとして扱い、続行する前にユーザーに確認します。 - フェーズ6でのワークツリークリーンアップをスキップし、通常どおりブランチを削除します。
フェーズ1: ステージ & コミット
git status --short
git branch --show-current
git log --oneline @{upstream}..HEAD 2>/dev/null || echo "No upstream set"
決定ツリー:
- main上に未コミットの変更がある場合 → ブランチを作成、コミット、プッシュ、PR
- フィーチャーブランチ上に未コミットの変更がある場合 → コミット、プッシュ、PR（または既存PRを更新）
- フィーチャーブランチ上に未プッシュのコミットがある場合 → プッシュ、PR（または既存PRを更新）
- フィーチャーブランチ上に既存PRがある場合 → プッシュ（PRは既に存在）
ステージングされていない変更がある場合:
- ユーザーにすべての変更を含めるか、特定のファイルか尋ねます。
- 変更が複数の関心事にまたがる場合は、分割を提案します。
コミットメッセージを作成します:
| タイプ | 使用タイミング |
|---|---|
feat | 新しい機能 |
fix | バグ修正 |
docs | ドキュメントのみ |
chore | 設定、依存関係、ツーリング |
refactor | コード再構築、動作変更なし |
test | テストの追加または変更 |
ci | CI/CDワークフロー変更 |
フォーマット: <type>[optional scope]: <imperative description>
ルール:
- 命令形（「added」や「adds」ではなく「add」）
- コロンの後の最初の単語は小文字
- 末尾にピリオドなし
- 短く（件名は50文字以下）
- 何を行うかを記述し、どのようには記述しない
提案されたコミットメッセージをユーザーに提示し、コミット前に確認を得ます。
フェーズ2: ブランチ & プッシュ
main上にいる場合、ブランチを作成します:
<type>/<short-description>
例:
feat/oauth-loginfix/null-response-handlingdocs/release-workflow-permissions
プッシュ:
git push -u origin $(git branch --show-current)
フェーズ3: PRを開く
PRタイトル = conventional commit メッセージ（mainへのスカッシュマージに使用されます）。
PR本文の構造:
## What changed
[追加/変更/削除の具体的な説明]
## Why
[動機 — これが解決する問題は何か？]
gh CLIを使用して作成:
gh pr create --title "<conventional commit message>" --body "<PR body>"
ghが利用できない場合は、git push出力からPR URLを提供するか、構築します。
プレビュー環境が立ち上がったことを確認します。 プロジェクトがPRごとにプレビューをデプロイする場合、そのワークフローを待ち、PRを引き渡す前に環境が到達可能であることを確認します:
gh pr checks --watch
プレビューのデプロイに失敗した場合は、報告して停止します。誰もレビューできないPRは出荷されません。
このスキルが停止する場所。 ship-it はプレビューまででデプロイメント認識を終了します。ステージングや本番へのプロモーションはこのスキルの仕事ではありません — それらはプロジェクトのデリバリースキル（cloud-delivery-aks、または同等のもの）に属します。以下のフェーズ4〜6はgitとドキュメントの衛生管理であり、デプロイメントではありません。
フェーズ4: マージを待つ
PR作成後、「マージされたら教えてください。クリーンアップとアーカイブを行います。」と尋ねます。
ユーザーの確認（例: 「merged」「done」「it's merged」）を待ちます。
フェーズ5: マージ後 — 決定記録のアーカイブ
仕様と計画は設計上冗長です — 人間が履歴を読むには良いですが、Claudeが読み込むたびにコストがかかります。それらをコンパクトな決定記録に変換することで、本質的な決定を安価に読み取れるようにし、完全なナラティブはディスク上にアーカイブされたまま、誰かが意図的に開くまでコストをかけません。
PRがマージされた後にのみ、未変換の仕様/計画がないか確認します:
ls docs/superpowers/specs/ 2>/dev/null
ls docs/superpowers/decisions/ 2>/dev/null
recording-decisions スキルには、このための2つのヘルパーが含まれています。それらを見つけます — スキルはプロジェクトまたはグローバルにインストールされている可能性があります:
for base in .claude/skills ~/.claude/skills; do
d="$base/recording-decisions/scripts"
[ -d "$d" ] && echo "$d" && break
done
見つかった場合、$d/doc-archive.sh は未変換の仕様をリストし、変換プロンプトを出力します。また $d/index-rebuild.sh はインデックスを再生成します。見つからない場合は、以下の手順を使用して同じ作業を手動で行います — これらは自己完結型です。
未変換の仕様/計画が存在する場合:
-
ユーザーに尋ねます:「この作業に対応する仕様/計画が見つかりました。コンパクトな決定記録に変換し、オリジナルをアーカイブしますか？」
-
「はい」の場合、各仕様について:
- 仕様の内容を読み取ります
- YAMLフロントマター付きの決定記録を生成します:
--- title: <仕様から抽出> date: <仕様のファイル名から> component: <内容から推測> status: implemented supersedes: null dependencies: [<推測>] --- - 約30〜50行を書き、以下を捕捉します: 主要な決定、インターフェース、制約
docs/superpowers/decisions/<date>-<topic>.mdに保存します- 元の仕様を
docs/superpowers/archive/specs/に移動します - 対応する計画を
docs/superpowers/archive/plans/に移動します
-
マスターインデックスを再構築します — すべての決定記録のフロントマターから
docs/superpowers/index.mdを再生成し、アクティブな決定テーブル（コンポーネント、タイトル、日付、依存関係）と置き換えられたテーブル（コンポーネント、タイトル、置き換え元）にグループ化します。上記で見つけた場合は$d/index-rebuild.shを実行し、それ以外は直接ファイルを書き込みます。 -
アーカイブをコミットします:
git add docs/superpowers/ git commit -m "docs: archive specs and update decision index" git push
フェーズ6: クリーンアップ
git checkout main
git pull
git branch -d <branch-name>
git push origin --delete <branch-name> 2>/dev/null || true
git fetch --prune
クリーンな状態を確認:
git branch --show-current
git log --oneline -3
作業がgitワークツリーで行われた場合、解体を superpowers:finishing-a-development-branch に委任します（そのプロベナンスベースのクリーンアップ — 自身が所有するワークツリーを認識し、外部管理のものはそのままにします）。そのスキルが利用できない場合は、git worktree remove <path> で手動でワークツリーを削除し、事前にユーザーに確認します。
主要原則
- レッドスイートは決してPRになりません — 何よりも先に検証（フェーズ0）
- メインに直接プッシュしない — 常にブランチ + PR。PRはプレビューデプロイメントでありCIゲートです。ローカルマージは両方をスキップします。これは、ローカルマージを選択肢として提供するワークフローを上書きします。
- 出荷はプレビューで終了 — マージ、アーカイブ、クリーンアップは衛生管理。ステージングと本番へのプロモーションは別のスキルの仕事
- Conventional Commits — PRタイトルがチェンジログエントリ
- マージ後にのみアーカイブ — レビュー中は仕様にアクセス可能
- 決定記録はコンパクト — 約30〜50行、YAMLインデックス、LLM最適化
- 完全にクリーンアップ — 古いブランチや追跡参照を残さない