kompiro Ship Workflow
コミット済みの変更を PR 作成 → CI 確認 → クリーンアップまで進める。
/start-dev を使わずにブランチで直接開発した場合にも対応する。
前提条件
gh auth statusで GitHub 認証済みであること- 現在のブランチが
mainでないこと（機能ブランチ上であること） - コミット済みの変更があること
ホスト repo に依存する慣習について
/start-dev skill と同じ optional 仕様に従う。status: * ラベル運用、preview deploy URL 表示、CHANGELOG 維持などはホスト repo が当該慣習を採用している場合のみ実行する。
手順
0. 状態確認
スキル開始時に現在の状態を自動検出する。
- 現在のブランチ名を取得する:
git branch --show-current mainブランチ上の場合はエラーメッセージを表示して終了する- 未コミットの変更を確認する:
git status --porcelain- 未コミットの変更がある場合、
/commitスキルを実行してコミットする - コミット完了後、後続の処理を続行する
- 未コミットの変更がある場合、
- main からの差分コミット一覧を取得する:
git log --oneline origin/main..HEAD- コミットがない場合はエラーメッセージを表示して終了する
- worktree 内かどうかを判定する:
git rev-parse --show-toplevel- パスに
.claude/worktrees/または.worktrees/を含む場合は worktree 内と判定する
- パスに
- 依存関係をインストールする（
package.jsonがある場合のみ）- worktree 直後 / main から切り替えた直後 / lock file が更新された直後は
node_modulesが古く、pre-push hook の typecheck や test が依存不足で失敗する - 後続の commit / push より前に必ず実行する。host が lefthook / husky / pre-commit を採用している場合、install の
prepareスクリプトで pre-push hook も設置される - パッケージマネージャは
package.jsonのpackageManagerフィールドまたは lock file（pnpm-lock.yaml/package-lock.json/yarn.lock）から検出する - ロックファイルが最新なら即座に完了する
- worktree 直後 / main から切り替えた直後 / lock file が更新された直後は
- 関連 Issue を検出する:
- ブランチ名からパターンマッチ（例:
feat/issue-42-xxx→ #42） - コミットメッセージ内の
#Nパターン - 見つからない場合はユーザーに Issue 番号を確認する（なしも可）
- ブランチ名からパターンマッチ（例:
- CHANGELOG の追記を確認する（ホスト repo が CHANGELOG を維持している場合のみ。リポジトリ直下に
CHANGELOG.mdが無い、または Keep a Changelog 形式の## [Unreleased]見出しを持たない repo では本ステップをスキップする）- ブランチの差分が CHANGELOG に触れているか確認する:
git diff origin/main...HEAD --name-only | grep -i changelog - 触れていない場合、変更がユーザーから見える挙動・ドキュメントを変えるものなら、
## [Unreleased]節への追記をユーザーに提案する（節が無ければ先頭に作る）。CI・内部ツールのみの変更など利用者影響が無いものは追記不要 - 追記する場合は push より前に
/commitでコミットに含める（push 後に気づくと PR に追従コミットが増える） - リリース手順自体（Unreleased の版上げ → tag 等）はこのスキルの責務外。host の手順（例: README の「Releasing」節）に従う
- ブランチの差分が CHANGELOG に触れているか確認する:
1. PR 作成
リモートにプッシュする:
git push -u origin <branch-name>- host が pre-push hook を採用していれば push 時に自動実行される。
--no-verify/LEFTHOOK=0等で hook を回避しない - hook が失敗した場合は原因を直してから再 push する。failing hook を skip して
gh pr createまで進めると、CI で初めて気づき手戻りが発生する - hook を採用していない host で push 前に手元確認したい場合は、host が提供する preflight 系コマンド（例:
pnpm preflight/make check）があればそれを実行する。コマンド名は host のpackage.jsonscripts やMakefileから検出する
- host が pre-push hook を採用していれば push 時に自動実行される。
git log --oneline origin/main..HEADとgit diff origin/main...HEAD --statで変更内容を分析するPR 本文を生成する。
.github/PULL_REQUEST_TEMPLATE.mdのセクション構成に従い、コメントを実際の内容で埋める。テンプレートが無い場合は以下の最小構成にフォールバックする:- Purpose:
Closes #Nで Issue と紐付け。Issue がない場合は変更の目的を1行で記述 - Summary: コミット履歴と差分から1-3行で要約
- Changes: 主要な変更をリストで記述（コミット単位ではなく意味のある変更単位でまとめる）
- Manual Verification Checklist: CI では検証できない項目。なければ
N/A — all covered by automated tests - Related Docs: 更新した docs/ 内のファイル。なければ
N/A
- Purpose:
PR タイトルを生成する:
- Conventional Commits 形式に準拠する（例:
feat(core): add team property parsing） - ブランチのコミット群の主要な変更を反映する
- 70文字以内に収める
- Conventional Commits 形式に準拠する（例:
生成した PR タイトルと本文をユーザーに提示し、確認を得る
承認後、
gh pr createで PR を作成する:gh pr create --title "<title>" --body "<body>"PR の URL をユーザーに通知する
2. CI 確認
- PR 番号を取得する（
gh pr createの出力から） - CI の完了を待つ:
gh pr checks <pr-number> --watch - CI の結果に応じて対応する:
- 全て通過: ステップ 2.5 のポストチェックへ進む
- 失敗: 失敗したジョブのログを確認し、修正を提案する
- 修正が必要な場合: 修正 →
/commit→git push→ 再度 CI 確認
- 修正が必要な場合: 修正 →
2.5. ポストチェック
CI 通過後、以下のチェックを順に実行する。
- コンフリクト確認:
gh pr view <pr-number> --json mergeableで確認するCONFLICTINGの場合はユーザーに通知し、コンフリクト解消を案内するMERGEABLEまたはUNKNOWNの場合は次へ進む
- PR Description の言語確認:
gh pr view <pr-number> --json title,bodyで取得し、host repo の言語ポリシー（CLAUDE.md 等で定義されている場合）に沿っていることを確認する- ポリシーから外れている場合は警告し、修正を提案する
- コードレビュー:
/reviewを実行して PR の変更内容をレビューし、GitHub にレビューコメントを投稿する
すべてのチェック完了後、Issue がある場合はラベルを status: in-review に更新する（ラベル運用がある場合のみ）:
gh issue edit <N> --remove-label "status: implementing" --add-label "status: in-review"
完了メッセージ:
CI・ポストチェックが完了しました。
手動検証チェックリストの項目を確認してください。
確認完了後、GitHub 上で PR をマージしてください。
マージ後に「クリーンアップして」と言っていただければ、
ローカルブランチ（と worktree）を削除します。
ここで Claude の作業は一旦完了。 レビューと PR マージは GitHub 上でユーザーが行う。
3. クリーンアップ
ユーザーから「マージした」「クリーンアップして」等の指示を受けたら実行する。
PR の状態を確認する:
gh pr view <pr-number> --json stateマージ済みでない場合は警告し、確認を求める
マージ済みの場合、環境に応じてクリーンアップする:
worktree 内の場合（パスに
.claude/worktrees/または.worktrees/を含む）:MAIN_ROOT=$(git worktree list | head -1 | awk '{print $1}') cd "$MAIN_ROOT" git worktree remove <worktree-path> git branch -d <branch-name>通常ブランチの場合:
git checkout main git pull origin main git branch -d <branch-name>main ブランチを最新化する（worktree の場合も実行）:
git checkout main git pull origin mainIssue のラベルを更新する（Issue 紐付けかつラベル運用がある場合）:
- PR で
Closes #Nした Issue は GitHub が自動で close するため、ラベル操作は不要 - 依存していた Issue（
status: blockedのもの）があればstatus: readyに更新する:gh issue edit <blocked-issue> --remove-label "status: blocked" --add-label "status: ready" - 依存関係の判断: Issue 本文や会話の文脈から判断する
- PR で
クリーンアップ完了をユーザーに通知する
リモートブランチは GitHub 上で PR マージ時に自動削除される設定を推奨。