verify-and-ship

検証と出荷

変更を実装したら、品質を検証して作業を出荷するため、以下の手順に従ってください。

1. 受け入れ基準の検証（重要）

課題トラッカーの get_issue ツールを使って、現在の課題の詳細を取得します。課題の説明から受け入れ基準をすべて抽出し、実装によって各基準が満たされていることを検証します。明示的な基準がない場合は、課題のタイトルと説明から推測される要件に照らして検証します。

2. 品質チェック

変更した動作、リスク、既存のテスト範囲に応じて検証方法を選択します。検証は必須ですが、すべての変更で新たな自動テストや全テストスイートの実行が必要なわけではありません。該当する場合は、リポジトリ固有のチェックと CI ゲートに従ってください。

• 直接検証 — 通常のリリーススクリプト、パッケージング／ビルドメタデータ、CI、ドキュメント、手順書の編集では、十分な場合は構文チェック、安全なドライラン、成果物の確認、隔離された環境でのインストールスモークチェック、整合性レビューを優先してください。コマンドと結果、または実施したレビューを PR に記録してください。作業を示すためだけに、新しいテストファイルや検証レポートを用意する必要はありません。
• 自動テスト — 関連する既存テストを実行します。具体的で重大な障害を検出し、その保護により保守コストが正当化される場合に限り、回帰テストを追加または維持してください。例として、誤った成果物の公開、安定版タグの意図しない移動、無効なリリース証拠の受け入れなどがあります。追加するテストがどの障害を検出するかを説明してください。ドキュメントの文言やソーステキストに対する脆弱なアサーション、実装をなぞるだけのテスト、低リスクの編集に対する過剰なテスト用の仕組みは追加しないでください。スクリプトのファイル名だけでテストが必須になるわけではありません。また、重大な動作に対する保護が不要になるわけでもありません。
• 範囲 — 共通動作、障害、または未解決のリスクに応じてテスト範囲を広げてください。全テストスイートを自動的に実行したり、カバレッジレポートを作成したりしないでください。十分なチェックに合格したら、変更や新たな証拠によって再実行が必要にならない限り、繰り返し実行しないでください。関連する失敗は調査し、コマンドを変更せずに再試行しないでください。未解決の失敗があれば、正直に報告してください。
• Lint、型、ビルド — 変更したファイルに関連するチェックと、リポジトリで必須のゲートを実行してください。変更によって生じた失敗は修正してください。
• レビュー — 提案したテストが有効な保護を提供するかどうかも含め、正確性、範囲、保守性を確認してください。

リポジトリで F1 を使用している場合は、ドライブを実行したり証拠を求めたりする前に、正規の skills/f1-test-drive/SKILL.md 適用ポリシーを適用してください。適用対象外の変更では、相応のチェックを行い、PR に簡潔な注記を記載してください。F1 の実行やレポートは不要です。このスキルだけを根拠に F1 が必須だと判断しないでください。重大な障害に対する既存の保護は維持してください。

3. 変更履歴の更新

プロジェクトに変更履歴ファイルがあるか確認します。

ls -la CHANGELOG.md CHANGELOG.internal.md 2>/dev/null || echo "NO_CHANGELOG"

変更履歴ファイルがある場合は、ベースブランチとの差分を確認し、このブランチですでにエントリーが追加されているかを検出します。

# See what changelog lines this branch has added compared to the base branch
# Replace <base_branch> with the actual base branch from the issue context
git diff <base_branch> -- CHANGELOG.md CHANGELOG.internal.md 2>/dev/null

既存のエントリーの扱い：

• 差分から、このブランチですでに現在の課題に関する変更履歴エントリー（課題識別子が一致するもの）が追加されていることがわかった場合は、そのエントリーをその場で更新します（例：PR／MR リンクを追加する、説明を整えるなど）。重複したエントリーは追加しないでください。
• このブランチで別の課題に関するエントリーが追加されている場合、またはエントリーがまったくない場合は、新しいエントリーを追加します。

エントリーの追加または更新：

• 適切なサブセクション（### Added、### Changed、### Fixed、### Removed）の ## [Unreleased] の下にエントリーを配置します。
• エンドユーザーへの影響に焦点を当て、簡潔ながら具体的に記述します。
• Linear の課題識別子と PR／MR リンクを含めます（形式：([ISSUE-ID](linear_url), [#NUMBER](PR_OR_MR_URL))）。
• Keep a Changelog 形式に従ってください。

4. コミットとプッシュ

• 変更履歴の更新を含め、関連するすべての変更をステージングします。
• プロジェクトのコミット規約に従い、明確で説明的なメッセージでコミットします。
• リモートリポジトリにプッシュします。

5. PR/MR を作成または更新する

リポジトリのコンテキスト（課題のコンテキスト内の <github_url> または <gitlab_url>）からプラットフォームを特定します。プラットフォームに適したツールを使用します。

GitHub（<github_url> がある場合）

git push -u origin HEAD
gh pr view --json url,number 2>/dev/null || gh pr create --draft --base [base_branch from context] --title "[descriptive title]" --body "Work in progress"

GitLab（<gitlab_url> がある場合）

git push -u origin HEAD
glab mr view 2>/dev/null || glab mr create --draft --target-branch [base_branch from context] --title "[descriptive title]" --description "Work in progress"

PR/MR の説明

PR/MR を包括的な説明で更新します。

• 担当者の記載：担当者のコンテキストに <github_username> がある場合は、本文の先頭に Assignee: @username ([Display Name](linear_profile_url)) を追加します。Linear プロフィール URL のみがある場合は、Assignee: [Display Name](linear_profile_url) を使用します。
• 変更内容、実装方針、実施したテストの概要
• Linear の課題へのリンク
• Cyrus マーカー：本文の末尾に、非表示の HTML コメントとして `` を含めます。
• 操作のヒント：マーカーの前に、システムプロンプトの <agent_context> ブロック内にある <github_bot_username> または <gitlab_bot_username> のボットユーザー名を使って、これを追加します。<agent_context> がない場合は、cyrusagent を使用します。

  ---
  > **Tip:** I will respond to comments that @ mention @<bot_username> on this PR/MR. You can also submit a review with all your feedback at once, and I will automatically wake up to address each comment.
  

タイトルから「WIP:」または「Draft:」の接頭辞を削除します。<agent_guidance> を確認し、ドラフトのままにするよう指示されていない場合に限り、PR/MR をレビュー可能な状態にします。

PR/MR のマージ先が、課題のコンテキスト内の <base_branch> で指定された正しいベースブランチであることを確認します。