mcpField
B
brief-to-tasks

brief-to-tasks

github.com/julianoczkowski開発5945.2k 回インストール16 週間前に更新
リポジトリ

brief-to-tasks について

brief-to-tasksは、デザインブリーフと既存コードベースを基に、実装・検証可能なUIタスクを順序立てて作成します。機能開発の計画向けで、独立した縦割りの作業単位に整理し、TASKS.mdに保存します。

主な機能

  1. 01デザインブリーフとプロジェクト構成の確認
  2. 02再利用・変更・新規作成するコンポーネントの特定
  3. 03検証可能な縦割りタスクへの分解
  4. 04依存関係・視覚的優先度・リスクによる順序付け
  5. 05タスクリストのTASKS.mdへの保存

活用シーン

  1. 01デザインブリーフから実装を計画
  2. 02最初に取り組むUIタスクの選定
  3. 03既存コンポーネントに沿った機能開発の調整

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/julianoczkowski/designer-skills --skill brief-to-tasks

インストール後、Claude Code で/brief-to-tasksを入力して読み込まれたか確認します。

詳細

このスキルでは、デザインブリーフを順序付けされた、実装可能なタスクリストに変換します。各タスクは垂直スライスです。単独で構築、レビュー、検証できる UI の一部を指します。

プロンプトの例

  • 「ブリーフをタスクに分割して」
  • 「最初に何を構築すべきですか？」
  • 「デザインブリーフからタスクリストを作成して」
  • 「この機能の構築順序を計画して」

プロセス

  1. デザインブリーフを読みます。.design/*/DESIGN_BRIEF.md を探してください。サブフォルダーが複数ある場合は、最終更新日時が最も新しいものを使うか、ユーザーにどの機能に取り組んでいるか尋ねてください。同じサブフォルダーにある INFORMATION_ARCHITECTURE.md とトークンファイルも確認してください。いずれも存在しない場合は、何を構築しているのか説明するようユーザーに尋ねてください。

  2. 既存のコードベースを調べ、すでに構築されているものを把握します。特に次を確認してください。

    • コンポーネントディレクトリ：components/、ui/、shared/ を確認し、すべてのコンポーネント名を列挙します
    • 既存のページ／ビュー：この機能と共存する必要がある、すでに構築済みのもの
    • トークン／テーマファイル：tokens.css、globals.css、Tailwind の設定、テーマプロバイダー
    • ファイルの命名規則：kebab-case、PascalCase、ファイルの整理方法（機能別、種類別）
    • テストファイル：コンポーネントと併せてテストが存在する場合、新しいタスクにテスト要件を含める必要があります
    • package.json の依存関係：すでにインストールされている UI ライブラリ、アニメーションライブラリ、アイコンセット
    • 関連する各コンポーネントを次のように分類します。そのまま再利用する、変更が必要、まだ存在しない。変更または作成が必要なコンポーネントのみ、個別のタスクにします。

  3. 作業を垂直スライスに分割します。各タスクは次の条件を満たす必要があります。

    • 単独で構築できる（特記がない限り、あるタスクが別のタスクを妨げない）。
    • 構造、スタイル、操作を1つのタスクに含める（「HTML を構築」「CSS を追加」「JS を追加」と別々のタスクにしない）。
    • 検証可能である（結果を見て、ブリーフに合っていることを確認できる）。
    • 1回の作業セッションで完了できる規模である。

  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]**: [One sentence describing what to build and what "done" looks like]. _Reuses: [existing components/tokens if any]._
- [ ] **[Task name]**: [Description]. _New component._

## Core UI
- [ ] **[Task name]**: [Description]. _Depends on: [task name if any]._
- [ ] **[Task name]**: [Description].

## Interactions & States
- [ ] **[Task name]**: [Description]. Covers: [list of states, e.g., hover, loading, error, empty].
- [ ] **[Task name]**: [Description].

## Responsive & Polish
- [ ] **[Task name]**: [Description]. Breakpoints: [which ones].
- [ ] **[Task name]**: Accessibility pass. [Specific checks from the brief].

## Review
- [ ] **Design review**: Run /design-review against the brief.

ルール

  • 各タスクで、コンポーネントを再利用、変更、作成するかを必ず明記します。
  • 「プロジェクトをセットアップする」「ファイル構造を作成する」だけのタスクは作成しないでください。これらは垂直スライスではありません。
  • ブリーフでデザインの美学が指定されている場合は、視覚的な方向性をすぐに確立できるよう、最初の構築タスクにその方針を記載してください。
  • 関連するタスクはまとめますが、階層は1段階より深くしないでください。フラットなリストのほうが取り組みやすくなります。

コメント

Markdown 対応