amanjotx/Agent-Skills

/ship

現在の作業をコミットし、プッシュし、プルリクエストを開く。このスキルを呼び出すことは、ブランチの作成/切り替え、コミット、プッシュ、gh pr createの実行に対する明示的な許可を与えます。

厳格なルール

• ユーザーのgit安全プロトコルに従うこと：git configを変更しない、フックをスキップしない、main/masterに強制プッシュしない、修正ルールが完全に満たされた場合のみ修正する。
• 機密情報（.env、認証情報、秘密鍵、トークン）をコミットしないこと。存在する場合は警告し、除外すること。
• この変更に属するファイルのみをステージングすること。ツリーが明らかに意図的でジャンクがない場合を除き、git add .やgit add -Aのような包括的なステージングは行わないこと。
• コミットメッセージとPR本文にはHEREDOCを使用すること。
• このワークフローはプロジェクトに依存しないこと。検証コマンドとレイアウトはリポジトリから推論し、アプリ名やパッケージ名をハードコードしないこと。
• 完了したらPR URLを返すこと。

従来のコミットプレフィックス

プロダクションレベルの従来のコミットを使用すること。1つのプライマリタイプを選択：

プレフィックス	使用タイミング
feat	新しいユーザー向け機能
fix	バグ修正
refactor	動作変更を意図しない内部再構成
perf	パフォーマンス改善
chore	メンテナンス、ツール、依存関係、ハウスキーピング
docs	ドキュメントのみ
test	テストのみ
ci	CI設定/パイプライン
build	ビルドシステムまたはバンドラーの変更
style	ロジック変更のないフォーマット/リンタ駆動のチャーン
revert	以前のコミットを元に戻す

フォーマット：

type(optional-scope): 命令形の要約

オプションの本文：この変更が存在する理由（1～2文）

例：feat(auth): リフレッシュトークンのローテーションを追加、fix: チェックアウト時の二重送信を防止、chore: lint設定を更新

ワークフロー

1. 調査（並列実行）

• git status
• git diffおよびgit diff --staged
• git branch -vv（カレントブランチ+追跡情報）
• git log -8 --oneline（メッセージスタイル）
• デフォルトのベースブランチ（main優先、なければmasterまたはリポジトリのデフォルト）
• リモート同期状態（git status -sb、未プッシュのコミット）

コミットするものや、この作業に関連する未プッシュのコミットがない場合は停止する。空のPRを開かないこと。

2. 正しいブランチの確保

目標：最新のベースに基づく専用の機能ブランチに作業を置く。

1. 現在のブランチがこれらの変更に適しているか判断する：

   • すでにこの作業の記述的なトピックブランチ（feat/…、fix/…、chore/…、または変更意図に明確に一致するもの）であり、かつデフォルトブランチではない場合は「はい」。
   • main/master/デフォルト、一致しないトピックブランチ、古い無関係なブランチ、またはデタッチドHEADの場合は「いいえ」。

2. 現在のブランチがこれらの変更に適していない場合：

   • ワーキングツリーがダーティな場合は、明確なメッセージを付けてstashする（デフォルト；stashが不可能でない限り確認しない）。
   • git checkout <base>
   • git pull --ff-only（または追跡リモートからの同等のfast-forward更新）
   • 新しい記述的なブランチを作成してチェックアウトする。例：feat/short-topic、fix/short-topic、chore/short-topic
   • 新しいブランチにgit stash popする。競合があれば解決する。

3. 現在のブランチがこれらの変更に適している場合：

   • そのままにする。
   • コミット前に、必要に応じてベースから更新する（リポジトリの慣行に従い、最新のベースからリベースまたはマージ；非破壊的なオプションを優先；ユーザーが明示的に要求しない限り強制プッシュしない）。

デフォルトブランチから直接PRを構築しないこと。

3. コミット

• ユーザーが分割を要求しない限り、1つの一貫したコミットを優先する。
• メッセージは適切な従来のプレフィックスと命令形の要約を使用する。
• 本文（オプション）：なぜに焦点を当て、ファイルリストではない。
• コミット後、git statusを実行して期待通りの状態を確認する。
• フックが失敗した場合：問題を修正し、新しいコミットを作成する。修正ルールが完全に満たされない限り、修正しない。

4. プッシュ

git push -u origin HEAD

サンドボックス/ネットワーク/ghが操作をブロックした場合、必要な権限を要求する。

5. PRを開く

ベースにマージされるすべてのコミットを分析する（最新のみではない）。

タイトル： コミット要約と同じ精神 — 明確で、具体的で、役立つ場合は従来のプレフィックスを使用する。曖昧なタイトルは禁止。

本文テンプレート（必須）：

## サマリー

- 何が出荷され、なぜ重要かについて2～5個の箇条書き

## 理由

- この変更の背景、動機、またはトリガー

## 変更内容

- 関心事ごとにグループ化された箇条書き（動作、API/契約、データ、UI、インフラ、テスト、ドキュメント）
- 破壊的変更、移行、または認証/セッション動作の変更を明示的に指摘する

## アーキテクチャ/フロー

以下を少なくとも1つ含める：

1. プライマリパスのMermaid図（シーケンス、フローチャート、または状態）
2. 構造、階層、またはbefore→afterのASCII図

制御フローにはMermaid、ツリーやレイヤーマップにはASCIIを使用する。
図は実際の差分と一致しなければならない — アーキテクチャをでっち上げないこと。

## リスク/ロールバック

- 考えられる障害モード
- 安全な復元/緩和策のメモ

## テスト計画

- [ ] レビューアが実行できる具体的な手順
- [ ] プロジェクトから発見された、リポジトリに適した検証コマンド

gh pr createとHEREDOC本文を使用して作成する。必要に応じて--baseを明示的に設定する。

6. 報告

簡潔に：

• ブランチ名
• コミット要約
• PRタイトル
• PR URL
• 意図的にコミットされていないファイル