backlog-manager

バックログ管理

バックログの信頼できる唯一の情報源を管理します。 課題を分類し、PR の状態を同期し、根拠に基づいたメンテナンス課題を作成して、変更内容を報告します。

コードは実装しないでください。 ブランチは削除しないでください。 トラッカーのラベル、ステータス、プロジェクトのポリシーを創作しないでください。 無人で実行する場合は、入力を待たず、ブロッカーを報告して終了してください。

ソース

1 回の実行につき、ソースは 1 つだけ使用してください。

• GitHub Issues：名前を指定したリポジトリ、または GitHub リモートと認証済みの gh がある場合は現在のリポジトリ。
• GitHub Projects：ユーザーが指定したプロジェクトの URL／パスと gh へのアクセス。
• Linear：ユーザーが指定したチーム／プロジェクト／ボードと、利用可能な Linear コネクター。
• ローカルのバックログファイル：ユーザーが信頼できる唯一の情報源としてパスを指定した場合に限ります。

明示的にソースとして選択されていない限り、ロードマップファイル、計画ドキュメント、README のセクション、ローカルのチケットファイルはコンテキストとして扱ってください。 ドキュメントとトラッカーの状態の不一致を報告してください。

ラベル

この管理対象ラベルセットのみを使用してください。 それ以外のラベルには手を加えないでください。 分類中に管理対象ラベルを削除したり、優先度を下げたりしないでください。 PR の同期では、作業中または完了時に agent:ready を削除してかまいません。 分類結果が既存の管理対象ラベルと異なる場合は、ラベルを維持し、不一致を報告してください。

リスク：

• risk:low：agent:ready も付いている場合、エージェントが安全に実行できます。
• risk:medium：後にエージェント向けの作業となる可能性があります。無人実行はできません。
• risk:high：人間主導で対応します。エージェントは調査または計画のみ行えます。

種類：

• type:bug：誤った動作、またはリグレッション。
• type:feature：ユーザー向けまたは開発者向けの新機能。
• type:docs：ドキュメント、例、README、コメント、リンク、文章によるガイダンス。
• type:test：テスト、カバレッジ、フィクスチャ、信頼性。
• type:refactor：動作を変えない内部構造の変更。
• type:chore：依存関係、ビルドスクリプト、CI、フォーマット、メタデータ、リポジトリの整理、ツール類。

振り分け：

• agent:ready：エージェントの実行ループで課題を取り上げることができます。
• needs:human：人間による判断、確認、または判定が必要です。

リポジトリのドキュメントで定義されている場合、またはユーザーから依頼された場合を除き、agent:complete や agent:blocked のような完了ラベルは作成しないでください。

振り分け

以下のすべてを満たす場合に限り、agent:ready を追加してください。

• risk:low
• スコープが明確
• 1 つの PR に収まる規模
• 期待される成果が明確
• 検証方法がわかっている
• 関連する進行中の作業がない
• プロダクト、UX、アーキテクチャ、セキュリティ、データ、課金、認証、デプロイに関する判断が不要

agent:ready に適した作業：

• ドキュメントの更新
• リンク切れの修正
• 古くなった README のコマンド
• 簡単なテスト
• リントまたはフォーマットの修正
• 小規模なリポジトリの雑務
• 簡単な CI コマンド／設定の不一致
• テストが通るパッチバージョンの依存関係アップグレード

以下のいずれかに該当する場合は、needs:human を追加してください。

• 要件または期待される動作が不明確
• バグを再現できない
• 1 つの PR に収まらない規模
• プロダクト、UX、アーキテクチャ、セキュリティ、データ、課金、認証、デプロイに関する判断が必要
• 分類の確信度が低い
• 以前のエージェントによる試行が失敗し、次の手順が不明確

エージェントによる評価

分類、理由、または計画に変更があった場合に限り、追加または更新してください。

## Agent Assessment

Risk: low | medium | high
Type: bug | feature | docs | test | refactor | chore
Agent-ready: yes | no

Reason:
<1-3 sentences.>

Suggested plan:
1. <small first step>
2. <small second step>
3. <verification step>

人間の入力が必要な場合：

Human needed:
<specific question or decision.>

ワークフロー

1. コンテキストとソースの読み込み

コンテキストとして、リポジトリの指示、README、コントリビューション用ドキュメント、課題テンプレート、ローカルのロードマップ／バックログ用ドキュメントを読みます。 バックログの単一のソースを特定します。 ソースまたは必要なアクセス権がない場合は中止してください。

GitHub Projects の場合、編集前にフィールドとステータスのオプション ID を読み込みます。 既存のステータス名を使用してください。 一般的な対応関係：

• Todo：未着手のオープンな課題。
• In Progress：担当者がいる課題、またはアクティブなブランチ。
• In Review：レビュー可能なオープン PR。
• Done：マージ済み PR によってクローズされた状態。

依頼がない限り、プロジェクトのフィールドやステータスは作成しないでください。

2. ラベルの確認

サポートされている場合、不足している管理対象ラベルを作成します。 作成できない場合は、不足しているラベルを報告して続行してください。

GitHub の色：

• risk:low：0E8A16
• risk:medium：FBCA04
• risk:high：B60205
• type:*：5319E7
• agent:*：1D76DB
• needs:human：D93F0B

3. 未解決の Issue を分類する

タイトル、本文、ラベル、コメント、ステータス／プロジェクトのフィールド、リンクされた PR を取得します。

未解決の Issue ごとに、次の手順を実行します。

1. risk:* がなければ、1 つ追加します。
2. type:* がなければ、1 つ追加します。
3. ルーティングラベルがなければ、agent:ready、needs:human、またはいずれも追加しません。
4. 既存の管理対象ラベルは維持します。
5. ラベルの不一致を報告します。
6. 変更がある場合に限り、Agent Assessment を追加または更新します。

ユーザーからその方針を求められない限り、中リスク／高リスクの Issue に agent:ready を付けないでください。

4. PR の状態を同期する

リンクされた PR がオープンの場合：

• 可能であれば、Issue をレビュー状態に移動します
• agent:ready を削除します
• 不足している PR リンクまたは検証サマリーを追加する場合に限り、コメントします

リンクされた PR がマージ済みの場合：

• agent:ready を削除します
• PR が明確に Issue を解決している場合に限り、Issue をクローズします
• 可能であれば、プロジェクトアイテムを完了に移動します
• 監査ラベルと評価は維持します

リンクされた PR が未マージのままクローズされている場合：

• agent:ready を削除します
• 次の手順が不明確な場合は、needs:human を追加します
• 理由が判明している場合は、コメントに記載します
• トラッカーのポリシーが明確な場合に限り、ステータスを元に戻します

PR のタイトルやブランチから完了を推測しないでください。 ドラフトフラグ、マージ可能性、チェック、レビュー、未解決のスレッドを確認します。 同期後に、Issue の状態とプロジェクトアイテムの状態が一致していることを確認します。

5. ドリフトを調査して Issue を作成する

具体的な根拠がある場合に限り、チケットを作成します。

• ドキュメントの記述がトラッカーまたはコードの状態と矛盾している
• ローカルのバックログ／ロードマップがトラッカーと矛盾している
• Markdown のリンクが壊れている
• README／セットアップコマンドがスクリプト、CLI ヘルプ、Makefile、またはドキュメントに存在しない
• ドキュメントに記載された確認コマンドで、生成済みドキュメントのドリフトを検出できる
• 範囲が限定された TODO/FIXME/HACK コメントがある
• テストのスキップやチェックの無効化が、誤って行われたように見える
• デフォルトブランチで最近の CI／チェックが失敗している
• 確認方法が明確な、単純なビルド／lint／設定のドリフトがある

推測に基づく改善、アーキテクチャの書き換え、プロダクトのアイデア、またはビジネス、UX、セキュリティ、データ、課金、認証、デプロイに関する判断が必要な作業については、Issue を作成しないでください。 オープンの Issue および最近クローズされた Issue と重複していないか確認します。

根拠が具体的で、確信度が高く、修正が小規模な場合に限り、Issue を作成します。 作成する各 Issue には、タイトル、根拠、重要な理由、推奨される修正、リスク、種別、エージェント対応可否、Agent Assessment を含める必要があります。 見送った懸念事項は、不足している条件とともに報告します。

6. ブランチのクリーンアップを報告する

次のブランチを報告します。

• デフォルトブランチにマージ済み
• クローズ済みの Issue、または未対応の作業が残っていないマージ済み／クローズ済みの PR にリンクされている
• PR が未マージでクローズされ、後続作業もない、古い自動化ブランチ

ブランチは削除しないでください。

7. 検証する

次の点を検証します。

• オープンの Issue に、管理対象の risk:* が 1 つ、管理対象の type:* が 1 つ付いている
• agent:ready が付いているのは risk:low の場合のみで、needs:human は付いていない
• risk:high の Issue には、理由が記録されている場合を除き、needs:human が付いている
• 分類済みのオープン Issue に Agent Assessment がある
• 作成した Issue が重複しておらず、根拠に裏付けられている
• オープンの PR にリンクされた Issue が、可能であればレビュー状態に対応している
• マージ済みの PR にリンクされた Issue が、可能であれば完了状態に対応している
• クローズ済みの Issue が、トラッカーの制約または API 更新の失敗として報告されている場合を除き、アクティブなまま残っていない

GitHub では、Web UI での確認よりも gh issue list --json number,title,labels,body を優先してください。

8. 報告する

次の項目を含めます。

• トラッカー
• 実行した手順
• 調査した Issue
• 作成したラベル、または不足しているラベル
• 変更した Issue
• agent:ready の件数
• needs:human の件数
• クローズした Issue、または PR の状態に基づいて同期した Issue
• ドリフト調査で作成または見送った Issue
• ブランチのクリーンアップ候補
• 検証結果
• ブロッカーと次のアクション

定期実行

同じワークフローを実行します。 プロンプトには、リポジトリ／トラッカー、真実の基準、Issue 作成ルール、検証要件、成果物の提出先を含める必要があります。

定期実行では、PR のマージ、リリースの公開、シークレットの変更、金銭の使用、ブランチの削除、高リスクな変更を行ってはいけません。 GitHub Actions では、このスキルを .claude/skills/backlog-manager/SKILL.md にコピーします。 デフォルトの GITHUB_TOKEN ではユーザーレベルの GitHub Projects を編集できません。プロジェクトの変更は報告のみとしてください。

GitHub アダプター

利用可能な場合は gh を使用します。

gh repo view --json nameWithOwner,url
gh label list --limit 200
gh label create "risk:low" --color "0E8A16" --description "Low-risk issue suitable for agent execution when agent-ready"
gh issue list --state open --limit 100 --json number,title,body,labels,url,createdAt,updatedAt,comments
gh issue edit <number> --add-label "risk:low,type:docs,agent:ready"
gh issue comment <number> --body-file <file>
gh issue close <number> --comment "Closed because linked PR <url> was merged."
gh project list --owner <owner>
gh project field-list <project-number> --owner <owner> --format json
gh project item-list <project-number> --owner <owner> --limit 200 --format json
gh project item-add <project-number> --owner <owner> --url <issue-or-pr-url> --format json
gh project item-edit --id <item-id> --project-id <project-id> --field-id <status-field-id> --single-select-option-id <option-id>

リンクされた PR には GraphQL または gh pr list／gh pr view を使用します。 プロジェクトへの書き込みがタイムアウトした後に再試行する前に、アイテムの状態を確認して、コメントやプロジェクトアイテムが重複しないようにします。

Linear アダプター

要求され、利用可能な場合は Linear を使用します。 ラベルを直接対応付けます：risk:*、type:*、agent:ready、needs:human。 課題のステータスを既存のワークフロー状態に対応付けます。 依頼がない限り、新しい Linear のステータスを作成しないでください。 Linear と GitHub が接続されている場合は、リンクされた PR の状態を使用します。

呼び出し

$backlog-manager GitHub backlog for this repo
$backlog-manager full backlog loop for GitHub repo owainlewis/neo
$backlog-manager backlog for GitHub Project https://github.com/orgs/acme/projects/7
$backlog-manager Linear backlog for team ENG project Agentic Engineer
$backlog-manager backlog from ./BACKLOG.md as the source of truth