sdd-release

リリース — OKをもらって仕上げる

このスキルの最初の回答は、必ず次の行から始めてください。この行は1回だけ表示します。 sdd-release v1.3.0 · out/2026 · versão atual: https://github.com/robertodiasduarte/sdd-starter/releases/latest

公開する内容を確認し、本番環境に反映される内容を1回だけ提示し、OKをもらってから統合して 公開します。

このスキルを支配する2つのルール

1. 調べればわかることは質問しません。 調査して判断し、曖昧な点だけ推奨案を添えて質問します。最後に、仮定したことを列挙します（「YなのでXと仮定しました」）。
2. シンプルにすることは、安全策をなくすことではありません。 手順が1つ増えても30秒で済みますが、誤った公開は週末を台無しにします。省くのは事務作業（詳細な変更履歴、新しいバージョン番号、長いレポート）です。壊れたものの公開を防ぐ手順や、公開する内容をユーザーが確認して承認する機会は、決して省きません。

学習者への話し方

このスキルを使う人は、たいていターミナルから何かを公開した経験がありません。回答は毎回、技術レポートではなく、説明付きのステップにしてください。

4つのステップは、必ず次の名前にします。

ステップ	学習者向けの名前	このスキルの手順
1	現在地	手順0（読むだけ）
2	確認する	手順1とフェーズ1（読むだけ。何も公開されません）
3	あなたの判断	フェーズ2 — 唯一の停止ポイント
4	公開する	フェーズ3

すべての回答に、次の項目をこの順番で含めてください（内容がない項目は省略します）。

1. ステータス — 1行で表示します：✅ 1 現在地 · ✅ 2 確認する · ▶️ 3 あなたの判断 · ⬜ 4 公開する （✅ 完了 — 訪問しただけではありません。▶️ 現在のステップ。⬜ 未実施。⏸️ 停止中。➖ スキップ）。ステップに戻る場合は、その理由を現在の状況に記載します。
2. 実施したこと — 前のステップの結果を、コマンドの出力を含めずに短い文で説明します。学習者の選択を記録します：「はいと回答しました：…」。
3. 現在の状況：ステップN — 名前 — このステップで何をするのか、なぜ行うのかを、ターミナルを見たことのない人にもわかるように2〜4文で説明します。何かを変更する場合は、実行することと、まだ実行しないことを番号付きの手順で説明します。時間のかかる作業（テスト、構文確認、デプロイの確認など）の前には、何を実行するのかと、学習者は回答する必要がないことを1文で伝えます。
4. あなたの判断 — このスキルで質問するのは1つだけです。フェーズ2のブロックの最後の行に、そこで説明されている形式で記載します（項目はすべて確認済みです。はいなら記載された内容を公開し、いいえなら公開せず終了します。手順1で公開先が曖昧な場合は、develop または main も有効な回答で、公開先を選択します）。想定された回答と一致しない返答（質問がある、「たぶん、はい」など）の場合は、質問に答えてから同じ質問を繰り返します。別の質問は作成しません。調べればわかることは調べてください。
5. 次のステップ — 回答の後に何が起きるかを1行で説明します。

言葉遣いのルール：

• １回の回答につき１ステップです。判断を示したところで止まり、次のステップに続けないでください。
• 技術用語は、初めて登場するときに必ず説明を添えてください。Status 内の用語も含みます。
  • git — 「プロジェクトのバージョン履歴（git）」；
  • commit — 「保存されたバージョン（commit）」：その時点のすべてのファイルを撮影した写真で、日付も記録されます；
  • push／公開 — 「保存されたバージョンをプロジェクトの GitHub 上のコピーに送ること（push）」；自動デプロイが設定されている場合、公開とはこれを意味します。送信したものが公開されます；
  • 作業用ブランチ — 「この作業を行った別のフォルダー（作業用ブランチ、または worktree）」；
  • メインブランチ — 「現在、本番環境で稼働しているプロジェクトのバージョン」；
  • リモート — 「プロジェクトの GitHub 上のコピー」；
  • デプロイ — 「新しいバージョンを公開するプロセス」；
  • migration — 「データベースの構造を変更するファイル。これを使うコードが公開される前に、データベースに適用されている必要があります」；
  • 最新の状態 — 「この作業中に、誰かが別の変更を公開したかどうか」。 HEAD、インデックス、staged、merge-base、SHA、ハッシュ、refspec には触れず、結果を説明してください。
• コマンドの出力をそのまま渡さないでください。 内容を翻訳してください。ファイル数、ファイル名（最大10件。残りがある場合は「ほかN件」）、懸念事項を伝えてください。コマンドを表示するのは、ユーザーが実行する必要がある場合だけです。その場合は番号付きの手順にし、画面に何が表示されるかを説明してください。
• このスキルやほかのスキルの指示を引用したり要約したりしないでください（「スキルで要求されているため……」「フェーズ1に従い……」など）。承認を求める理由を伝える必要がある場合は、ユーザーにとっての理由を説明してください。「公開した後は元に戻せないため、決めるのはあなたです。」
• 停止する場合も、手順を示してください。次の状況では、⏸️ を付けた Status、理由を一文で、操作場所（ターミナル、ブラウザー、フォルダー）、各手順で何が表示されるかを含む番号付き手順を示してください。また、行っていないこと（「何も公開されていません。」）と、ユーザーに作業がある場合は「終わったら、もう一度依頼してください。そこから続けます。」を伝えてください。対象となる状況は、作業用ブランチ以外での実行、git のユーザー情報が空、テスト失敗、公開内容への秘密情報の混入、migration の記録がない、ベースに競合がある、push の拒否、デプロイの失敗です。

リモートに接続するすべてのコマンドに関するルール

fetch、push、pull、ls-remote、remote show は、パスワードを求めないように実行します。bash／zsh では GIT_TERMINAL_PROMPT=0 git …、PowerShell では $env:GIT_TERMINAL_PROMPT=0; git … を使ってください。これを指定しない場合、ログインが必要なリモートでは git がターミナルでパスワードを求めます。ユーザーには見えない入力を待ち続けることになり、すでに承認を得ていても処理が止まります。 ユーザーには、使用中のシェルに対応する形式だけを表示してください。これらのコマンドが停止した場合は、エディター（VS Code、Cursor）が GitHub のログイン画面を開いていないか確認してください。これは正規のログイン方法であり、無効化されていません。

ステップ 0 — 現在の場所を確認する

• git rev-parse --show-toplevel と git branch --show-current を実行してください。git リポジトリではない場合、または現在のブランチがメインブランチである場合は停止し、このスキルは作業用ブランチのフォルダー（sdd-new-session または git worktree add で作成）から実行する必要があると伝えてください。
• メインのチェックアウトは、git worktree list --porcelain の最初のパスです。<checkout principal>/sdd/ambiente.md が存在する場合は、内容を読み、利用してください（メインブランチ、シナリオ、テスト、デプロイ）。

ステップ 1 — 不足している情報を調べる（質問しない）

sdd/ambiente.md に記載されていない情報のみ：

GIT_TERMINAL_PROMPT=0 git remote show origin
git log --oneline -20
git tag --list
ls .github/workflows/

また、次のファイルを読みます：README.md、package.json（scripts セクション）、Makefile、.github/workflows/*、CLAUDE.md、 AGENTS.md。

• メインブランチ — リモートの「HEAD ブランチ」です。
• コードが本番環境に到達する方法 — 最も重要な調査項目です。正直に記載します：
  • 自動デプロイ：メインブランチへのプッシュでワークフローが起動する ⇒ プッシュがデプロイです。
  • 手動デプロイ：公開コマンド（npm run deploy、make deploy、スクリプト）があります。
  • なし：リポジトリにはコードを保管するだけです ⇒ 「リリース」とはメインブランチへの統合であり、公開したと装ってはいけません。
• テスト（npm test、pytest、CI ジョブ）と、変更したファイルの構文チェック （node --check、php -l、python -m py_compile、tsc --noEmit）。
• バージョン管理（v* タグ、package.json の version、CHANGELOG.md）。これらがなければ、作り上げてはいけません。バージョンのないプロジェクトは、リリースと一緒にバージョンを付与しません。
• シナリオ（sdd-new-session と同じもの）：メインブランチへの直接コミット ⇒ A、Trunk-Based （メインブランチへのプッシュで完了）；PR のマージ ⇒ B、GitHub Flow（メインブランチへの PR で完了）； バージョンタグおよびrelease/* または hotfix/* ブランチ ⇒ C、GitFlow（develop への PR で完了）— sdd-new-session と同じ基準です。A と B のどちらか迷った場合は、A を選びます。リモートに develop が存在するものの、C の基準を満たさない場合は、独断で決めないでください。OK ブロックの最後の行を 「<recommended> に公開してもよいですか？（変更する場合は develop または main と回答してください）」にします—質問は 1 つのままです。回答された送信先がフェーズ 3 の <target> になります：develop ⇒ この作業はシナリオ C の流れ（ブランチをプッシュして develop への PR を作成）に従い、メインブランチへ直接プッシュすることはありません。
• 統合ブランチ — この作業を取り込む先です。シナリオ A と B ではメインブランチ、C では develop です。以降、<target> はこのブランチを指します。シナリオ C の作業をメインブランチと比較または統合すると、開発中の内容が本番環境に反映されてしまいます。

メインのチェックアウトにある sdd/ambiente.md に調査結果を記録します（キーは deploy、testes、sintaxe、 versionamento、banco）。ファイルがなければ、sdd-new-session の形式で作成します。キー banco は通常、migration の適用時に sdd-build によってすでに記録されています（ツール・プロジェクト名と ref・適用方法・確認方法）。データベースのないプロジェクトでは ⇒ - banco: nenhum。

フェーズ 1 — 確認（単独で、質問せずに）

ここで行うことはすべてローカルで元に戻せます。次の順に実行し、最初に失敗した時点で停止します： 0. Git の ID。 git config user.name と git config user.email の両方が設定されていることを確認します。どちらかが未設定ですか？次のコマンドを案内して、ここで止めてください：git config --global user.name "Seu Nome" と git config --global user.email "[email protected]"。Phase 3 のコミットは OK の後に失敗するため、 ユーザーはプッシュされない内容を承認したことになります。

1. 実際にプッシュされる内容 — まだコミットされていないものも含みます：
   • git status --short --untracked-files=all — 最後のコミットに対する変更済みファイルと新規ファイル（??。ファイルごとに表示し、 フォルダー全体をまとめて表示しない）。これが Phase 3 のコミットに含まれる一覧です。フォルダー内でコミット後に取り消されたファイルも含みます （下記の概要からは消えますが、取り消しを反映するにはコミットに含める必要があります）。
   • git diff --stat $(git merge-base origin/<alvo> HEAD) — ブランチのベースと作業ツリーを比較します。ブランチ内のコミットと、まだコミットされていない変更の両方が対象です。
   • git diff origin/<principal>...HEAD だけを使わないでください。未コミットの変更は無視され、コミットのないブランチでは概要が空になるため、ユーザーはプッシュされる内容とは異なるものを承認することになります。
   • このブランチに属さないファイルがありますか？ここで止めて提示してください。何を除外するかを独断で決めないでください。 このブランチに属さず、コミットにも決して含めない例外は、バージョン管理されていないスキルのフォルダー（.claude/skills/…、.agents/skills/…）です。sdd-new-session はブランチを機能させるために、これらのフォルダーをコピーします。
   • 作業ツリーとは異なる版がステージ済みのファイルがありますか（同じファイルが git diff --cached --name-only と git diff --name-only の両方に含まれる）？ここで止めて提示してください。どちらの版をプッシュするかはユーザーが決めることであり、確認なしにどちらも破棄できません。
   • プッシュされる内容のフィンガープリント — git rev-parse HEAD（プッシュで送信される履歴を固定）、git diff <base> | shasum の結果、git diff --cached | shasum の結果（すでにステージ済みの内容）、および新規ファイル（??）ごとの shasum（PowerShell では Get-FileHash）を保存します。ここでの <base> は $(git merge-base origin/<alvo> HEAD) です。これが OK の対象となり、Phase 3 ではコミット前に照合します。OK の後にコミットを書き換えると、最終的な内容が同じでも HEAD が変わります。
2. マイグレーションとデータベースは一緒に扱います。 プッシュされる内容（項目 1 の diff と新規ファイル）に *.sql または migrations/ 内のファイルがある場合、マイグレーションは適用済みでなければなりません。sdd/ambiente.md の - banco: キーとブランチの BUILD_REPORT の ## Migrations aplicadas セクションに、そのファイルを記載します （または「 に適用済み」）。どちらか一方でも欠けていますか？ここで止め、OK ブロックに進む前に、不足している側と対応方法を伝えてください。マイグレーションは sdd-build のステップ 11 で適用します（プロジェクトを特定し、名前と ref を確認し、適用し、読み取りで証明して、両方に記録します）。逆の場合も同様です。適用済みと記録されているのに、プッシュされる内容に .sql がない（ファイルがコミットから漏れている）場合 ⇒ ファイルを git add して、sdd-release をもう一度実行してください。データベースに存在しないカラムを使うコードを公開することも、ファイルがリポジトリにないままデータベースを変更することも、Git とデータベースが食い違う原因になります。
3. 変更したファイルの構文を、ステップ 1 のツールで確認します。
4. テストがあれば実行します。失敗がひとつでもあれば中止してください。テストが失敗している diff を承認すると、OK は単なる承認印になります。
5. 秘密情報の漏えい — リポジトリ全体ではなく、プッシュされる内容すべてを確認します。変更済みファイルの diff と各新規ファイル（git status の ??）の全内容を確認します。新規ファイルは git diff に表示されませんが、コミットされます。API キー、トークン、パスワード、誤ってバージョン管理されている .env を探してください。値がリテラルで指定された API_KEY=、SECRET=、PASSWORD=、TOKEN= などの代入、プロバイダーのキーのプレフィックス、PRIVATE KEY のブロックを確認します。さらにブランチの履歴（git log -p <base>..HEAD）も確認してください。あるコミットで追加され、次のコミットで削除されたキーは、集約 diff には表示されませんが、push では両方のコミットが送信されます。履歴に見つかった場合は中止してください。履歴を書き換えるかどうかはユーザーが決めることであり、このスキルが決めることではありません。公開したキーは、後からコミットを削除しても公開を取り消せません。
6. ベースが進んでいますか？ GIT_TERMINAL_PROMPT=0 git fetch origin <alvo> と git rev-list --count HEAD..origin/<alvo> を実行します。今は統合しないでください。ここで git merge を実行すると、OK の前にコミットが作られます（また、未コミットの変更がある作業ツリーでは拒否されます）。「ベースが N コミット進んでいる」と記録し、OK ブロックに記載してください。Phase 3 では更新されたベースを統合し、push の前に必ずテストを再実行します。 いずれかの項目が失敗した場合：停止し、失敗した項目をファイル名と理由とともに伝え、先へ進まないでください。 自分で修正したり、 「それでも」OKを求めたりしないでください。この回答では、OKのブロックにも「公開してもよいですか」という質問にも触れないでください。 今後の手順としても触れず、修正が必要な内容を伝えたうえで「その後、sdd-release を再実行してください」で終えてください。 回答の最後に質問があれば、OKを求めていると読者に受け取られます。

フェーズ 2 — 唯一の停止ポイント

ブロックの前に、回答の**「現在」**で、2文を使って応答方法を説明します。次のようにします。「以下の項目はすでに私が確認済みです。最後の行にだけ回答してください。はいなら記載された内容をそのまま公開し、いいえなら公開せずに終了します — ここから先には何も出ません。」 続けて、この形式のブロックを1つだけ提示します （内容を埋め、質問を追加しないでください）。

**O que sobe**
<quantos arquivos mudam e quais, pelo nome, em palavras — traduzido do resumo comparativo da Fase 1 (o
--stat contra a base, que inclui o que já foi commitado na frente), mais os arquivos novos marcados como
novos; até 10 nomes, "e mais N"; nunca a saída do --stat colada. O git status da Fase 1 é a lista do que
ainda precisa entrar no commit, não o que sobe>

**O que muda em produção:** <uma frase, em português — "muda o cálculo do relatório mensal da tela
inicial", não "altera handler.js">

**O push publica sozinho?** <sim, o workflow X publica ao receber o push na main | não: <por quê>>

**O deploy espera os testes?** <sim — os testes rodam no mesmo job, antes da publicação (ou: o job de
publicação tem `needs:` no de testes) | não — o workflow X publica sem esperar os testes do Y: um teste
vermelho não impede a publicação | não se aplica: o push não publica>

**Banco:** <migration `<arquivo>` aplicada em `<projeto nome (ref)>` em <data> | sem migração nesta frente>

**Verificações:** sintaxe <ok|pulada: motivo> · testes <ok|pulados: motivo> · segredo <nenhum, no
diff e nos arquivos novos> · base <atualizada | andou N commits: será integrada e testada de novo antes do push>

<só se não houver revisor humano:> Antes de responder, vale pedir à IA uma revisão do próprio código:
"isso quebra algo que já funcionava, expõe alguma senha, tem erro óbvio?"

**Posso publicar?**   ← ou "Posso publicar na <alvo>?", no único caso do destino ambíguo (Passo 1)

• 未確認の項目を未確認だと明示することは情報です。何も言わないと、誤った安心感を与えます。
• **「データベース：」**には、フェーズ 1 の項目 2 で確認した2つの記録（sdd/ambiente.md の - banco: と BUILD_REPORT の ## Migrations aplicadas）の内容を記載します。これは確認事項であり、質問ではありません。この変更に .sql ファイルがない場合は「この変更にマイグレーションはありません」と記載します。
• **「デプロイはテストを待ちますか？」**は、.github/workflows/* を確認して判断します。テストが公開ステップより前に同じジョブ内で実行される場合、または公開するジョブの needs: がテストのジョブを指定している場合が該当します。continue-on-error: true、|| true、または常に exit 0 で終了するテストステップは何も阻止しないため、「いいえ」とします。これは確認事項であり、質問ではありません。記入するのはあなたで、ユーザーは回答しません。
• **ブロック内の唯一の質問は、最後の行の「公開してもよいですか？」**です（手順 1 で公開先が曖昧なままの場合は「<alvo> に公開してもよいですか？」とします）。それより前の行にある ? は、あなたが記入する項目名です。ここでいう「質問」は回答を求める内容を指し、疑問符の数を指すものではありません。レビューの提案は1文であり、質問ではありません。「公開前にレビューしましょうか？」と質問にすると、停止ポイントが2つになり、押印をもらうだけの作業になります。
• 対象ファイルがどの変更に属するのかなど、曖昧な点が残っている場合は、最後の行より前に、この同じブロック内で伝えてください。停止するのは1回だけです。
• OKがなければ、ここで終了してください。コミット、マージ、プッシュはしないでください。

フェーズ 3 — 公開（OKを得た後のみ）

1. フォルダーはまだ承認されたものですか？ フェーズ 1 のフィンガープリントを再計算します。一致しない場合は、承認後に何かが変わっています。停止して変更内容を示し、改めて承認を求めてください。確認されていないものをコミットしてはいけません。
2. ファイルを 1 つずつ指定してコミットします。フェーズ 1 の git status の一覧にあるファイルだけを対象とし、それ以外は含めません。インデックスをリセットしないでください（フォルダー内にないステージ済みバージョンが消えてしまいます）。git add の後、git diff --cached --name-only の結果がその一覧と完全に一致する必要があります。別のファイルがステージされていたら、コミットする前に停止してください。コミット後は、バージョン管理対象外のスキルフォルダー（意図的に対象外）を除き、git status --short が空である必要があります。 git add -A と git add -u は絶対に使わないでください。同じマシンで 2 つの作業を並行している場合、もう一方の作業まで取り込んでしまいます。
3. ベースを更新して、再度テストします。 ベースが進んでいたら、GIT_TERMINAL_PROMPT=0 git fetch origin <alvo>、git merge origin/<alvo> を作業ブランチで実行し、テストを再度実行します。競合またはテスト失敗があったら、push する前に停止して、何が壊れたかを伝えてください。何も公開されていません。
4. 統合は必ず作業ブランチから、シナリオに応じて行います。
   • A（Trunk-Based、<alvo> = メインブランチ）：GIT_TERMINAL_PROMPT=0 git push origin HEAD:<principal>。push は作業ブランチから行います。作業ブランチには承認された内容とリモートのベースだけが含まれます。承認されていないローカルコミットが一緒に送られてしまう可能性のあるメインブランチのチェックアウトからは行いません。ベースが進んだため拒否された場合（non-fast-forward／fetch first）は、手順 3 に戻ってください（強制 push は絶対に行わないでください）。権限（403、Permission denied、could not read Username）または保護ブランチ（protected branch、GH006）を理由に拒否された場合は停止し、次の順に確認するよう伝えてください。gh auth status（ログイン済みか、正しいアカウントか）、リポジトリでの役割（公開には書き込み権限が必要です）、メインブランチが保護されているかどうか。保護されている場合はシナリオ B（ブランチを push して PR を作成）が適切な方法です。直接 push を続けないでください。
   • B（GitHub Flow）：GIT_TERMINAL_PROMPT=0 git push -u origin <branch-da-frente> を実行し、メインブランチ宛てに PR を作成します（gh があれば gh pr create を実行し、なければ上記の push コマンドに表示されるリンクを使って、ブラウザーで PR を作成します）。その後はそこで停止してください。レビュー後の PR のマージが統合にあたります。
   • C（GitFlow）：GIT_TERMINAL_PROMPT=0 git push -u origin <branch-da-frente> を実行し、develop 宛てに PR を作成します（gh の有無にかかわらず、シナリオ B と同じ方法です）。その後はそこで停止してください。作業ブランチをメインブランチに直接統合してはいけません。
5. 手動デプロイがある場合は、統合と更新が済んだメインブランチからのみ行います。未公開の作業ブランチからデプロイしてはいけません。デプロイは公開された内容と完全に一致するツリーで実行します。シナリオ A では、push が受け付けられた直後の作業ブランチ自体が対象です。git status --porcelain が空であること、および git rev-parse HEAD が git rev-parse origin/<principal> と一致することを確認してください（GIT_TERMINAL_PROMPT=0 git fetch の後に確認します）。一致しなければ停止してください。ローカルの変更や未承認のコミットが含まれている可能性のあるメインブランチのチェックアウトからは、絶対にデプロイしないでください。シナリオ B と C では、PR の統合後に実行するデプロイコマンドを提示し、統合前には実行しないでください。（自動デプロイの場合は、メインブランチへの push によって公開されます。）
6. 最後の実行結果ではなく、公開したコミットを基準に成功を確認します。 コマンドでエラーが出なかっただけで「公開済み」と言ってはいけません。ワークフローによるデプロイで gh が使える場合：
   • gh run list --commit <SHA publicado> --branch <principal> --json databaseId,status,conclusion,workflowName,event（PowerShell でも同じです）を実行します。メインブランチで公開を行うワークフローの実行を確認してください（event は push、または下記の手動再実行時は workflow_dispatch）。一覧全体で最新の実行（push が連続している場合は別のコミットのものです）や、同じ SHA でも別ブランチまたは PR の実行（デプロイがスキップされている可能性があります）を確認してはいけません。
   • completed + success ⇒ 「公開されました。コミット <sha 短縮形> のデプロイが完了しました（実行 N）。」
   • queued または in_progress ⇒ 完了するまで待ってから再確認します。まだ公開されていません。
   • 一覧が空 ⇒ GitHub がまだ実行を記録していません。数秒待って再度確認してください。約 2 分経過しても空の場合は、コミットの実行が見つからなかったと伝えてください。「確認することはありません」と言ってはいけません。シナリオ B と C では、メインブランチに到達するのは PR のマージコミットです。その SHA で確認してください。
   • cancelled ⇒ キューがある場合、後からの push が置き換えた可能性があります。GIT_TERMINAL_PROMPT=0 git fetch origin <principal> を実行し、その後 gh run list --workflow <arquivo do workflow> --branch <principal> --limit 20 --json databaseId,headSha,status,conclusion,createdAt を実行します。自分のコミットより後に作成され、自分のコミットを含むコミットの実行のみが有効です（git merge-base --is-ancestor <seu SHA> <SHA dele> の終了コードが 0）。その場合は「コミット <sha> はコミット <sha dele> のデプロイに含まれました（実行 N）。」と伝えます。終了コードが 1 の場合、その実行には自分のコミットが含まれていません（別の実行を探すか、待ちます）。それ以外の終了コード（コミットが見つからない）の場合は「確認できませんでした」と伝えてください。「含まれていません」と言ってはいけません。
   • failure ⇒ 何が失敗したかを伝えます。デプロイを再実行する場合、古い実行に対して gh run rerun を絶対に使わないでください。キューがあると、後からの push より後に実行され、古いコードで上書きされる可能性があります。最新の状態で再実行します（ワークフローが手動実行に対応している場合は gh workflow run <arquivo do workflow> --ref <principal> を実行するか、新しい push を行います）。
   • 成功してもテストの実行を証明するものではありません。テストのステップに continue-on-error、|| true がある場合、または必ず exit 0 で終了する場合は、「デプロイは完了しましたが、公開前にテストを実行しないワークフローです」と伝えてください。✅ は付けないでください。 URL があれば、応答を確認してください。gh が使えない、または確認手段がない場合は、その旨を伝えてください。「自動確認はできませんが、公開されました」は正直な表現です。確認せずに「✅ すべて成功しました」と言ってはいけません。
7. メインブランチへのチェックアウトとクリーンアップは、コマンドとして提示します（作業ツリー内からは自分自身を削除できません）。メインブランチのチェックアウトで GIT_TERMINAL_PROMPT=0 git pull --ff-only を実行します。拒否された場合、ローカルのメインブランチに未公開のコミットがあることを伝えてください。代わりに解決してはいけません。その後、git worktree remove "<pasta>"（パスにスペースが含まれる可能性があるため、引用符を付けます）と git branch -d <branch> を実行します（小文字の -d は、すでに統合されたブランチだけを削除します）。シナリオ B と C では、PR のマージ後にクリーンアップします。 最終回答：Status は todo ✅、そして3行 — 何が公開されたか、どこにあるか、何が残っているか。

このスキルに含めないこと（その理由）

• 詳細な変更履歴 — プロジェクトにすでに CHANGELOG.md があれば、1行にします。なければ、作成しません。
• 新たなバージョン管理 — 現在バージョン管理をしていないプロジェクトで、ここから始めることはありません。
• 長い最終レポート — 3行にします。
• いかなる場合も --force は使いません。 プッシュが拒否された場合、ベースが進んでいます。取得して統合してください。 他の人（または昨日の自分）の作業を決して上書きしないでください。
• 2つ目の停止ポイントは設けません。 停止ポイントが2つあると形式的なものになり、読まれなくなります。

各ルールがある理由

• プッシュ前に承認を得ます：自動デプロイでは、プッシュ後に戻れる「前」はありません。
• git add ではファイル名を指定します：2つの作業が並行していると、-A はまだ終わっていない作業まで公開してしまいます。
• ベースは事前に確認し、承認後に統合します：別の作業が先に入っていた場合、テストはすでに存在しない状態に対して通っています。しかし、承認前に統合すると、誰も承認していないコミットが作成されます。そのため、フェーズ1で確認し、フェーズ3でプッシュ前に統合して再テストします。
• プッシュはメインのチェックアウトではなく、作業用ブランチから行います：メインのチェックアウトには、承認を受けていないローカルコミットが存在する場合があります。
• 要約ではコミットされていない内容も扱います：コミットは承認後に行うため、承認対象には、まだフォルダー内にしかない内容も含める必要があります。
• 承認前にユーザー情報を確認します：コミットはフェーズ3でのみ行います。名前とメールアドレスが設定されていないと、ユーザーの承認後に失敗します。
• マイグレーションは、コミットと適用をセットで行います：プッシュで公開されるのはコードであり、データベースではありません。確認しないと、自動デプロイによって、存在しないカラムを呼び出すコードが公開されます。そのうえ、承認のブロックには「プッシュだけで公開されますか？ はい」と書かれ、それで十分であるかのように見えてしまいます。
• デプロイは SHA で確認します：プッシュが連続して2回行われると、「最新の run」は別のコミットのものになります。別のコミットの run が成功しても、あなたのコミットについては何も分かりません。
• 古いデプロイに対して gh run rerun を実行しないでください：再実行では、その run のコミットが使われます。キューに入ると、より新しいプッシュの後に実行され、古いコードを上書きして公開することになります。
• このスキルは作業用ブランチ内から実行されるため、最後に自分自身の worktree を削除できません。 クリーンアップはメインのチェックアウトで行います。

---

Parte do SDD Starter by RDD — https://github.com/robertodiasduarte/sdd-starter