speckit-taskstoissues

非推奨のお知らせ

このコマンドの最初の手順として、また、以下の「ユーザー入力」および「実行前チェック」セクションより前に、次の簡潔な警告を必ず最初に表示してください。

⚠️ /speckit-taskstoissues は非推奨となり、今後のマイナーリリースで削除される予定です。代わりに同梱の github 拡張機能を使用してください。specify extension add github を実行してから、/speckit-github-taskstoissues を呼び出してください。

既存のワークフローは変更せずに続行してください。拡張機能を自動的にインストールまたは有効化したり、処理を停止したり、置き換えコマンドを実行したりしないでください。

ユーザー入力

$ARGUMENTS

（空でない場合）先に進む前に、ユーザー入力を必ず考慮してください。

実行前チェック

拡張機能のフックを確認します（タスクから Issue への変換前）。

• プロジェクトのルートに .specify/extensions.yml があるか確認します。
• ファイルがある場合は読み込み、hooks.before_taskstoissues キーの下にあるエントリーを探します。
• YAML を解析できない、または無効な場合は、黙ってスキップせず、.specify/extensions.yml を読み込めなかったこと（パーサーのエラーを含む）と、そこに登録されている必須（optional: false）フックも含め、フックを一切確認していないことをユーザーに伝えてから、通常どおり続行します。
• enabled が明示的に false のフックは除外します。enabled フィールドがないフックは、デフォルトで有効として扱います。
• 残った各フックについて、condition の式を解釈または評価しようとしないでください。
  • フックに condition フィールドがない場合、または値が null／空の場合は、実行可能なフックとして扱います。
  • フックに空でない condition が定義されている場合は、そのフックをスキップし、条件の評価は HookExecutor の実装に任せます。
• フックのコマンド名からコマンド呼び出しを構成する際は、ドット（.）をハイフン（-）に置き換えます。たとえば、speckit.git.commit → /speckit-git-commit です。
• 実行可能なフックごとに、optional の値に応じて次の内容を出力します。

  • 任意のフック（optional: true）：

    ## 拡張機能のフック
    
    **任意の Pre-Hook**：{extension}
    コマンド：`/{command}`
    説明：{description}
    
    プロンプト：{prompt}
    実行するには：`/{command}`
    

  • 必須のフック（optional: false）：

    ## 拡張機能のフック
    
    **自動 Pre-Hook**：{extension}
    実行中：`/{command}`
    EXECUTE_COMMAND: {command}
    
    アウトラインに進む前に、フックコマンドの結果を待ってください。
    

    上記のブロックを出力した後、フックを実際に呼び出し、完了するまで待ってから続行する必要があります。エージェント／セッション内で自分がコマンドを実行する場合と同じ方法で実行してください（呼び出し方法は、上記に表示されるリテラルな {command} の ID と異なる場合があります。たとえば、skills モードのエージェントでは /skill:speckit-... または $speckit-... のように実行します）。ブロックを出力するだけでは、フックを実行したことにはなりません。

• フックが登録されていない場合、または .specify/extensions.yml が存在しない場合は、何も出力せずにスキップします。

概要

1. リポジトリのルートから .specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks を実行し、FEATURE_DIR と AVAILABLE_DOCS のリストを解析します。すべてのパスは絶対パスでなければなりません。"I'm Groot" のように引数にシングルクォートが含まれる場合は、エスケープ構文を使用します。例：'I'\''m Groot'（または可能であれば "I'm Groot" のようにダブルクォートで囲みます）。
2. 存在する場合：プロジェクトの原則とガバナンス上の制約を確認するため、.specify/memory/constitution.md を読み込みます。
3. 実行したスクリプトから tasks へのパスを抽出します。
4. 次を実行して Git のリモートを取得します。

git config --get remote.origin.url

注意

リモートが GitHub URL の場合にのみ、次の手順に進んでください。

1. 重複を確認するため、既存の issue を取得します：何かを作成する前に、tasks.md から処理対象のタスク ID のセットを作成します（各 ID は T の後に少なくとも3桁の数字が続く形式です。例：T001。/speckit-converge は T{M+1:03d} の形式で新しい ID を割り当てますが、これは上限ではなく最小桁数です。そのため、ファイル内のタスクが999件を超えると、IDは4桁以上になります）。次に、GitHub MCP サーバーの list_issues ツールを使用して、それらの ID をすでに扱っている issue を探します。state の値は指定しないでください。省略すると、ツールはオープンとクローズ済みの両方の issue を返します。呼び出し回数を減らすため perPage: 100 を指定します。また、このツールはカーソルベースのページネーションを使用するため、after パラメーターを指定してページを要求します（前の応答の endCursor を使用します）。各 issue のタイトルをタスク ID のパターン \bT\d{3,}\b と照合し（{3,} は4桁以上の ID にも対応します。\d{3} では、タイトルに T1000 が含まれていても末尾の \b が2つの数字の間に入らないため、一致しません。その結果、そのタスクは重複として処理されることも作成されることもありません。単語境界により ST001 のようなトークンは一致せず、数字列全体が対象になるため、T1000 の一部として T100 が一致することもありません。また、T001 ...、T001: ...、[T001] ... のようなタイトルも認識されます）、自分のタスク ID のいずれかと一致した場合は、その ID に対応する issue がすでに存在するとマークします。すべてのタスク ID が一致した時点、またはこれ以上ページがない時点でページネーションを停止します。すべてのタスク ID が確認された後もリポジトリ全体の issue 履歴を取得し続けることはありません。これにより、issue 履歴が大量にあるリポジトリでの呼び出し回数を抑えつつ、tasks.md の再生成後やスキルの再実行時に重複を防止できます。
2. リスト内の各タスクについて、GitHub MCP サーバーを使用し、Git リモートに該当するリポジトリに新しい issue を作成します。tasks.md のタスク行は Markdown のチェックボックスで始まるため、まず先頭の - [ ]（および [P] / [US#] マーカー）を取り除き、タスク ID と説明を取り出します。T001: <description> の形式で、ID を1回だけ記載し、その後にタスクの説明を続ける標準タイトルを作成します（たとえば、- [ ] T001 Create project structure という行は T001: Create project structure というタイトルになります）。
   • 前の手順で作成した既存 issue のセットにすでに ID が含まれているタスクはスキップし、その旨を報告します（例：T001 already has an issue, skipping）。
   • 一致する issue がまだないタスクのみ、issue を作成します。

注意

リモート URL と一致しないリポジトリには、いかなる場合も絶対に issue を作成しないでください。

実行後のチェック

拡張フックをチェックする（タスクから issue への変換後）： プロジェクトのルートに .specify/extensions.yml が存在するか確認します。

• 存在する場合は読み込み、hooks.after_taskstoissues キーの下にエントリーがあるか確認します
• YAML を解析できない、または無効な場合は、黙ってスキップしないでください。.specify/extensions.yml を読み込めなかったこと（パーサーエラーを含む）と、そこに登録された必須（optional: false）フックも含め、フックをチェックしていないことをユーザーに伝えてから、通常どおり続行します
• enabled が明示的に false のフックは除外します。enabled フィールドのないフックは、デフォルトで有効として扱います。
• 残りの各フックについて、フックの condition 式を解釈または評価しようとしてはいけません。
  • フックに condition フィールドがない場合、または値が null／空の場合は、フックを実行可能として扱います
  • フックに空でない condition が定義されている場合は、フックをスキップし、条件の評価は HookExecutor の実装に任せます
• フックのコマンド名からコマンド呼び出しを構築する際は、ドット（.）をハイフン（-）に置き換えます。たとえば、speckit.git.commit → /speckit-git-commit です。
• 実行可能な各フックについて、optional フラグに基づいて以下を出力します。

  • 任意のフック（optional: true）：

    ## 拡張フック
    
    **任意のフック**：{extension}
    コマンド：`/{command}`
    説明：{description}
    
    プロンプト：{prompt}
    実行するには：`/{command}`
    

  • 必須のフック（optional: false）：

    ## 拡張フック
    
    **自動フック**：{extension}
    実行中：`/{command}`
    EXECUTE_COMMAND: {command}
    

    上記のブロックを出力した後、続行する前にフックを実際に呼び出し、完了するまで待つ必要があります。自分自身がこのエージェント／セッションでコマンドを実行するのと同じ方法で実行してください（呼び出し方法は、上記に表示された {command} の文字列と異なる場合があります。たとえば、skills モードのエージェントでは /skill:speckit-... または $speckit-... として実行します）。ブロックを出力するだけでは、フックは実行されません。

• フックが登録されていない場合、または .specify/extensions.yml が存在しない場合は、黙ってスキップします