かんばん — xp-harness 改修バックログの確認・更新

なぜこの skill があるか

xp-harness の改修バックログは kanban/ ディレクトリに 1 項目 1 カードで置く。「次なにやるか」を決める・新しい改修項目を足す・終わった項目を完了にする、といった操作の規約と段取りをここに集約する。状況確認は読み取り専用スクリプトに任せ、カードの変更は git 操作で透過的に行う。

これは改修バックログ管理の内部ツールであり、XP の進め方の規律そのものではない（置き場所・配布の扱いは skill-design-style / philosophy のスコープ境界に従う）。

何をカードにするか (スコープ)

かんばんに載るのは 独立して切り出した作業項目 (ストーリー) — 単独で「これをやろう」と着手を決めた改修。利用者 (consumer) に届く機能・変更も、改修者向けの改善も、独立した項目ならカードにする (小粒でもよい。実際、skill description の言い回し修正のような小さな改修も、単独で切り出したものはカード化されてきた)。

載せないのは、別のストーリーを進める流れの中で付随的にやるリファクタリング・改善 — 息をするように当たり前にやるもの。例: ある skill を改修・検証している最中に気づいて直した周辺の不具合や言い回し。これらは ふりかえり や skill 本文の更新に残り、かんばんには載せない。

判断軸: 「独立して着手を予定した項目か、別作業の流れの中で付随的にやったか」を問う。付随なら載せない、独立なら (小粒でも) 載せてよい。重い塊で独立してやりたいものは、迷わず開発者ストーリーとしてカードを切る (「重い」はサイズの下限ではなく、わざわざカード化する動機)。

かんばんの構造

• カードは kanban/ 直下に置く（リポジトリ直下）
• ファイル名は ステータス_優先度_タイトル.md（3 部構成で統一）
  • ステータス: TODO / DONE
  • 優先度: tier1（着手対象） / backlog（未 triage）。tier2/tier3 は実際に振り分けたくなったとき足す。DONE は完了時点の優先度を残す
  • タイトル: 機能を表す簡潔な名前。_ を含めない（区切りはハイフン、日本語可）
• カードは独立。カード間を ID で参照させない
• frontmatter は持たせない（メタ情報はファイル名にある）

状況確認はスクリプトを叩く

.claude/skills/kanban/board.sh がファイル名を読んで盤面を出す（読み取り専用、本文は読まない）:

• board.sh（引数なし）= tier1 の TODO 一覧。「次なにやるか」はまずこれ
• board.sh todo = TODO 全体（tier1 → backlog）。tier1 で決まらないとき / 棚卸しのとき
• board.sh done = DONE 一覧。進捗確認のとき

カードに着手するとき、カードは要件確定ではない

カードを拾って手を動かし始めるときに立ち止まる。カードは出発点であって、要件定義済みの実装指示ではない。tier1 でも、直前に依頼者と内容を確認した直後でも、Why / Done / スコープが固まっているとは限らない。

着手は通常のフェーズゲートを通してから始める（カードがあること自体を「要件確定・実装フェーズ」と扱わない）。具体的には、手を動かす前に git-workflow skill を、要件が固まっていなければ define-requirements skill を呼ぶ。カード起点の着手は「合意済みカードの実行＝ルーチン」と分類されやすく、その瞬間にゲートが飛ぶ（dev 環境で実際に起きた失敗）。

カードの操作はエージェントが git で

状況変更（追加・完了・優先度変更）はスクリプトに持たせない。エージェントが直接行う:

• 新規追加: kanban/TODO_<優先度>_<タイトル>.md を Write する。本文は下記テンプレ。優先度は下記「優先度の確定」の規律に従って決める
• 完了にする: git mv kanban/TODO_<優先度>_<タイトル>.md kanban/DONE_<優先度>_<タイトル>.md。本文を完了記録（後述）に書き換える
• 完了済みを直接 DONE 記録する: TODO カードを経ず shipped した独立項目（= リリース済みだがカードが無かったもの）は、kanban/DONE_<優先度>_<タイトル>.md を直接 Write する（本文は下記の DONE カードテンプレ）。優先度は完了時点の実態を書く（= 実際に着手・完了した項目なので通常 tier1）。着手前の triage でなく完了の記録なので、下記「優先度の確定」の AskUserQuestion は不要
• 優先度を変える: git mv でファイル名の優先度部分を変える（例 backlog → tier1）。優先度は下記「優先度の確定」の規律に従う
• 取り下げる: カードを git rm する。やめた理由の中に再利用したい判断軸があれば、捨てる前に philosophy skill の該当 section へ昇格させる

ファイル名を変える操作なので、依頼者から git の動きが見える。

優先度の確定（依頼者の領分）

優先度はエージェントが黙って決めない。必ず AskUserQuestion で妥当な優先度（tier1 / backlog）を選択肢として提示し、根拠を添えて依頼者の明示選択を取る。チャット文に紛れさせて「提案したから確定」と進めるのは禁止 — 紛れて気づかれず、沈黙・部分回答を同意と扱うと事故る（実際に起きた）。明示選択を得てから Write / git mv / commit / push する（未確認のまま外に出さない）。

カードの中身

frontmatter なし。緩いテンプレ（きっちり固定しない）。

TODO カード:

# <タイトル>

## 背景 / Why
（何の改善か、なぜ要るか）

## 状況
（現状）

## 再開時の起点
（何から始めるか、具体 action）

DONE カードは「再開時の起点」が不要。完了内容と日付の記録に留める:

# <タイトル>

完了 (<日付>)。<何をやったか>