Menu
xp-harness の改修バックログをかんばん（1 項目 1 カード）で一覧・追加・更新する。「次なにやるか決めたい」と着手対象を選ぶ場面、改修項目を新規追加・完了・優先度変更する場面で使う。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | kanban |
| description | xp-harness の改修バックログをかんばん（1 項目 1 カード）で一覧・追加・更新する。「次なにやるか決めたい」と着手対象を選ぶ場面、改修項目を新規追加・完了・優先度変更する場面で使う。 |
xp-harness の改修バックログは kanban/ ディレクトリに 1 項目 1 カードで置く。「次なにやるか」を決める・新しい改修項目を足す・終わった項目を完了にする、といった操作の規約と段取りをここに集約する。状況確認は読み取り専用スクリプトに任せ、カードの変更は git 操作で透過的に行う。
これは改修バックログ管理の内部ツールであり、XP の進め方の規律そのものではない（置き場所・配布の扱いは skill-design-style / philosophy のスコープ境界に従う）。
かんばんに載るのは 独立して切り出した作業項目 (ストーリー) — 単独で「これをやろう」と着手を決めた改修。利用者 (consumer) に届く機能・変更も、改修者向けの改善も、独立した項目ならカードにする (小粒でもよい。実際、skill description の言い回し修正のような小さな改修も、単独で切り出したものはカード化されてきた)。
載せないのは、別のストーリーを進める流れの中で付随的にやるリファクタリング・改善 — 息をするように当たり前にやるもの。例: ある skill を改修・検証している最中に気づいて直した周辺の不具合や言い回し。これらは ふりかえり や skill 本文の更新に残り、かんばんには載せない。
判断軸: 「独立して着手を予定した項目か、別作業の流れの中で付随的にやったか」を問う。付随なら載せない、独立なら (小粒でも) 載せてよい。重い塊で独立してやりたいものは、迷わず開発者ストーリーとしてカードを切る (「重い」はサイズの下限ではなく、わざわざカード化する動機)。
kanban/ 直下に置く（リポジトリ直下）ステータス_優先度_タイトル.md（3 部構成で統一）
TODO / DONEtier1（着手対象） / backlog（未 triage）。tier2/tier3 は実際に振り分けたくなったとき足す。DONE は完了時点の優先度を残す_ を含めない（区切りはハイフン、日本語可）.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 環境で実際に起きた失敗）。
状況変更（追加・完了・優先度変更）はスクリプトに持たせない。エージェントが直接行う:
kanban/TODO_<優先度>_<タイトル>.md を Write する。本文は下記テンプレ。優先度は下記「優先度の確定」の規律に従って決めるgit mv kanban/TODO_<優先度>_<タイトル>.md kanban/DONE_<優先度>_<タイトル>.md。本文を完了記録（後述）に書き換える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 カードは「再開時の起点」が不要。完了内容と日付の記録に留める:
# <タイトル>
完了 (<日付>)。<何をやったか>
xp-harness の skill / subagent が意図どおり振る舞えているか (発火するか・あるべき振る舞いができているか) を transcript で事実確認する手順。skill / subagent を改修した後に sandbox で動作検証したいとき、または本番の実運用セッションを「あるべき振る舞い」に照らして分析したいとき、「検証したい」「発火するか確かめたい」「このセッションを分析したい」と言われたときに発火させる。核は発火・振る舞いができたかの事実確認で、本番セッションでは自走の良し悪し (止まり方・判断の質など) も見る。
要件が固まった機能・変更について、アーキテクチャ・ER・シーケンス・論理設計までを対話で固める「基本設計フェーズ」のスキル。docs/working/<title>/要件定義.md が既にある状態で「設計を進めて」「basic-design」と言われたら必ず発火させる。要件定義が終わって設計フェーズに入りたい依頼、データモデルや API 設計や画面遷移の議論、コンポーネント分割や責務分離の相談、「どう作るか」の構造的な設計が必要な場面で使う。
新規・変更・削除・改善などの要望やレビュー指摘を受けたら、設計や実装に入る前にまず必ず発火させる「要件定義フェーズ」のスキル。依頼者のインテントを読み取り、Why / Done / スコープ / 影響範囲を引き出す。見える挙動が変わる依頼全般が対象で、やることが具体的でも md にまとめられていても発火させ、複数の要望が混ざる依頼ほど積極的に発火させる。発火しないのは、再現条件と期待動作が完全に明確なバグ修正、依存更新・タイポ修正などの定型作業、要件定義と基本設計の文書が両方揃った実装フェーズの続き（メモや TODO があるだけでは除外しない）だけ。
依頼者と議論・対話を進める場面で必ず発火させる skill。共創を目指して、認識を小さく揃えながら、同じ抽象度・レイヤーで話すための対話の進め方を扱う。要件・設計フェーズの対話、実装中の設計判断の議論、レビュー結果の共有、複数の論点・選択肢を依頼者に渡す場面、依頼者からの指摘・反論に応答する場面、「確認したい」「議論したい」「相談したい」と問いかけたいとき、いずれも発火対象。「会話」ではなく「対話」を成立させたい全場面で効く。
Git 運用の規律 (branch / worktree 運用、commit / push / pull / rebase / conflict 解決、remote 同期、完了時の統合) を一元的に担う skill。コード変更を伴う依頼・セッション開始・Git 操作の話題のいずれかに該当したら、他より先に必ず最初に使う。ファイルを 1 行でも書き換える依頼なら Git に無関係に見えても発火し、セッション開始・作業再開 (「前回の続き」「何から始めよう」等) でも必ず発火する。発火しないのはコードを読むだけの質問、Git の概念学習質問、doc のサマリ依頼。project 固有ルールでの部分上書きに対応する。
設計判断・ライブラリ選定・アーキ判断・実装アプローチが 2 つ以上ありえる場面で必ず発火させる、「複数案＋メリデメ＋推奨」を提示する横断スキル。「どっちがいい？」「これでいい？」「方針を相談したい」と聞かれたとき、ライブラリ選定・ディレクトリ構成・API 設計・テスト戦略のように選択肢が複数ある相談を受けたとき、要件定義 / 設計 / 実装の中で「複数アプローチがありそう」と感じたときに必ず使う。一案だけポンと出さない。