コンテンツにスキップ
soloscrum docs

/refine

/refine は、ふわっとしたアイデア — 1 文のメモ、段落単位の文章、書きかけのバグ報告 — を、Background / Goal / Acceptance Criteria / Out of Scope の 4 セクションを持つ GitHub Issue に整形します。後続の command はこの形を前提に動きます。Issue を作る前に、まずバックログを sweep して、closing PR が merge 済みなのに open のまま残っている Issue を閉じます。

使い方

Section titled “使い方”
Terminal window
/refine <idea or feature description> [--no-janitor]

引数は自由なテキストです。--no-janitor を付けるとバックログ sweep をスキップします。GitHub API の挙動が不安定なとき、または command 冒頭の出力を静かにしたいときに使ってください。

処理の流れ

Section titled “処理の流れ”
  1. バックログ janitor。 open Issue を順に確認し、closing keyword (Closes #N / Fixes #N / Resolves #N など) を持つ PR が merge 済みかをチェックします。該当する Issue は completed の理由で close します。出力の 1 行目は Closed N stale Issue(s): #X, #Y か No stale Issues found、--no-janitor 指定時は Janitor skipped です。janitor は close するのみで、reopen することはありません。
  2. アイデアの構造化。 PO agent がアイデアを読み、4 セクション構成の Issue 本文を組み立て、priority ラベルを選び、size-check SP を算出します。
  3. サイズゲート。 size-check SP が 5 を超えると、Issue を作成する前に「大きすぎる」と判定して分割を提案します。issue size を参照してください。
  4. 承認。 整形した Issue 本文をユーザに提示します。
  5. Issue 作成。 承認後、priority ラベルを付けた状態で GitHub Issue を作成します。

典型的な流れ

Section titled “典型的な流れ”

/refine "users should be able to reset their password by email" を実行すると、最初の行に janitor の結果が出ます。掃除済みのリポジトリでは通常 No stale Issues found です。続いて PO agent が、ユーザニーズを説明する Background 段落、1 文の Goal、3-5 個の AC チェックボックス、明示的な Out of Scope を組み合わせた Issue 本文を提示します。priority (ユーザが初日から触る機能なら high など) と size-check SP も提示します。

SP が 5 以下なら承認して Issue を作成します。authentication / email infrastructure / form UI に跨って SP が 8 になるような場合、command は Issue を「大きすぎる」と判定し、機能軸で分割するよう提案します。それぞれに /refine を再実行するか、/breakdown で subtask に切ります。

新規 Issue を起票しないセッションでも、/refine を最初に走らせるのは自然です。janitor sweep がバックログを正確に保ってくれます。

出力

Section titled “出力”
  • 1 行目: janitor の結果
  • 作成した GitHub Issue の URL
  • 適用された priority ラベル
  • size-check SP (情報用。tracker には保存されません — tracker に保存される SP は /breakdown が書き込む subtask 側の値です)

参考

Section titled “参考”