Menú
タスクを親→子→孫に分解し、コンテキスト継承を設計し、並列実行を最適化する計画スキル。大きなタスクの実装計画・分解・並列化が必要な時に使う。
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
| name | eld-sense-planning |
| context | fork |
| description | タスクを親→子→孫に分解し、コンテキスト継承を設計し、並列実行を最適化する計画スキル。大きなタスクの実装計画・分解・並列化が必要な時に使う。 |
タスク分解→スコープ設計→並列化をワンセットで実行する。
親→子→孫の3レベル以内でタスクを分解する。
原子タスク = 5-10分で完了する最小単位。以下をすべて満たすこと:
git checkout でロールバック可能詳細とアンチパターンは atomic-task-definition.md を参照（粒度判定に迷った時に読む）。
| サイズ | 時間 | 例 |
|---|---|---|
| 原子タスク | 5-10分 | 型定義追加、1関数の実装、1テスト追加 |
| 子タスク | 20-40分 | モジュール実装、API層実装 |
| 親タスク | 2-4時間 | 機能全体の実装 |
各タスクに以下を明示:
task:
name: <タスク名>
level: L0 | L1 | L2 | L3 | L4
verification: <検証方法>
law_term: [<関連Law/Term ID>]
time_estimate: <時間見積もり>
すべての原子タスクは最低1つのLawまたはTermに紐付ける。紐付けがなければ分解が不適切。
Evidence LadderとSeverity別要件の詳細は evidence-requirement.md を参照（Evidence計画時に読む）。
# Task Decomposition: [親タスク名]
## Level 0: Root Task
**Goal**: [全体目標]
**Constraints**: [全体制約]
**Success Criteria**: [完了条件]
## Level 1: Major Components
### 1.1 [子タスク1]
- Goal: [目的]
- Boundary: [責務境界]
- Dependencies: [依存関係]
- Parallel: Yes/No
- Time Estimate: [時間見積もり]
## Level 2: Atomic Tasks
### 1.1.1 [原子タスク1]
- Goal: [目的]
- Evidence Level: L0/L1/L2/L3/L4
- Verification: [検証方法]
- Law/Term: [LAW-xxx, TERM-yyy]
- Time Estimate: 5-10min
## Context Inheritance Map
| From | To | Inherit | Return |
|------|-----|---------|--------|
| Root | 1.1 | [継承情報] | [戻す情報] |
## Evidence Summary
| Task | Level | Law/Term | Verification |
|------|-------|----------|--------------|
| 1.1.1 | L1 | LAW-xxx | ユニットテスト |
機能分割:
機能A実装
├── データ層
├── ビジネスロジック層
└── API層
フェーズ分割:
機能A実装
├── 設計フェーズ
├── 実装フェーズ
└── テストフェーズ
ドメイン分割:
Eコマース機能
├── 商品管理
├── カート管理
└── 決済処理
入れ子プロセス間のコンテキスト継承を設計する。
to_child:
goal: 子タスクの目的（親目的との関係）
constraints: 子に適用される制約のみ
references: 必要な参照のみ（フルパス）
boundary: 子の責務範囲の明確な境界
from_child:
summary: 成果の要約（3行以内）
artifacts: 生成した成果物リスト
decisions: 子が行った重要な決定
issues: 発見した問題・懸念
delta: 潜在プールへ追加すべき知見
| 問題 | 症状 | 対策 |
|---|---|---|
| 過剰継承 | 子がノイズで混乱 | 最小コンテキストに絞る |
| 過少継承 | 子が前提を誤認 | 必須参照を明示 |
| 境界曖昧 | 責務が重複・漏れ | boundary明確化 |
| 差分欠落 | 親が子の学びを失う | deltaを必須化 |
Context継承パターンの詳細（Broadcast/Pipeline/Scatter-Gather/Hierarchical）は context-inheritance.md を参照（Task tool統合で設計に迷った時に読む）。
タスクに渡す最終的なコンテキストは以下の形式に正規化する:
active_context:
goal: <このタスクの目的、期待成果物、完了条件>
constraints: [<セキュリティ/性能/互換性/禁止事項/期限>]
references: [<参照ドキュメント/既存コード/過去決定/外部仕様>]
context: [<実行環境/依存ライブラリ/前提条件>]
expected_output:
format: <成果物の形式>
quality: <品質基準>
validation: <検証方法>
| 項目 | 推奨上限 |
|---|---|
| Goal | 3行 |
| Constraints | 5項目 |
| References | 3ファイル |
| Context | 必要最小限 |
依存関係のないタスクを検出し、Task toolで並列実行する。
いずれの依存もなければ並列実行可能。
依存関係グラフ構築の詳細アルゴリズムは dependency-analysis.md を参照（依存判定に迷った時に読む）。
task-1 (調査)
├→ task-2 (Law抽出) ─┐
└→ task-3 (Term抽出) ─┴→ task-4 (Link Map)
| タスクサイズ | 最大並列度 | 理由 |
|---|---|---|
| 調査・分析（5-10分） | 4-6 | Context継承が小さく統合が容易 |
| 実装（20-40分） | 2-3 | Context継承が中程度 |
| 複雑な実装（2-4時間） | 1-2 | Context継承が大きく統合が複雑 |
1メッセージ内で複数Task toolを呼び出すことで真の並列実行を実現。
各Task toolへ渡すContext設計:
prompt: |
## Task: [タスク名]
### Issue Contract
- Goal: [目的]
- Invariants: [制約]
### 調査対象
- [ファイルパス]（内容は含めずパスのみ）
### リソース（必要に応じて読み取り）
- [参照パス]
### 出力
- [期待する出力形式]
並列タスク完了後:
並列実行パターンと失敗処理の詳細は parallel-patterns.md を参照（失敗時の対応に迷った時に読む）。
以下が発生したら並列実行を中止し、順次実行に切り替え:
User: ユーザー認証システムを実装して
Claude:
# Planning: ユーザー認証システム
## Phase 1: タスク分解
### Level 0: Root Task
**Goal**: JWT認証による安全なユーザー認証
**Constraints**: OWASP準拠、既存DBスキーマ活用
### Level 1: Major Components
1.1 認証コア（30-40min, Parallel: Yes）
1.2 セッション管理（20-30min, Depends: 1.1）
1.3 APIエンドポイント（30-40min, Depends: 1.1, 1.2）
### Level 2: Atomic Tasks（1.1の例）
1.1.1 JWTペイロード型定義（5min, L0, TERM-jwt-payload）
1.1.2 トークン生成関数（8min, L1, LAW-token-expiry）
1.1.3 トークン検証関数（8min, L1, LAW-token-signature）
## Phase 2: スコープ設計
| From | To | Inherit | Return |
|------|-----|---------|--------|
| Root | 1.1 | ADR-003, セキュリティ要件 | トークン仕様 |
| 1.1 | 1.1.1 | JWTペイロード仕様 | 型定義ファイル |
| 1.1 | 1.1.2 | LAW-token-expiry | generateToken実装 |
## Phase 3: 並列化
### Wave 1（並列実行）
- 1.1.1 JWTペイロード型定義
- 1.1.2 トークン生成関数
- 1.1.3 トークン検証関数
→ 3タスクを同時にTask tool実行
### Wave 2（Wave 1完了後）
- 1.2 セッション管理
分解完了。Wave 1から開始しますか？
デザインシステムの構築・運用を体系的に行うスキル。ドキュメント（要件定義・ブランドガイドライン）からDesign Tokens・コンポーネント体系・ガバナンスまでを一貫して設計する。思考フレームワーク（Double Diamond・Atomic Design・Design Tokens 3層）の適用、暗黙的デザイン判断の形式知化（DDR/QOC/RFC）、UIインベントリ収集（手動+MCP自動化）を統合する。ゼロから体系的に構築する用途向け。既存の単発UIから再利用可能な構造を抽出するにはrelational-design-pluginのdesign-system-backflowスキルを使用すること。Use when: 「デザインシステムを構築して」「デザインシステムを設計して」「デザイントークンを定義して」「デザイン原則を策定して」「UIインベントリを作って」「デザインガバナンスを設計して」「デザイン判断を記録して」と言われた時。
iOS/Androidモバイルアプリのデザインを体系的に行うスキル。Apple HIG・Material Design 3などプラットフォームガイドラインに準拠し、ナビゲーション・レイアウト・コンポーネント・モーション・アクセシビリティを適切に設計する。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「モバイルアプリをデザインして」「iOSアプリのUIを設計して」「Androidアプリの画面を作って」「モバイルのナビゲーションを設計して」「タッチUIを改善して」「アプリのアクセシビリティを対応して」と言われた時。
Webアプリの個別画面・コンポーネントのデザインを体系的に行うスキル。デザインプロセス・レイアウト・コンポーネント設計・インタラクション・アクセシビリティなどWebデザインの確立された手法を適用する。デザインシステム全体の構築・運用はdesign-system-builderスキルを使用すること。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「Webアプリをデザインして」「UIを設計して」「画面をデザインして」「レスポンシブ対応して」「アクセシビリティを改善して」「コンポーネントを設計して」「カラーパレットを決めて」と言われた時。
Use this skill when a design assumption, user segment, business goal, constraint, or product requirement has changed and you need to analyze which design hypotheses, decisions, artifacts, copy, or components should be retracted or revised. Requires a Relational Design trace session with recorded observations/relations/hypotheses/decisions to analyze against — not a general "redo this design" request.
Use this skill to critique an existing UI, frontend implementation, wireframe, flow, or visual design through Relational Design relations: user state, business intent, action risk, trust, information density, reversibility, accessibility, and implementation constraints. This is a relation-based critique, not a general design-methodology review — for platform-guideline or design-system compliance review, use design-plugin instead.
Use this skill after creating or reviewing a design artifact to extract reusable design-system knowledge: semantic tokens, components, variants, interaction rules, copy patterns, accessibility constraints, and governance notes. This only backflows structure out of an artifact that already exists — to build or govern a design system from scratch (Design Tokens layers, Atomic Design, DDR/QOC/RFC, UI inventory), use design-plugin's design-system-builder instead.