Menú
/brainstorm のユーザーストーリー品質を INVEST 基準で軽量チェックする。proposal.md 生成前にストーリーの構造的品質を確認し、問題があれば対話で改善を促す
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Use at the START of every task, before writing any code, running tests, debugging, reviewing, or designing. This skill determines which methodology and domain skills must be invoked. MUST be invoked before any implementation, debugging, review, testing, or specification work begins.
proposal.md が /spec の入力として十分な情報を含んでいるかを確認する。「ユーザーにとっての承認」ではなく「/spec にとっての準備完了度」を検証する軽量チェック
Use when splitting a domain Skill into Phase-Aware File Structure (SKILL.md / design.md / constraints.md). Defines the splitting criteria, procedures, sync procedures, and validation rules. Invoked by /skill-format command or manually when restructuring domain Skills.
| name | story-quality-gate |
| description | /brainstorm のユーザーストーリー品質を INVEST 基準で軽量チェックする。proposal.md 生成前にストーリーの構造的品質を確認し、問題があれば対話で改善を促す |
ユーザーストーリーの構造的品質を INVEST 基準で軽量チェックする。
目的: 品質の低いストーリーが /spec に流入するのを防ぐ。 タイミング: /brainstorm の要件確定後、proposal.md 生成前。 原則: ブロッキングゲートではない。Warn を出すが、ユーザー判断で進行可能。
各ユーザーストーリーに対して Pass / Warn を判定する。
他のストーリーへの暗黙の依存がないか。
Warn 例: 「ログイン後にプロフィールを編集したい」
→ ログイン機能が暗黙の前提。依存関係を明示するか、分離を検討
Pass 例: 「ユーザーとして、プロフィールを編集したい」
→ 認証済みであることは前提条件として明記可能
実装手段の指定がなく、ゴールが記述されているか。
Warn 例: 「Zustand を使って状態管理したい」
→ 技術指定。/brainstorm では「複数画面で状態を共有したい」が適切
Pass 例: 「商品をカートに入れて、別の画面でも確認したい」
「なぜなら」の理由がユーザーまたはビジネスの価値を示しているか。
Warn 例: 「コードの可読性を上げたい」
→ 技術的理由のみ。ユーザー/ビジネス価値が不明
Pass 例: 「注文履歴を確認したい。なぜなら過去の購入を再注文できるから」
サイズ感が推定できるだけの情報があるか。
Warn 例: 「パフォーマンスを改善したい」
→ どの画面？どの操作？目標値は？範囲が不明
Pass 例: 「商品一覧の初回表示を高速化したい」
1つのストーリーに複数の独立した変更が混在していないか。
Warn 例: 「ユーザー登録、ログイン、パスワードリセットを実装したい」
→ 3つの独立した機能。分割を検討
Pass 例: 「新規ユーザーとして、メールアドレスで登録したい」
測定不能な曖昧表現がないか。
Warn 例: 「エラーを適切にハンドリングしたい」
→ 「適切に」は測定不能。具体的なエラー表示内容が必要
Pass 例: 「入力エラー時にフィールド横にエラーメッセージを表示したい」
ストーリー品質チェック結果:
「ユーザーとして、〇〇したい。なぜなら△△だから」
I: Pass N: Pass V: Pass E: Warn S: Pass T: Warn
⚠ E（見積可能性）: 対象範囲が不明確です。どの画面/機能が対象ですか？
⚠ T（テスト可能性）: 「快適に」は測定が難しいです。具体的な基準はありますか？
→ このまま進めますか？ それとも修正しますか？