ユーザーストーリーを Independent / Valuable / Small / Testable で点検し、満たさないストーリーを分割または再定義するための skill。要件定義完成直後 (ユーザーストーリーを書き終えた直後) に必ず発火させる。
基本設計中や実装中に「このストーリー大きすぎる」「他のストーリーに依存している」「ユーザー価値が見えない」「受け入れテストが書けない」と気付いたタイミングでも発火させる。Small は『ユーザー価値を保ったまま分割可能な最小単位』として価値ベースで判定する (技術的なサイクル数ではない)。
Negotiable は意図的に落とし (要件 / 設計フェーズで固める方針)、Estimable は暗黙 (固める方針なら自動で満たされる)。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
ユーザーストーリーを大きいまま、または独立性なしで実装フェーズに渡すと:
ストーリー粒度の整理は実装の前提条件で、要件定義の延長で必ず行う。基本設計や実装の中で気付くこともあり、その場合も同じ skill で再度 refine する。
| 場面 | モード | 説明 |
|---|---|---|
| 1. 要件定義完成直後 | auto (必須) | define-requirements がストーリーを書き終えた直後、INVEST 4 観点で点検 |
| 2. 基本設計中 / 完成後 | 判断 invoke | 設計フェーズで「このストーリー大きい / 独立性ない」と気付いたら invoke |
| 3. 実装中 (slice-tdd 委譲) | 判断 invoke | 実装してみて「このストーリー大きすぎる」と気付いたら、slice-tdd から invoke |
| 4. 手動 | 任意 | user / main の明示要求 |
場面 1 を auto にする理由: 「skip OK」を導入すると、main が「これは明らかに大丈夫」と rationalize する余地ができる。INVEST チェック自体は 1 ストーリーなら数秒で済むので過剰にならない。
このプロジェクトでは INVEST から N (Negotiable) を意図的に落とし、E (Estimable) は暗黙とする:
中核は I / V / S / T の 4 観点。
| 観点 | 失格時の対応 |
|---|---|
| Independent | 他のストーリーへの依存があれば、依存解消の分割 or 順序整理 |
| Valuable | エンドユーザー価値が見えなければ、Why に戻って再定義 |
| Small (価値ベース) | 「ユーザー価値を保ったまま分割可能な最小単位」を超えるなら分割 |
| Testable | 受け入れテストが書けなければ Done を観測可能形に書き直す |
Small = ユーザー価値を保ったまま分割可能な最小単位
技術的なサイクル数ではなく、価値ベースで判定する。
「運用管理者が注文履歴を見られる」 — これより小さくすると価値が崩れる:
ストーリー内部で「フロント実装 + API モック → API 本実装」のような技術的サイクル分割が発生するが、これはストーリー分割ではなく slice-tdd の責務 (Cycle 内の刻み)。
「注文履歴 + 商品一覧」 — 2 つの独立な価値単位がまとまっている。分割可能。
分割した片方だけ完成して、ユーザーに価値が届くか?
- YES → Story として分割可能 (例: 「注文履歴」と「商品一覧」は分割可)
- NO → Cycle として刻む (例: API モックとフロント実装は Cycle 内、ストーリー分割しない)
docs/working/<title>/要件定義.md の「ユーザーストーリー」セクションから、現在のストーリー一覧を読む。
各ストーリーについて I / V / S / T の 4 観点で点検する。失格項目があれば次の対応:
失格があれば、依頼者と対話で refine する。1 問ずつ質問、段階的に認識合わせ、セクション単位で approval gate を取る (define-requirements / basic-design と同じ対話の型)。
refine 結果を 要件定義.md のユーザーストーリーセクションをインライン更新 する。新規ファイルは作らない。Refine の経緯は git 履歴で追える。
Independent でも順序依存はありえる (例: ストーリー A の機能の上にストーリー B が建つ)。順序があるなら明記する:
- ストーリー A: 注文履歴を見られる (順序: 1)
- ストーリー B: 注文に承認/差し戻しを付けられる (順序: 2、A の完了が前提)
ストーリー refine は対話駆動。以下を厳守:
AskUserQuestion ツールが使える場面では使う| story-slicing (このスキル) | slice-tdd Step 1 | |
|---|---|---|
| 扱う粒度 | ストーリー (= ユーザー価値の単位) | サイクル内 (= TDD 1 サイクルの単位) |
| 主題 | 独立性 / 受け入れ可能性 / 価値の最小単位 | 実装手順の刻み |
| 失敗時の対応 | ストーリーを分割 or 再定義 | 1 ストーリー内を更にサイクル分割 |
実装中に「このストーリー大きすぎる」と気付いたら、slice-tdd から story-slicing を invoke する (場面 3)。
define-requirements → ユーザーストーリーの初期形を引き出す
↓
story-slicing (本) → 初期形を INVEST 基準で refine
↓
basic-design → refine 済みストーリーごとに How を設計
↓
slice-tdd → 1 ストーリー内の刻みを TDD で実装
cross-cutting なので、basic-design や slice-tdd からも逆向きに invoke される。
要件定義.md の「ユーザーストーリー」セクションをインライン更新。
例 (refine 前):
## 2. ユーザーストーリー
- 運用管理者が、注文のレビュー画面で要確認の注文を見て承認/差し戻しできる
例 (refine 後、Small 分割を適用):
## 2. ユーザーストーリー
- ストーリー A (順序 1): 運用管理者が、要確認の注文一覧を見られる
- ストーリー B (順序 2): 運用管理者が、注文ごとに承認/差し戻しを実行できる (A 完了が前提)
新規ファイルは作らない。Refine 履歴は git で追える。
軽微な案件 (1 ストーリーで明らかに INVEST OK、例: 「ボタンの文言を変える」) でも形式的には INVEST チェックを通す。skip OK を許すと形骸化する。チェック自体は数秒で済むので過剰にならない。
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.