brief-to-tasks

このスキルは、設計ブリーフを順序付きの構築可能なタスクリストに変換します。各タスクは縦割りスライスです。つまり、UI の一部分で、単独で構築、レビュー、検証できるものです。

使用例プロンプト

• "ブリーフをタスクに分解して"
• "何を最初に構築すべき?"
• "設計ブリーフからタスクリストを作成して"
• "この機能の構築順序を計画して"

プロセス

1. 設計ブリーフを読みます。.design/*/DESIGN_BRIEF.md を探します。複数のサブフォルダが存在する場合、最後に変更されたものを使用するか、ユーザーに作業している機能を聞きます。また、同じサブフォルダ内の INFORMATION_ARCHITECTURE.md とトークンファイルも確認します。存在しない場合、ユーザーに構築している内容を説明するよう求めます。

2. 既存のコードベースを探索して、既に構築されているものを理解します。具体的に以下をスキャンしてください：

   • コンポーネントディレクトリ: components/、ui/、shared/ を確認し、すべてのコンポーネントを名前でリストアップ
   • 既存のページ/ビュー: この機能が共存する必要がある既に構築されたもの
   • トークン/テーマファイル: tokens.css、globals.css、Tailwind config、テーマプロバイダー
   • ファイル命名規則: ケバブケース、パスカルケース、ファイルの整理方法 (機能別、タイプ別)
   • テストファイル: テストがコンポーネントの横に存在する場合、新しいタスクはテスト期待値を含めるべき
   • package.json の依存関係: 既にインストールされている UI ライブラリ、アニメーションライブラリ、アイコンセット
   • 関連する各コンポーネントを以下のように分類します: そのまま再利用、修正が必要、またはまだ存在しない。修正または作成が必要なコンポーネントだけが独自のタスクを得ます。

3. 作業を縦割りスライスに分解します。各タスクは以下を満たす必要があります：

   • 独立して構築可能である (別のタスクに明記されない限り、あるタスクが別のタスクをブロックしない)
   • 単一のタスク内に構造、スタイル、インタラクションを含める (「HTML を構築」「CSS を追加」「JS を追加」を別のタスクとして分離しない)
   • 検証可能である: 結果を見て、ブリーフと一致することを確認できる
   • 単一のセッションで完了できるほど小さい

4. タスクを以下の順序で並べます：

   • 依存関係優先: ページ固有の作業の前に、基礎要素 (トークン、レイアウトシェル、共有コンポーネント)
   • 視覚的優先度: 最も目立つ UI 要素を早期に配置して、ユーザーが詳細に投資する前に美的方向性を検証できるようにする
   • リスク優先: 最も難しい、または最も不確実な部分を早期に実施して、すべてがその周りに構築される前に問題が表面化するようにする

5. タスクリストを .design/<feature-slug>/ サブフォルダ内、設計ブリーフと同じ場所に TASKS.md として保存します。

タスクリストテンプレート

# Build Tasks: [Feature/Page Name]

Generated from: .design/<feature-slug>/DESIGN_BRIEF.md
Date: [date]

## Foundation
- [ ] **[Task name]**: [構築する対象と「完了」の定義を 1 文で説明]。_Reuses: [既存コンポーネント/トークン (あれば)]._
- [ ] **[Task name]**: [説明]。_New component._

## Core UI
- [ ] **[Task name]**: [説明]。_Depends on: [依存するタスク名 (あれば)]._
- [ ] **[Task name]**: [説明]。

## Interactions & States
- [ ] **[Task name]**: [説明]。Covers: [状態のリスト、例: hover、loading、error、empty]。
- [ ] **[Task name]**: [説明]。

## Responsive & Polish
- [ ] **[Task name]**: [説明]。Breakpoints: [どれか]。
- [ ] **[Task name]**: Accessibility pass。[ブリーフからの特定のチェック]。

## Review
- [ ] **Design review**: ブリーフに対して /design-review を実行。

ルール

• すべてのタスクは、コンポーネントを再利用、修正、または作成するかを参照する必要があります。
• 「プロジェクトをセットアップ」または「ファイル構造を作成」だけのタスクは作成しません。これらは縦割りスライスではありません。
• ブリーフが美的哲学を指定している場合、最初の構築タスクに記載して、視覚的方向性を即座に確立できるようにします。
• 関連タスクをグループ化しますが、1 レベルより深くはネストしません。フラットなリストはより簡単に進行できます。