Menü
xp-harness の改修バックログをかんばん（1 項目 1 カード）で一覧・追加・更新する。「次なにやるか決めたい」と着手対象を選ぶ場面、改修項目を新規追加・完了・優先度変更する場面で使う。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| 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 設計・テスト戦略のように選択肢が複数ある相談を受けたとき、要件定義 / 設計 / 実装の中で「複数アプローチがありそう」と感じたときに必ず使う。一案だけポンと出さない。