jpskill.com
📦 その他 コミュニティ

devdocs-dev-tasks

システム設計を、開発者が実行可能な具体的なタスクに細分化し、スプリント計画やタスクリスト作成を支援することで、開発業務を効率的に進めるSkill。

📜 元の英語説明(参考)

Break down system design into executable development tasks. Use when users need task breakdown, sprint planning, or development task lists. Triggers on keywords like "dev tasks", "task breakdown", "sprint planning", "implementation tasks".

🇯🇵 日本人クリエイター向け解説

一言でいうと

システム設計を、開発者が実行可能な具体的なタスクに細分化し、スプリント計画やタスクリスト作成を支援することで、開発業務を効率的に進めるSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux 
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o devdocs-dev-tasks.zip https://jpskill.com/download/8769.zip && unzip -o devdocs-dev-tasks.zip && rm devdocs-dev-tasks.zip
🪟 Windows (PowerShell) 
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/8769.zip -OutFile "$d\devdocs-dev-tasks.zip"; Expand-Archive "$d\devdocs-dev-tasks.zip" -DestinationPath $d -Force; ri "$d\devdocs-dev-tasks.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して devdocs-dev-tasks.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → devdocs-dev-tasks フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動
⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

開発タスク

システム設計を実行可能で追跡可能な開発タスクに分解します。

言語規則

  • 中国語と英語での質問をサポート
  • 中国語での統一された回答
  • 中国語を使用してドキュメントを生成

トリガー条件

  • ユーザーがシステム設計とテストケースを完了している
  • ユーザーが開発タスクの分割を要求している
  • ユーザーがイテレーション/Sprint計画を必要としている
  • /devdocs-feature、/devdocs-bugfix、/devdocs-insights からの増分要求

前提条件

  • 要求ドキュメント：docs/devdocs/01-requirements.md
  • システム設計ドキュメント：docs/devdocs/02-system-design.md
  • テストケースドキュメント：docs/devdocs/03-test-cases.md
  • 存在しない場合は、まず前提段階を実行することをお勧めします

ワークフロー

  1. ドキュメントの読み込み：すべての前提段階ドキュメントをロードします
  2. コンポーネントの識別：システムモジュールをタスクにマッピングします
  3. 依存関係の定義：タスクの実行順序を確立します
  4. 範囲の評価：タスクの粒度が適切であることを確認します
  5. タスクリストの作成：構造化されたタスクドキュメントを生成します
  6. ユーザーの確認：承認を得ます
  7. TodoWrite へのロード：オプション、タスクを追跡リストに追加します

出力ファイル

メインファイル：docs/devdocs/04-dev-tasks.md

ドキュメント分割規則

以下の条件が満たされる場合、ドキュメントを分割する必要があります。

  • タスク数が 20 個 を超える
  • ドキュメントが 300 行 を超える
  • 複数の独立したモジュールが関与する

分割方法：

docs/devdocs/
├── 04-dev-tasks.md              # メインドキュメント：タスクの概要、依存関係図、実行チェックリスト
├── 04-dev-tasks-infra.md        # インフラストラクチャタスク
├── 04-dev-tasks-core.md         # コアロジックタスク
├── 04-dev-tasks-api.md          # インターフェース層タスク
└── 04-dev-tasks-test.md         # テストタスク

タスクのアーカイブ

完了したタスクが多すぎる場合は、04-dev-tasks-archive.md にアーカイブします。

詳細は archive-rules.md を参照してください。

タスク設計原則

各タスクは TAR 原則 を満たす必要があります。

原則 説明 必須内容
テスト可能 (Testable) 自動または手動テストで検証可能 テスト方法と期待される結果
受入可能 (Acceptable) 明確な受入基準がある 具体的な、定量化可能な完了基準
レビュー可能 (Reviewable) 独立してコードレビューを実行可能 Review の要点

タスクの階層化

タスクの種類に応じて階層化し、TDD モードを決定します。

層級 TDD モード 説明
コアロジック (Service/Domain) 🔴 必須 テスト先行
インターフェース層 (Controller/API) 🟡 推奨 テスト先行を推奨
UI 層 (Component/View) 🟢 オプション 実装後の追加が可能
インフラストラクチャ (DB/Config) ⚪ 適用外 統合テストで検証

制約

基本制約

  • [ ] 単一のタスクは 4 時間以内に完了できる必要がある
  • [ ] タスクの依存関係を指定する必要がある
  • [ ] 依存関係に従ってソートする必要があり、循環依存関係があってはならない
  • [ ] ファイルパスは具体的にする必要があり、「関連ファイル」と記述してはならない
  • [ ] 依存関係図を提供する必要がある
  • [ ] 優先度：P0（ブロック）、P1（重要）、P2（マイナー）
  • [ ] タスク番号の形式：T-XX（連番）

要求追跡制約

  • [ ] 各タスクは、機能ポイント (F-XXX) と受入基準 (AC-XXX) に関連付ける必要がある
  • [ ] 各タスクは、テストケース (UT/IT/E2E-XXX) に関連付ける必要がある
  • [ ] テストケースは 03-test-*.md ドキュメントから取得

TAR 原則制約

  • [ ] 各タスクには、テスト方法（検証方法）を含める必要がある
  • [ ] 各タスクには、受入基準（定量化可能な完了基準）を含める必要がある
  • [ ] 各タスクには、Review の要点（コードレビューの注目点）を含める必要がある
  • [ ] テスト方法は実行可能である必要がある（曖昧な記述は不可）
  • [ ] 受入基準は定量化可能である必要がある
  • [ ] Review の要点はタスクの種類に特化している必要がある

階層制約

  • [ ] コアロジックタスクは 🔴 必須 TDD とマークする必要がある
  • [ ] インターフェース層タスクは 🟡 推奨 TDD とマークする
  • [ ] UI 層タスクは 🟢 オプション TDD とマークする
  • [ ] インフラストラクチャタスクは ⚪ 適用外 TDD とマークする

実行制約

  • [ ] タスクの実行には /devdocs-dev-workflow を使用する必要がある
  • [ ] dev-workflow をスキップして直接コードを記述することは禁止されています（追跡が無効になるため）
  • [ ] タスク完了後、/devdocs-sync --trace を実行する必要があります

増分タスク管理

来源

来源 Skill 触发场景 操作
/devdocs-feature 新規機能要求 リストにタスクを追加
/devdocs-bugfix バグ修正要求 優先度の高いタスクを挿入
/devdocs-insights 改善提案の確認 リストにタスクを追加

増分操作

  • 新規タスク：タスクリストの末尾に追加し、番号を振り直します
  • タスクの挿入：優先度の高いタスクを適切な位置に挿入します
  • 依存関係の更新：影響を受けるタスクの依存関係を調整します
  • 状態の更新：タスクを完了/進行中としてマークします

完了後の操作

ユーザーがタスクドキュメントを確認した後：

  1. ユーザーに開発を開始するかどうかを尋ねます
  2. 開始する場合は、TodoWrite を使用してすべてのタスクを追跡リストに追加します
  3. 最初のタスク（T-01）から開始することをお勧めします
  4. タスクの実行時には /devdocs-dev-workflow を使用する必要があります

重要：dev-workflow を使用せずに直接コードを記述すると、コードに @satisfies/@verifies アノテーションが欠落し、 /devdocs-sync --trace が自動的に追跡できなくなり、ドキュメント↔コードの閉ループが破壊されます。

参考資料

連携 Skill

场景 Skill
開発タスクの実行 /devdocs-dev-workflow
ドキュメントの状態の同期 /devdocs-sync
新規機能要求 /devdocs-feature
バグの修正 /devdocs-bugfix
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

开发任务

将系统设计分解为可执行、可追踪的开发任务。

语言规则

  • 支持中英文提问
  • 统一中文回复
  • 使用中文生成文档

触发条件

  • 用户已完成系统设计和测试用例
  • 用户要求拆分开发任务
  • 用户需要迭代/Sprint 规划
  • 来自 /devdocs-feature、/devdocs-bugfix、/devdocs-insights 的增量需求

前置条件

  • 需求文档：docs/devdocs/01-requirements.md
  • 系统设计文档：docs/devdocs/02-system-design.md
  • 测试用例文档：docs/devdocs/03-test-cases.md
  • 如不存在，建议先运行前置阶段

工作流程

  1. 读取文档：加载所有前置阶段文档
  2. 识别组件：将系统模块映射为任务
  3. 定义依赖：建立任务执行顺序
  4. 评估范围：确保任务粒度合适
  5. 创建任务列表：生成结构化任务文档
  6. 用户确认：获得批准
  7. 加载到 TodoWrite：可选，添加任务到追踪列表

输出文件

主文件：docs/devdocs/04-dev-tasks.md

文档拆分规则

当满足以下条件时，应拆分文档：

  • 任务数量超过 20 个
  • 文档超过 300 行
  • 涉及多个独立模块

拆分方式：

docs/devdocs/
├── 04-dev-tasks.md              # 主文档：任务概览、依赖图、执行检查清单
├── 04-dev-tasks-infra.md        # 基础设施任务
├── 04-dev-tasks-core.md         # 核心逻辑任务
├── 04-dev-tasks-api.md          # 接口层任务
└── 04-dev-tasks-test.md         # 测试任务

任务归档

已完成任务过多时归档到 04-dev-tasks-archive.md。

详见 archive-rules.md

任务设计原则

每个任务必须满足 TAR 原则：

原则 说明 必需内容
可测试 (Testable) 可通过自动化或手动测试验证 测试方法和预期结果
可验收 (Acceptable) 有明确的验收标准 具体、可量化的完成标准
可审查 (Reviewable) 可独立进行代码审查 Review 要点

任务分层

根据任务类型分层，决定 TDD 模式：

层级 TDD 模式 说明
核心逻辑 (Service/Domain) 🔴 强制 测试先行
接口层 (Controller/API) 🟡 推荐 建议测试先行
UI 层 (Component/View) 🟢 可选 可实现后补
基础设施 (DB/Config) ⚪ 不适用 集成测试验证

约束

基础约束

  • [ ] 单个任务必须在 4 小时内可完成
  • [ ] 必须指定任务依赖
  • [ ] 必须按依赖排序，不能有循环依赖
  • [ ] 文件路径必须具体，不能写"相关文件"
  • [ ] 必须提供依赖关系图
  • [ ] 优先级：P0（阻塞）、P1（重要）、P2（次要）
  • [ ] 任务编号格式：T-XX（顺序编号）

需求追溯约束

  • [ ] 每个任务必须关联功能点 (F-XXX) 和验收标准 (AC-XXX)
  • [ ] 每个任务必须关联测试用例 (UT/IT/E2E-XXX)
  • [ ] 测试用例来自 03-test-*.md 文档

TAR 原则约束

  • [ ] 每个任务必须包含测试方法（如何验证）
  • [ ] 每个任务必须包含验收标准（可量化的完成标准）
  • [ ] 每个任务必须包含 Review 要点（代码审查关注点）
  • [ ] 测试方法必须可执行（不能是模糊描述）
  • [ ] 验收标准必须可量化
  • [ ] Review 要点必须针对任务类型

分层约束

  • [ ] 核心逻辑任务必须标记 🔴 强制 TDD
  • [ ] 接口层任务标记 🟡 推荐 TDD
  • [ ] UI 层任务标记 🟢 可选 TDD
  • [ ] 基础设施任务标记 ⚪ 不适用 TDD

执行约束

  • [ ] 任务执行必须使用 /devdocs-dev-workflow
  • [ ] 禁止跳过 dev-workflow 直接写代码（会导致追溯失效）
  • [ ] 任务完成后必须执行 /devdocs-sync --trace

增量任务管理

来源

来源 Skill 触发场景 操作
/devdocs-feature 新增功能需求 追加任务到列表
/devdocs-bugfix Bug 修复需求 插入高优先级任务
/devdocs-insights 改进建议确认 追加任务到列表

增量操作

  • 新增任务：追加到任务列表末尾，重新编号
  • 插入任务：高优先级任务插入合适位置
  • 更新依赖：调整受影响任务的依赖关系
  • 更新状态：标记任务完成/进行中

完成后操作

用户确认任务文档后：

  1. 询问用户是否开始开发
  2. 如是，使用 TodoWrite 添加所有任务到追踪列表
  3. 建议从第一个任务（T-01）开始
  4. 执行任务时必须使用 /devdocs-dev-workflow

重要：直接写代码而不使用 dev-workflow 会导致代码缺失 @satisfies/@verifies 标注， 使 /devdocs-sync --trace 无法自动追溯，破坏文档↔代码的闭环。

参考资料

协作 Skill

场景 Skill
执行开发任务 /devdocs-dev-workflow
同步文档状态 /devdocs-sync
新增功能需求 /devdocs-feature
修复 Bug /devdocs-bugfix