codely-plan-create-github

🧠 計画の作成方法

[!CRITICAL] ユーザーが検討対象となる具体的な公開コントラクトと実装フェーズに同意するまで、GitHub の issue を作成または編集しないでください。まず提案し、承認を得てから issue を作成してください。

計画の構成、そのセクション、作成時のルールは resources/plan-guidelines.md で定義されています。何かを提案する前に読んでください。

🎯 入力

このスキルは /codely-plan-create-github <github-issue-url> として呼び出されます。

• <github-issue-url> は、計画対象のタスクを説明する GitHub issue の URL です。この issue が親の「計画」issue になります。
• URL が指定されていない場合は、ほかの作業を始める前にユーザーに URL を尋ねてください。

🗂️ リポジトリ

計画はすべて、現在の作業ディレクトリのリポジトリにある GitHub issue として管理します。リポジトリをハードコードせず、ローカルの Git リモートから gh に解決させてください。

gh issue view <number>
gh issue create --title "..." --body "..."
gh issue edit <number> --body "..."

指定された URL から <number> を取得します。gh repo view --json nameWithOwner --jq .nameWithOwner で gh が解決するリポジトリを確認し、指定された URL がそのリポジトリに属していることを確認してください。属していない場合は処理を中止し、そのリポジトリのクローンからスキルを実行するようユーザーに依頼してください。

フェーズを親 issue のネイティブ GitHub サブ issueとして紐付けるには、サブ issue REST API を使用します。この API では、issue 番号ではなく子 issue の数値データベース id が必要なので、まずそれを取得してください。{owner} と {repo} のプレースホルダーは、現在のリポジトリを使って gh が置き換えます。

# Resolve the child issue database id from its number
child_id=$(gh api repos/{owner}/{repo}/issues/<child> --jq .id)

# Attach the child as a native sub-issue of the parent
gh api --method POST repos/{owner}/{repo}/issues/<parent>/sub_issues -F sub_issue_id="$child_id"

🧱 Issue の構成

計画は、GitHub のネイティブサブ issue機能を使ったissue のツリーとして保存されます。

• 親の「計画」issue：URL で指定された issue です。Goal、Context、合意済みの設計上の決定事項、および各子 issue にリンクされたフェーズのチェックリストを記載します。親 issue は子 issue に依存します。すべての子 issue がクローズされると、親 issue もクローズされます。
• フェーズごとに 1 つの子 issue：フェーズの説明と、チェックボックス形式の ToDo アクションを記載し、親 issue への参照（Part of #<parent>）を含めます。各子 issue はチェックリストのリンクだけでなく、サブ issue API を使って、親 issue のネイティブ GitHub サブ issueとして紐付けます。

#12 Product Bundles (parent plan)
     Goal / Context / design decisions
     - [ ] #13 Phase 1: ...
     - [ ] #14 Phase 2: ...
#13 Phase 1: ...   (child, to-do checkboxes)
#14 Phase 2: ...   (child, to-do checkboxes)

🪜 計画を作成する手順

1. gh issue view <parent> で親イシューからタスクを確認します。

2. ガイドラインに記載されているとおり、ユーザーがフェーズ数を選べるようにして、タスクのフェーズを定義します。

3. ガイドラインに記載されているとおり、各フェーズのタスクで作成・変更・削除する公開コントラクトを明記します。

4. 承認を得るために、計画をユーザーに提案します。重要：ユーザーが対象とする具体的なコントラクトと実装フェーズに同意するまで、イシューを作成してはいけません。

5. gh issue create でフェーズごとに子イシューを1つ作成します。各子イシューの本文には、次の内容を含める必要があります。

   • フェーズの説明。
   • フェーズの実施項目をチェックボックス形式のリストで記載（- [ ] ...）。
   • そのフェーズの公開コントラクト。
   • Part of #<parent> という参照行。

   gh から返されたすべての子イシュー番号を記録します。

6. 各子イシューを親イシューのネイティブなサブイシューとして紐付けます。各子イシューのデータベース ID を取得し、上記の Repository セクションにあるスニペットに従って、サブイシュー API で親イシューに紐付けます。

   child_id=$(gh api repos/{owner}/{repo}/issues/<child> --jq .id)
   gh api --method POST repos/{owner}/{repo}/issues/<parent>/sub_issues -F sub_issue_id="$child_id"
   

   すべてのフェーズについて順番に実行し、親イシューにすべてのフェーズがネイティブなサブイシューとして表示されるようにします。

7. gh issue edit <parent> --body ... で親イシューを更新し、Goal、Context、合意済みの設計判断、およびすべての子イシューへのリンクを含む Phases チェックリスト（- [ ] #<child> Phase N: <title>）を本文に追加します。親イシューの元のタスク説明はそのまま保持し、その下に --- の行で区切って新しい計画内容を追記します（元の文章を失ったり書き換えたりしてはいけません）。

8. 次のステップを提案し、ユーザーに希望する対応を尋ねます。

   • 何も実行しない。
   • /codely-plan-phase-implement-github <parent-issue-url> スキルを実行して計画を実装する（Phase 1 のみ実装）。
   • /codely-plan-phase-implement-github <child-issue-url> スキルを実行して特定のフェーズを実装する。

   重要

   /codely-plan-phase-implement-github は1回の実行につき1つのフェーズを処理します。すべてのフェーズを一度に実装してはいけません。

🗃️ 計画メタデータ

GitHub イシューには YAML フロントマターがないため、計画メタデータを親イシュー本文の末尾にフッターとして追加します。

---

<sub>Created by { tool } · { model.name } { model.version } (reasoning effort: { model.reasoning_effort }) · { current_date }</sub>

• current_date：現在の日付を ISO 8601 RFC 3339 形式（YYYY-MM-DDTHH:MM:SSZ）で記載します。
• tool：使用した AI コーディングツール（例：Claude Code、Cursor、Copilot、Codex）。
• model.name：変更に使用したモデルの名前（例：Claude Opus、Cursor Composer、OpenAI GPT）。
• model.version：変更に使用したモデルのバージョン（例：4.6、1.5、5.4）。
• model.reasoning_effort：変更に使用したモデルの推論レベル（例：low、medium、high）。

🗂️ 各計画セクションの配置先

親イシューには、resources/plan-guidelines.md に記載された Goal、Context、Phases チェックリスト、および Next step セクションを記載します。各子イシューには、そのフェーズの説明と実施項目リストを記載します。

フェーズはプルリクエストを通じて実装されるため、各フェーズの最後の実施項目では、コミットメッセージではなくプルリクエストのタイトルを求めます。