skanehira/implementation-planning-tasks
claude/skills/implementation-planning-tasks/SKILL.md
承認済みの設計書（DESIGN.md）からTDD準拠のTODO.mdを作成します。analyzing-requirementsスキルで設計が完了・承認された後に使用します。developingスキルで実装できる形式のタスクリストを生成します。
$ install --global
skillsauthnpx skillsauth add skanehira/dotfiles implementation-planning-tasksInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 17, 2026, 7:29 AM43.3s1 file scanned
SKILL.md
- name:
- implementation-planning-tasks
- description:
- 承認済みの設計書（DESIGN.md）からTDD準拠のTODO.mdを作成します。analyzing-requirementsスキルで設計が完了・承認された後に使用します。developingスキルで実装できる形式のタスクリストを生成します。
タスク計画
参照ルール（必須）
Claude指示: タスク分解を開始する前に、必ず以下のルールファイルをReadツールで読み込んでください。
- TDDルール:
rules/core/tdd.md - 設計原則:
rules/core/design.md - コミットルール:
rules/core/commit.md
概要
承認済みの設計書（DESIGN.md）を読み込み、TDD（テスト駆動開発）に準拠したTODO.mdを作成する。生成されるTODO.mdはdevelopingスキルで直接使用できる形式となる。
前提条件: analyzing-requirementsスキルで作成されたDESIGN.mdが存在し、ユーザーに承認されていること。
コアワークフロー
ステップ1: 設計書の確認
DESIGN.mdを読み込み、全体を確認する：
Read(file_path="docs/DESIGN.md")
設計書の全セクションを把握し、タスク分解に必要な情報を抽出する。
ステップ2: タスク分解
設計書から実装タスクを抽出し、TDDサイクルに従って分解する：
分解の原則
- 機能単位で分割: 1つの機能 = 1つのTDDサイクル
- 依存関係を考慮: 基盤 → コア機能 → 拡張機能の順
- テストファースト: 各機能でRED→GREEN→REFACTORを明示
タスクの粒度
- 1タスク = 1-4時間で完了可能
- テスト1つ + 実装1つ = 1セット
- リファクタリングは独立したタスク
ステップ3: TODO.md生成
以下の形式でTODO.mdを生成する：
# TODO: [プロジェクト名]
作成日: [日付]
生成元: planning-tasks
設計書: docs/DESIGN.md
## 概要
[設計書から抽出した目的と範囲]
## 実装タスク
### フェーズ1: 基盤構築
- [ ] プロジェクト構造のセットアップ
- [ ] 依存パッケージのインストール
- [ ] 開発環境の設定
### フェーズ2: [機能名A] の実装
- [ ] [RED] [機能A]の動作テストを作成
- [ ] [GREEN] テストを通過させる最小限の実装
- [ ] [REFACTOR] コード品質の改善
- [ ] [REVIEW] フェーズ実装の簡易セルフレビューと修正
- [ ] [CHECK] lint/format/build の実行と確認
### フェーズ3: [機能名B] の実装
- [ ] [RED] [機能B]の動作テストを作成
- [ ] [GREEN] テストを通過させる最小限の実装
- [ ] [REFACTOR] コード品質の改善
- [ ] [REVIEW] フェーズ実装の簡易セルフレビューと修正
- [ ] [CHECK] lint/format/build の実行と確認
### フェーズN: 品質保証
- [ ] [STRUCTURAL] コード整理（動作変更なし）
- [ ] 全テスト実行と確認
- [ ] [REVIEW] フェーズ実装の簡易セルフレビューと修正
- [ ] [CHECK] lint/format/build の実行と確認
## 実装ノート
### MUSTルール遵守事項
- TDD: RED → GREEN → REFACTOR → REVIEW → CHECK サイクルを厳守
- REVIEW: 各フェーズ完了時に簡易セルフレビューを実施し、問題があればその場で修正
- CHECK: REVIEW後に lint/format/build を実行して最終確認
- Tidy First: 構造変更と動作変更を分離
- コミット: [BEHAVIORAL] または [STRUCTURAL] プレフィックス必須
- [BEHAVIORAL]: 動作を変更するコミット（機能追加、バグ修正、テスト追加）
- [STRUCTURAL]: 動作を変更しないコミット（リファクタリング、フォーマット、コメント追加）
### 参照ドキュメント
- 設計書: docs/DESIGN.md
- MUSTルール: 参照 shared/references/must-rules.md
ステップ4: ファイル出力
TODO.mdをdocsディレクトリに出力する：
Write(
file_path="docs/TODO.md",
content=todoContent
)
ステップ5: セルフレビュー（ぬけもれ解消まで繰り返し）
生成したTODO.mdをセルフレビューし、ぬけもれがなくなるまで修正を繰り返す。
レビュー観点
- 完全性: DESIGN.mdのすべての要件がタスク化されているか
- TDD準拠: 各タスクにRED/GREEN/REFACTOR/CHECKフェーズが明示されているか
- 依存関係: タスクの順序が依存関係を正しく反映しているか
- 粒度: 各タスクが適切なサイズ（1-4時間）か
- 明確性: タスク内容が具体的で実装者が迷わないか
レビュープロセス（必須）
CRITICAL: このプロセスは問題がゼロになるまで繰り返すこと。途中で打ち切らない。
1. DESIGN.mdを再度読み込む（最新の内容を確認）
2. TODO.mdを読み返す
3. DESIGN.mdの各セクションを1つずつ確認し、対応するタスクがあるか照合
4. 以下のチェックリストで問題を洗い出す
5. 問題があれば修正してファイルを更新
6. 問題がゼロになるまで1-5を繰り返す
ぬけもれ確認の具体的手順
-
DESIGN.mdのセクション別照合
- DESIGN.mdの各見出し（##, ###）をリストアップ
- 各見出しに対応するTODO.mdのタスクを特定
- 対応がないセクションを「ぬけもれ」として記録
-
機能要件の照合
- DESIGN.mdに記載された各機能を抽出
- TODO.mdに該当タスクがあるか確認
- ない場合はタスクを追加
-
非機能要件の照合
- テスト戦略、エラー戦略、パフォーマンス要件を確認
- 対応するタスクがあるか確認
- ない場合はタスクを追加
セルフレビューチェックリスト
設計との整合性（ぬけもれチェック重点項目）
- [ ] DESIGN.mdのすべてのセクションがタスク化されている
- [ ] DESIGN.mdのすべての機能がタスク化されている
- [ ] 非機能要件（テスト戦略、エラー戦略）が反映されている
- [ ] 依存関係の順序が正しい
- [ ] DESIGN.mdを再読み込みして、見落としがないか最終確認した
TDD準拠
- [ ] すべてのタスクにRED/GREEN/REFACTOR/REVIEW/CHECKが明示されている
- [ ] テストファーストの順序になっている
- [ ] リファクタリングタスクが適切に配置されている
- [ ] 各フェーズにREVIEW（レビュー＋自動修正）→ CHECK（最終確認）の順で配置されている
実装可能性
- [ ] 各タスクが1-4時間で完了可能な粒度
- [ ] タスク内容が具体的で曖昧さがない
- [ ] developingスキルで実装開始できる情報量がある
問題発見時の対応
問題を発見した場合：
- 問題箇所を特定
- 修正内容を決定
- TODO.mdを更新
- 必ず再度レビューを実行（問題がゼロになるまで終わらない）
レビュー完了条件
以下のすべてを満たすまでレビューを終了しない：
- [ ] DESIGN.mdの全セクションとTODO.mdの照合が完了
- [ ] ぬけもれゼロを確認
- [ ] 上記チェックリストの全項目がチェック済み
問題が解消しない場合（同じ問題が繰り返し発生する等）は、AskUserQuestionツールでユーザーに確認する。
ステップ6: 完了確認
セルフレビュー完了後、ユーザーに確認する：
AskUserQuestion({
questions: [
{
question: "TODO.mdを確認しました。このタスクリストで実装を開始しますか？",
header: "実装開始",
options: [
{ label: "開始する", description: "developingスキルで実装を開始" },
{ label: "却下", description: "コマンドを終了" }
],
multiSelect: false
}
]
})
ユーザーが修正内容を入力した場合（Other選択）：
- 入力された修正内容を反映してTODO.mdを更新
- 再度ユーザー確認を取得（このセクションに戻る）
- 承認されるまで繰り返す
タスク分解のパターン
パターン1: CRUD機能
### [エンティティ名] CRUD実装
- [ ] [RED] Create機能のテスト作成
- [ ] [GREEN] Create機能の実装
- [ ] [RED] Read機能のテスト作成
- [ ] [GREEN] Read機能の実装
- [ ] [RED] Update機能のテスト作成
- [ ] [GREEN] Update機能の実装
- [ ] [RED] Delete機能のテスト作成
- [ ] [GREEN] Delete機能の実装
- [ ] [REFACTOR] CRUD処理の共通化
- [ ] [REVIEW] フェーズ実装の簡易セルフレビューと修正
- [ ] [CHECK] lint/format/build の実行と確認
パターン2: API実装
### [エンドポイント名] API実装
- [ ] [RED] 正常系レスポンスのテスト作成
- [ ] [GREEN] 正常系の実装
- [ ] [RED] バリデーションエラーのテスト作成
- [ ] [GREEN] バリデーションの実装
- [ ] [RED] エラーハンドリングのテスト作成
- [ ] [GREEN] エラーハンドリングの実装
- [ ] [REFACTOR] レスポンス形式の統一
- [ ] [REVIEW] フェーズ実装の簡易セルフレビューと修正
- [ ] [CHECK] lint/format/build の実行と確認
パターン3: UIコンポーネント
### [コンポーネント名] 実装
- [ ] [RED] レンダリングテスト作成
- [ ] [GREEN] 基本UIの実装
- [ ] [RED] インタラクションテスト作成
- [ ] [GREEN] イベントハンドラの実装
- [ ] [RED] エッジケーステスト作成
- [ ] [GREEN] エッジケース対応
- [ ] [REFACTOR] スタイルとロジックの分離
- [ ] [REVIEW] フェーズ実装の簡易セルフレビューと修正
- [ ] [CHECK] lint/format/build の実行と確認
Related Skills
skanehira/workflow-create-draft-pr
tools
VerifiedTrustedCommunity
ローカルのコミット履歴と差分からDraft PRを作成する。ブランチ未作成・コミット未作成の状態でも、必要に応じてブランチ作成とコミットを行ってからPRを作成する。`.github/` にPRテンプレートがあれば内容を埋めて、なければ作業内容から本文を生成し、`AskUserQuestion`で作成可否を確認してから `gh pr create --draft` を実行する。「PRを出したい」「draft PRを作成」「プルリクを作って」「PR本文を生成」などのリクエストで起動。
86SKILL.mdUpdated May 21, 2026
skanehira/workflow-debate
tools
VerifiedTrustedCommunity
複数サブエージェントに異なる立場を与えて議論を反復し、相違が収束するまで議題を検証して結論を提示する。設計妥当性検証・実装方針比較・原因分析のセカンドオピニオン・アイデアの壁打ちに使用。「議論したい」「壁打ちしたい」「セカンドオピニオン」「複数視点で検証したい」などで起動。
86SKILL.mdUpdated May 19, 2026
skanehira/workflow-commit
tools
VerifiedTrustedCommunity
変更内容を分析し、Conventional Commit形式でコミットする (pushはユーザが手動)
86SKILL.mdUpdated May 19, 2026
skanehira/demo-site-builder
development
VerifiedTrustedCommunity
React 19 + Vite+ (`vp`) + TypeScript + Tailwind CSS v4 + React Router v7 (HashRouter) でモバイル向け静的SPAデモサイトをTDDで構築し、Cloudflare Workers (Static Assets) へ自動デプロイするまでの標準ワークフローを提供する。テンプレートリポジトリ `skanehira/demo-site-template` を `gh repo create --template` で clone することで scaffold を省略する。`localStorage` でフロントエンドのみ完結する"フロントのみ完結デモ"に特化。デザインコンセプトの確立には `frontend-design` スキルを呼び出して連携する。起動トリガー：「デモサイトを作りたい」「モバイル向け静的デモ」「SPAを作ってCloudflareにデプロイ」「静的プロトタイプを公開」「localStorage でフロントだけ完結」。ユースケース：(1)クライアント提案用のUI/UXたたき台、(2)新機能のプロトタイプ、(3)モバイル向けランディング。ツールチェーンは Vite+ (`vp`) で統合（内部 PM は pnpm）。
86SKILL.mdUpdated Apr 29, 2026