バッチフィーチャーは何をしますか？

ワークフローの前半です。後半は work-issue です。

あなたはバックログのダンプを登録しているのではありません。大まかなアイデアを、エージェントが発見作業をやり直さずに計画を立てられるような課題に変換しているのです。そのためには、アイテムごとの議論、1回の承認、そして登録、という手順を踏みます。

開始時に宣言: 「このリストを課題に変換するため、batch-features スキルを使用しています。」

セットアップ

shared/ はこのスキルの隣のディレクトリです。インストール時は ~/.agents/skills/shared/、チェックアウト時は ../shared/ となります。shared/... パスが解決できない場合は、もう一方のパスを使用してください。

リポジトリを読み込む: ルートの AGENTS.md（または CLAUDE.md）。これが規約の基準となります。
.agent-skills/config.json が存在すればそれを読み込み、存在しなければ shared/config.md を読み込み、初回実行時の質問に答えてファイルを作成します。
shared/tracker-adapter.md、shared/labels.md、shared/issue-template.md を読み込みます。
トラッカーを検出します。既存のラベルや課題を確認し、新しいものが適合するようにします。
テンプレート。 プロジェクトにすでに課題テンプレート（.gitlab/issue_templates/*.md、.github/ISSUE_TEMPLATE/*.md）があるか確認します。ある場合はそれを使用し、そのパスを設定の issueTemplate に記録します。ない場合は、最後に一度だけ shared/issue-template.md をプロジェクトにコミットすることを提案することをメモしておきます。

議論

リストを1アイテムずつ処理します。各アイテムについて:

自分の言葉で言い換える: それが何か、誰に役立つか、なぜ今なのか。元の文言は、課題本文の Intent の下に原文のまま引用として残します（残りの部分が英語の場合でも）。
具体的な解釈を提案する: 「ここで何をしたいのですか？」ではなく、「私はこれをXと解釈しました。なぜならYだからです。もしZを意図していたなら言ってください。」
最大2つの質問をする: それぞれ具体的で、ユーザーが一言で受け入れられるデフォルト値を含める必要があります。回答によって最も構築内容が変わる質問を選びます。ユーザーが詳細な確認を求めた場合はより多く質問しても構いませんが、通常は2つです。
2つを確定する: 受け入れ基準（それぞれ観察可能で確認可能なもの）と種別（feature / fix / refactor / chore）。これ以外は確定しません（サイズ、エリア、依存関係は不要）。

議論後もアイテムが確定できない場合は、推測するのではなく、needs spec の注釈を付けて status::blocked とマークします。曖昧な課題を登録することは、登録しないことより悪いです。

すべてのアイテムが議論されるまで、登録に進んではいけません。

レビュー表

最後のアイテムの後、バッチ全体の表を1つ提示します:

| # | タイトル | 種別 |
|---|----------|------|
| 1 | ...      | feature |

その後、承認を求めます。ユーザーはタイトルの編集、アイテムの削除、種別の変更ができます。この承認前に何も登録されません。

課題を登録する

承認された各アイテムについて、ユーザーが希望する順序で（デフォルトは作成順）:

トラッカーのCLIを使用して課題を作成します。本文はプロジェクトのテンプレートがあればそれを使用し、なければ shared/issue-template.md を使用します。タイトルと本文は設定の language（デフォルトは en）に従います。
ラベルを適用します: status::ready と kind::<kind>。課題番号を記録します。
課題のURLを報告します。

ユーザーのリストに順序の示唆（「X puis Y」など）がある場合は、課題本文の Notes にその旨を記載します。依存関係やラベルは作成しません。

プロジェクトに課題テンプレートがなく、ユーザーが提案を受け入れた場合は、shared/issue-template.md をトラッカーの期待されるパスに一度だけコミットし、その後で登録します。黙って作成してはいけません。

報告

最後に、以下を出力します:

課題のURL（1行に1つ）
バッチサマリー: N件登録、M件ブロック。
1行: 「作業を開始するには、work-issue <n> と入力してください。」

厳格なゲート

レビュー表の承認なしに課題は作成されません。
受け入れ基準または検証セクションが空の課題は作成されません。
推測で範囲を決定した課題は作成されません（議論後に曖昧な場合は status::blocked になります）。
このスキルから課題を主張したり実装を開始したりしてはいけません。それは work-issue の役割です。

バッチフィーチャー