idea-triage

Files (2)

• SKILL.md
• backlog.sh · scripts/

SKILL.md (first lines)

# idea-triage — 溜まった idea を選んで夜間ジョブに流す

## このスキルの位置

```
idea スキル ─┐
              ├→ idea ラベルの Issue ─→ 【idea-triage】 ─→ automation ラベル ─→ nightly が実装
weekly-audit ┘        (インボックス)        (ここ)              (発注)
```

`idea` は溜める場所、`automation` は発注の合図。その間をつなぐのがこのスキル。
**ラベルが付くまで何も起きない**のがこのパイプラインの設計なので、ここが滞ると
夜間ジョブは毎晩「やることなし」で空振りし続ける。実際にそれで8日間止まったことがある。

## 手順

### 1. バックログを出す

```bash
scripts/backlog.sh <owner/repo> [owner/repo ...]
```

対象リポジトリが分からなければ、`~/.claude-harness/nightly/config.sh` の `REPOS` を見る
（夜間ジョブが実際に見ているのはそこなので、そこに無いリポジトリにラベルを付けても動かない）。

出力にはタイトルのほか、選別に効く3つの情報が付く。

| 表示 | 意味 | 選別でどう使うか |
|---|---|---|
| 経過日数 | 起票からの日数 | 古いものは前提が変わっている疑いを持つ |
| 本文字数 | Issue 本文の長さ | **エージェントは本文だけを仕様として読む**。薄いものはそのまま流せない |
| `PR中` | 未マージの PR が既にある | ラベルを付けても nightly はスキップする。先に PR を片付ける |
| `本文薄` | 本文120字未満 | 手順3で本文を書いてから流す |
| `古い` | 30日超 | 今も成り立つか確認する |
| `再現済` | weekly-audit が失敗テストで再現を確認した (`repro` ラベル) | 本文の再現テストがそのまま完了判定になるので、最も安心して流せる |
| `重大` | `sev:high` (データ消失・セキュリティ・主要機能が使えない) | 判断材料として並べる。優先するかどうかはユーザーが決める |

### 2. 束ねて見せる

そのまま貼り付けるのではなく、**ユーザーが番号を言えばいい状態**にして出す。

- 新しい順に並べる。古いものは別の塊にまとめ、「前提が変わっている可能性がある」と添える
- 内容が近いものは並べる（同じファイルを触るものを同時に流すとコンフリクトする）
- 一言ずつ所感を付ける。「データが消える系」「表示の誤り」のような粒度でよい。
  **ここで優先順位を断定しない**。決めるのはユーザーで、こちらは判断材料を並べる役

大きな移行やリファクタの直後なら、それ以前に起票されたものはまとめて
「一旦見送りを勧める」と言ってよい。実際、Cloudflare 移行の前後で前提が変わり、
移行前の14件が丸ごと怪しくなったことがある。

### 3. 選ばれたものを実装できる形にする

ここがこのスキルの本体。**本文が薄いまま `automation` を付けてはいけない。**

`idea` スキルは思考を止めないことを優先して本文を空のまま登録する。一方
nightly のエージェントは worktree の中で Issue 本文だけを仕様として読む。
つまり本文が空のものを流すと、エージェントはタイトル1行だけを頼りに実装することになり、
見当違いのものが出てくるか、何もせず終わる。

`本文薄` が付いているものを選ばれたら、流す前にコードベースを読んで本文を書く。
書くのは次の3つだけでよく、実装方針まで決め切る必要はない。

```markdown
## 現象
（どこで何が起きるか。ファイルパスと行番号を添える）

## なぜ問題か
（ユーザーから見て何が困るか。再現条件があれば書く）

## 完了の判定
（何が満たされれば直ったと言えるか。テストで判定できるなら、そのテスト）
```

書いたら**本文をユーザーに見せて確認を取ってから**反映する。仕様を勝手に決めて
流してしまうと、エージェントは忠実にその勝手な仕様を実装してしまう。

weekly-audit が作った Issue は「現象 / なぜ問題か / 再現テスト / 完了の判定」の
見出しで書かれているので、たいていそのまま流せる。`repro` が付いていないものは
再現テストを書けなかった理由が本文にあるので、それを読んでから判断する。

### 4. ラベルを付ける

```bash
gh issue edit <番号> <番号> -R <owner/repo> --add-label automation
```

一度に流す数は控えめにする。nightly は1リポジトリあたり既定3件、並行数1で回すので、
10件付けても消化に時間がかかるうえ、まとめて失敗したときに原因が切り分けにくい。
**まず2〜3件流して、翌朝の PR を見てから次を決める**のが扱いやすい。

### 5. 次に何が起きるかを伝える

ラベルを付けて終わりにせず、ユーザーが待てばいいのか動くべきかを伝える。

- 次の実行時刻（nightly は 2:00 と 8〜22時の偶数時）
- PR ができたら自動レビューが走り、指摘があれば `review-findings` が付いて自動マージが止まること。
  **ラベルを外すのが承認の操作**になること
- 詰まった PR（CI失敗・コンフリクト）には `needs-attention` が付き、新規のときだけ通知が飛ぶこと

## やらないこと

- **優先順位を断定しない。** 何が重要かはユーザーの状況次第で、こちらには見えていない
- **勝手に閉じない。** 「これは不要では」と思っても提案に留める。インボックスの整理は
  ユーザーの判断で、勝手に捨てられると次から放り込むのをためらうようになる
- **新しいアイデアを出さない。** ここは選ぶ場所。思いつきの記録は `idea` スキル、
  機械による発見は週次の weekly-audit が担当している

## 関連

- `idea` — 思いつきを1行で Issue にする（このスキルの上流）
- `ticket-breakdown` — まとまった要件を並行実装できる単位に分割する（別経路）
- `harness-ops` — spawn-agents / nightly の運用

From inai17ibar/claude-dev-harness, MIT.

More from inai17ibar/claude-dev-harness