codely-plan-phase-implement-github

🫡 計画のフェーズを実装する

[!CRITICAL] 1回の実行につき、実装するフェーズは1つだけです。現在のフェーズを完了したら、停止して、ユーザーによる変更の確認を待ってください。ユーザーの明示的な承認なしに、次のフェーズへ進んではいけません。

[!CRITICAL] プルリクエストをマージしてはいけません。 このスキルでは、フィーチャーブランチの作成、コミット、プッシュ、プルリクエストの作成ができますが、マージするタイミングはユーザーが決定します。マージすると、フェーズの issue がクローズされます。

🎯 入力

このスキルは /codely-plan-phase-implement-github <github-issue-url> として実行します。URL は次のいずれかを指定できます。

• フェーズ（子）issue：そのフェーズを実装します。
• 親の計画 issue：現在のフェーズを特定して実装します（下記を参照）。

URL が指定されていない場合は、ほかのことをする前にユーザーに URL を尋ねてください。

🗂️ リポジトリ

計画とそのフェーズは、現在の作業ディレクトリにあるリポジトリの GitHub issue として管理され、プルリクエストも同じリポジトリで作成します。リポジトリをハードコードしてはいけません。gh にローカルの Git リモートから解決させてください。

gh issue view <number>
gh issue develop <number> --checkout
gh pr create --title "..." --body "..."

gh repo view --json nameWithOwner --jq .nameWithOwner で gh が解決するリポジトリを確認し、指定された URL がそのリポジトリに属していることを確認してください。異なる場合は停止し、タスクを実装するリポジトリのクローンからスキルを実行するようユーザーに伝えてください。フェーズのブランチは、タスクを実装するのと同じリポジトリに作成する必要があります。

🔍 現在のフェーズを特定する

1. gh issue view <url> で指定された issue を読みます。
2. issue がフェーズ（子）issueの場合（Part of #<parent> という参照と、ToDo チェックリストがある場合）は、そのフェーズを実装します。
3. issue が親の計画 issueの場合（子 issue にリンクした Phases チェックリストがある場合）、現在のフェーズは、チェックリスト内で最初に見つかる、まだオープンの子 issue です。その子 issue を読み、実装します。
4. すべての子 issue がすでにクローズされている場合は、すべてのフェーズが完了していることをユーザーに伝え、何も実装しないでください。

🪜 計画のフェーズを実装する手順

1. 上記のルールに従って、実装するフェーズの issue を特定します。

2. そのフェーズ issue にリンクされたブランチを作成し、チェックアウトして、ブランチが issue にリンクされるようにします。

   gh issue develop <phase-issue-number> --checkout
   

3. そのフェーズの ToDo 項目だけを実装します。他のフェーズは実装しないでください。

4. gh issue edit <phase-issue-number> --body ... を使用してフェーズ issue の本文を更新し、完了した ToDo 項目にチェックを付けます（- [x] ...）。

5. 変更を検証し（型チェック、リンティング、テスト）、問題があれば先に進む前に修正します。

6. 停止します。 変更内容をユーザーに提示し、Conventional Commits に沿ったコミット／プルリクエストのタイトル案を3つ提案します（例：feat:、fix:、refactor:、test:、docs:）。3つの案では、それぞれ実現可能な異なるタイプを使ってください。「タイトル1でPRを作成して」のように簡単に返信できる形にします。

7. ユーザーがタイトルを選んだら、コミットしてブランチをプッシュし、フェーズ issue を参照するプルリクエストを作成します。これにより、マージ時に issue が自動的にクローズされます。

   gh pr create \
     --title "<chosen title>" \
     --body "Closes #<phase-issue-number>"
   

   • これが計画の最後のフェーズの場合（このフェーズの後にオープンの子 issue が残っていない場合）は、同じプルリクエストの本文で親 issue もクローズします。

     Closes #<phase-issue-number>
     Closes #<parent-issue-number>
     

   • プルリクエストをマージしてはいけません。マージするとフェーズ issue がクローズされること（最後のフェーズの場合は、親の計画 issue もクローズされること）をユーザーに伝えてください。

8. これが計画の最後のフェーズの実装である場合は、会話をエクスポートして（IDE を使用）、親の計画 issue にコメントとして添付するようユーザーに提案してください。

🔄 イシューの更新方法

• 子イシューで、現在のフェーズの ToDo リストのうち完了した項目にチェックを入れます。
• 親イシューの Next step セクションを、次に完了するフェーズに更新します。
• 親イシューの、Codely に関する最後の文を、前の絵文字と合わせてストーリーを表すランダムな絵文字を新たに追加した文に置き換えます。たとえば、前の最後の文が「Codely によるプラン 🐢 💨」だった場合、新しい最後の文は「Codely の AI ツールのおかげでバグを退治しました。 🐛 < 🐢 💨」のようにできます。

🔗 親子関係

• 各フェーズのプルリクエストは、マージ時に対応する子イシューをクローズします。
• 親の計画イシューでは、Phases チェックリストを通じて子イシューを追跡します。対応する子イシューがクローズされると、GitHub が各項目にチェックを入れます。
• 最後のフェーズのプルリクエストは親イシューもクローズするため、最終フェーズを完了すると計画全体がクローズされます。

☝️ 全般的な考慮事項

🧠 論理的な推論

• 次の作業を行う際は、AGENTS.md ファイルを参考にしてください。
  • アプリケーションサービス、ドメインイベント、テストなどを提案する
  • コード規約とアーキテクチャ上の決定（すべて docs/ ディレクトリ内）に従う
  • 作成、変更、削除するテストスイートとテストケースを決定する
• ユーザーが異なる選択肢から選べるようにしながら、利用可能なエージェントツールを使用してください。
  • Cursor を使用していてこのツールが利用可能な場合は、AskQuestion ツールを使用します（Opus 4.5 など一部のモデルでのみ利用でき、Composer 1 などでは利用できません）。
  • Claude Code を使用している場合は、AskUserQuestion ツールを使用します。