grove-issues

Grove Issues

思いつきを、整理された課題バックログに変換します。雑多な TODO のリストを受け取り、Lattice Kanban ボードですぐに使える、適切なラベル付きの構造化された GitHub の課題を作成します。

有効化する条件

• ユーザーが 1 つのメッセージで複数の TODO、タスク、アイデアを提示した場合
• ユーザーが /grove-issues を明示的に呼び出した場合
• ユーザーが「これらの課題を作成して」や「これらをチケットにして」のように依頼した場合
• ユーザーが追跡したい項目のリストを貼り付けた場合

---

パイプライン

Brain Dump → Parse → Deduplicate → Create Issues → Label → Report

ステップ 1：思いつきを解析する

ユーザーのメッセージを、個別に実行可能な課題に分割します。各課題は 1 つの作業を表すものとします。TODO の範囲が広すぎる場合は分割します。2 つの TODO が同じ内容の場合は統合します。

解析の手がかり：

• 番号付きリスト → 項目ごとに 1 つの課題
• 箇条書き → 箇条書きごとに 1 つの課題
• 改行で区切られた段落 → 段落ごとに 1 つの課題
• コンマで区切られた項目 → 項目ごとに 1 つの課題
• とりとめのない文章 → 論理的な区切りを判断して分割

ステップ 2：重複を確認する

課題を作成する前に、既存のオープンな課題を検索し、内容が重複していないか確認します。

gh issue list --state open --limit 100 --json number,title | jq -r '.[].title'

TODO が既存の課題とよく一致する場合はスキップし、報告時に既存の課題番号を記載します。重複する課題は作成しないでください。

ステップ 3：ラベルを決める

各課題に最大 3 つのラベルを付けます。

コンポーネントラベル（1～3 個選択）

ラベル	適用する場合
lattice	フレームワーク、モノレポ、共有インフラストラクチャ、エンジンパッケージ
heartwood	認証、セッション、OAuth、アイデンティティ
arbor	管理パネル、バックエンド API、管理ダッシュボード
amber	画像、CDN、R2 ストレージ、JXL、メディアパイプライン
clearing	ステータスページ、ヘルスモニタリング、稼働時間
shade	AI クローラー対策、ボット防御、レート制限
plant	料金設定、請求、LemonSqueezy、ストアフロント、サインアップ
ivy	メール、Resend、通知、メッセージング
foliage	テーマ設定、デザイントークン、テナントごとのカスタマイズ
curio	博物館の展示、コンテンツ表示、ゲストブック
meadow	ソーシャル機能、コミュニティフィード
forests	フォレストページ、コミュニティグローブ、物件紹介
vine	コンテンツ間の関連付け、余白メモ、つながり
graft	フィーチャーフラグ、段階的なロールアウト、A/B テスト
petal	コンテンツモデレーション、CSAM 検出、PhotoDNA
lumen	AI アシスタント、LLM ルーティング、AI ゲートウェイ
mycelium	MCP サーバー、サービス間ネットワーキング
patina	バックアップ、コールドストレージ、データ保全
landing	ランディングサイト、マーケティングページ、ナレッジベース

パターンラベル（コンポーネントラベルに加えて 0～2 個選択）

パターンは、再利用可能なアーキテクチャ上の解決策です。課題にパターンの実装または拡張が含まれる場合に適用します。

ラベル	適用する場合
pattern:firefly	一時的なサーバーインフラストラクチャ（ignite、illuminate、fade のライフサイクル）
pattern:loom	Durable Objects による調整（SessionDO、TenantDO、PostDO）
pattern:prism	グラスモーフィズムのデザインシステム、季節ごとのテーマ設定、UI レイヤー
pattern:sentinel	負荷テスト、スケール検証、ランプアップテスト
pattern:songbird	プロンプトインジェクション対策（canary、kestrel、robin の各レイヤー）
pattern:threshold	レート制限、不正利用の防止、段階的な対応

種別ラベル（必ず 1 つ選択）

ラベル	適用する場合
bug	何かが壊れている、または正しく動作しない場合
feature	まだ存在しない機能を追加する場合
enhancement	既存の機能を改善する場合
security	セキュリティ上の懸念、脆弱性、強化
documentation	ドキュメント、ガイド、ヘルプ記事

優先度（ユーザーが明示した場合のみ）

優先度を推測しないでください。ユーザーが緊急、重大、または優先度が低いと明示した場合にのみ適用します。

ステップ 4：Issue の本文を書く

すべての Issue にこのテンプレートを使用します。

## Summary
[1-3 sentences describing what needs to be done and why]

## Acceptance Criteria
- [ ] [Specific, verifiable criterion]
- [ ] [Another criterion]
- [ ] [Keep to 3-6 items]

## Context
- [Relevant technical context]
- [Dependencies or related issues if known]
- [Any constraints mentioned by the user]

作成ガイドライン：

• Summary では、「何を」「なぜ」行うのかを平易な言葉で説明します。エンジニアでない人にも、最初の文だけで理解できるようにしてください。
• 受け入れ条件は、完了／未完了を確認できるチェックボックス項目にします。
• Context は任意ですが、記載すると役立ちます。ファイルパス、パターン、略語などの技術的な詳細はここに記載します。
• 本文全体を 20 行未満に収めます。網羅性より簡潔さを優先してください。
• 定型文で水増ししないでください。役立つ情報がなければ、そのセクションは省略します。

ステップ 5：Issue を作成する

gh issue create \
  --title "Title in imperative mood" \
  --body "$(cat <<'EOF'
## Summary
...

## Acceptance Criteria
- [ ] ...

## Context
- ...
EOF
)" \
  --label "component1,type1"

タイトルのガイドライン：

• まずは平易な言葉で — 実装担当者ではなく、ボードをざっと見るプロジェクトオーナー向けに書きます。
• 命令形にします。「X を追加する」とし、「X を追加している」や「X を追加すべき」とはしません。
• 形式：Service: 平易な言葉で何が起きるか（例：「Plant: 料金ページの壊れた画像を修正する」）
• 可能であれば 60 文字未満にします。
• [FEATURE] や [BUG] の接頭辞は付けません（分類にはラベルを使用します）。
• Grove のサービス名以外の専門用語や略語は使いません。タイトルに HMR、PKCE、DO、SSR、CSRF などは使わず、正式名称にするか、平易な言葉で言い換えます。（技術的な詳細は本文に記載します。）
• セルフチェック： 各タイトルを読んで、次のように自問します。「ほかに 100 件の Issue が並ぶボード上でも、クリックせずにすぐ理解できるだろうか？」 そうでなければ、書き直します。

良いタイトルと悪いタイトル：

悪い例（専門用語が多い）	良い例（平易な言葉）
Hybrid dev mode: HMR + service binding fidelity	Dev mode: 実際のサービスバインディングを維持しながらライブリロードに対応する
Thorn behavioral: finish remaining wiring	Thorn: 残りのレート制限とラベルのチェックを接続する
Graduate Reeds (comments) out of greenhouse	Reeds: コメントを本番環境向けの完全な機能にする
Implement Queen coordinator Durable Object	Queen: バックグラウンドワーカーを管理するコーディネーターを構築する

ステップ 6：報告する

すべての Issue を作成したら、ユーザーに概要の表を提示します。

Created X issues:

| # | Title | Labels |
|---|-------|--------|
| #531 | Add glass overlay to Forest page | forests, enhancement |
| #532 | Fix tooltip positioning on mobile | lattice, bug |
...

Skipped (duplicates of existing issues):
- "Cache purge tool" → already tracked in #527

---

例外ケース

あいまいな TODO

TODO の内容があいまいすぎて適切な Issue を作成できない場合（「あれを直す」「もっと良くする」など）は、質の低い Issue を作成するのではなく、ユーザーに詳細を確認します。あいまいな項目をまとめ、一度に質問します。

大量の項目（20 件以上）

非常に多くの項目がある場合は、レート制限を避けるため、10 件ずつに分けて Issue を作成します。バッチの合間に一時停止します。

優先度が混在している場合

ユーザーが一部の項目を緊急／最優先として、ほかをバックログとして示した場合は、その内容を Context に記載します。ただし、ユーザーが明確に優先度について述べていない限り、優先度ラベルは付けません。

アイデアメモに含まれる実装の詳細

ユーザーが何をするかだけでなく、どのように実装するかも記載している場合は、その詳細を Context セクションに記載します。受け入れ条件は、引き続き実装方法ではなく結果に焦点を当てます。

---

アンチパターン

次のことはしないでください：

• タイトルだけで本文のない Issue を作成しない
• コンポーネントラベルを 3 つより多く付けない（すべてに関係する場合は、おそらく lattice です）
• 検証できない受け入れ条件を推測しない。「問題なく動作する」は条件になりません。「モバイルのビューポートで正しく描画される」は条件になります。
• すでに完了している項目の Issue を作成しない
• 「コードに十分なドキュメントがある」「テストが通る」のような汎用的な条件で Issue を水増ししない
• ユーザーが重大／緊急だと明言していない限り、priority-critical を追加しない

---

例

ユーザーの発言：

そうだな、やる必要があるのは、料金ページの壊れた画像の修正、ナレッジベースへのダークモード切り替えの追加、blog-engine の新しいヘルスエンドポイントの接続。それから、いずれ meadow に RSS フィードを追加することも検討したい。

作成する Issue：

1. 「料金ページの壊れた画像を修正する」 — plant、bug
2. 「ナレッジベースにダークモード切り替えを追加する」 — landing、enhancement
3. 「blog-engine のヘルスエンドポイントを Clearing に接続する」 — clearing、feature
4. 「Meadow に RSS フィード対応を追加する」 — meadow、feature

それぞれに適切な Summary、Acceptance Criteria、Context を記載します。

---

整理されたバックログは、落ち着いた心をもたらします。混乱を明快さに変えましょう。