xp-harness の改修バックログをかんばん（1 項目 1 カード）で一覧・追加・更新する。「次なにやるか決めたい」と着手対象を選ぶ場面、改修項目を新規追加・完了・優先度変更する場面で使う。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
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 カードは「再開時の起点」が不要。完了内容と日付の記録に留める:
# <タイトル>
完了 (<日付>)。<何をやったか>
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
xp-harness の公開済みリリースを要約して、チーム周知用の短いテキスト (利用者向けの変化 + 更新手順) を作る。「リリースをアナウンスしたい」「この期間のリリースをまとめて周知したい」「土日の分まとめて」と言われたときに発火。投稿はせずドラフト生成に留める。
The English summary is being prepared. Showing the original description.
要件が固まった機能・変更について、アーキテクチャ・ER・シーケンス・論理設計までを対話で固める「基本設計フェーズ」のスキル。docs/working/<title>/要件定義.md が既にある状態で「設計を進めて」「basic-design」と言われたら必ず発火させる。要件定義が終わって設計フェーズに入りたい依頼、データモデルや API 設計や画面遷移の議論、コンポーネント分割や責務分離の相談、「どう作るか」の構造的な設計が必要な場面で使う。
The English summary is being prepared. Showing the original description.
新規・変更・削除・改善などの要望やレビュー指摘を受けたら、設計や実装に入る前にまず必ず発火させる「要件定義フェーズ」のスキル。依頼者のインテントを読み取り、Why / Done / スコープ / 影響範囲を引き出す。見える挙動が変わる依頼全般が対象で、やることが具体的でも md にまとめられていても発火させ、複数の要望が混ざる依頼ほど積極的に発火させる。発火しないのは、再現条件と期待動作が完全に明確なバグ修正、依存更新・タイポ修正などの定型作業、要件定義と基本設計の文書が両方揃った実装フェーズの続き（メモや TODO があるだけでは除外しない）だけ。
The English summary is being prepared. Showing the original description.
依頼者と議論・対話を進める場面で必ず発火させる skill。共創を目指して、認識を小さく揃えながら、同じ抽象度・レイヤーで話すための対話の進め方を扱う。要件・設計フェーズの対話、実装中の設計判断の議論、レビュー結果の共有、複数の論点・選択肢を依頼者に渡す場面、依頼者からの指摘・反論に応答する場面、「確認したい」「議論したい」「相談したい」と問いかけたいとき、いずれも発火対象。「会話」ではなく「対話」を成立させたい全場面で効く。質問がスルーされる・訂正が続く・話題を変えられる・「そうじゃなくて」と返されるなど、噛み合っていない兆候を観測したときは軌道修正のために再度発火させる。
The English summary is being prepared. Showing the original description.
内部由来の知見（ふりかえりの反映・実プロジェクトの検証記録など）を公開リポジトリに出す前に、組織固有の固有名詞（会社名・内部リポ名・顧客名・人物名・プロジェクト名・ID・パス等）の混入を独立点検して防ぐ。公開 git 履歴は遡れて消せないため、コミット / push の前に必ず通す。機密・認証情報の検査は扱わない。
The English summary is being prepared. Showing the original description.
E2E テストの spec を書く・編集する・レビューする際に必ず発火させる。新しいシナリオの追加、既存 E2E テストの修正・デバッグ、E2E テストの書き方の相談、slice-tdd skill から E2E spec が必要と判断された場面で使う。触る範囲に対応するプロジェクトの E2E の流儀 (spec の書き方・構造・命名) を探して従わせる入口。E2E を実行する手順は扱わない (別スキルの責務)。
The English summary is being prepared. Showing the original description.