devflow
End-to-end agent development process. Use when coordinating work, dispatching agents, or reviewing PRs.
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o devflow.zip https://jpskill.com/download/18233.zip && unzip -o devflow.zip && rm devflow.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/18233.zip -OutFile "$d\devflow.zip"; Expand-Archive "$d\devflow.zip" -DestinationPath $d -Force; ri "$d\devflow.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
devflow.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
devflowフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
DEVFLOW: エージェント開発
連携されたマルチエージェント開発のための5段階ワークフローです。
⚠️ 必須: 100% の Issue/タスク網羅率
すべての段階で、元の Issue/タスクの要件が 100% 満たされていることを検証する必要があります。
- フェーズ 1: 元の Issue からすべての要件を抽出
- フェーズ 2: 完全な要件リストとともにエージェントを派遣
- フェーズ 3: 品質チェックの前に、レビューで 100% の網羅率を検証する必要あり
- フェーズ 5: 元の要件が 100% 実装されるまでマージできません
不完全な実装 = 返送、続行しないでください。
フェーズ 1: Oracle による評価
- Oracle を使用してコードベースの状態を評価
- 完了した作業、残りの作業、依存関係を特定
- 元の Issue/タスクからすべての要件を抽出 (
gh issue view <number>) - すべての要件が網羅されるように、並列化可能なタスクに分割
フェーズ 2: 並列実装
Docker エージェントを派遣:
- リポジトリをクローンし、ローカルでフォーマット (
cargo +nightly fmt) feat/nameまたはfix/nameとしてブランチを作成- 本文に
Closes #Xを含めて、正しいベースブランチに PR をオープン - 既存のブランチには絶対にプッシュしない
PR には必ず Issue へのリンクを含める必要があります:
- 対応する Issue に対して
Closes #XまたはFixes #X - PR 本文に「Related Issues」セクション
- 検証:
gh pr view --json closingIssuesReferences
フェーズ 3: 超重要なレビュー
CI がパスした後、6 パスのレビューを実行:
| パス | 焦点 |
|---|---|
| 0.5 | 100% の Issue/タスク網羅率の検証 (最初に必須) |
| 1 | ランタイム/コンパイルエラー |
| 2 | パターン、インポート、デッドコード |
| 3 | 抽象化、ハードコードされた値 |
| 4 | 環境互換性 |
| 5 | 検証コマンド |
| 6 | コンテキスト合成 |
重要: パス 0.5 (Issue 網羅率) は、続行する前にパスする必要があります。網羅率が 100% 未満の場合は、すぐにエージェントを返送してください。
レビューのエスカレーション
- 最初にコーディネーターにエスカレーション — アーキテクチャ/トレードオフに関する質問
- コーディネーターが適切な判断を下す — コードベースのパターンに基づく
- 必要な場合は人にエスカレーション — 重大なリスクまたは不確実性
レビューのタイミング
- PR 前レビュー: エージェント作業後、PR 作成前
- PR 後レビュー: PR 作成後、マージ前
フェーズ 4: 人間の承認
一時停止: PR の承認、人間の判断を必要とする複雑な決定。
続行: ワークストリームのセットアップ、エージェントの派遣、CI の修正、レビューのフィードバック。
フェーズ 4.5: 最終的な網羅率ゲート
必須: マージ前に、行ごとの要件検証を実行します。
# Issue からすべての要件を抽出
gh issue view <number> --json body --jq '.body' | grep -E "^\- \["
gh issue view <number>
検証テーブルを作成:
| Requirement | Status | Evidence |
|-------------|--------|----------|
| [from issue] | ✅ | `file:line` |
| [from issue] | ❌ MISSING | Not in PR |
| [from issue] | ⚠️ PARTIAL | [what's missing] |
**正直な評価**: X% (Y of Z requirements)
| Coverage | Action |
|---|---|
| 100% | ✅ マージに進む |
| < 100% | ❌ 行ごとのギャップリストとともにフェーズ 2 に戻る |
フェーズ 5: マージと続行
マージ前に、Issue へのリンクを確認:
gh pr view <NUMBER> --json closingIssuesReferences
# リンクされた Issue が表示される必要があります - 空の場合は、修正のために返送
依存関係の順に PR をマージします。最終的な網羅率ゲートがパスし、Issue がリンクされた後のみ。 Issue はマージ時に自動的にクローズされます。
レビューと PR における Mermaid ダイアグラム
変更がフロー、状態、またはアーキテクチャに関わる場合、レビューと PR には Mermaid ダイアグラムを含める必要があります。
| 変更の種類 | ダイアグラム |
|---|---|
| フローの変更 | flowchart before/after |
| API の変更 | sequenceDiagram |
| 状態の処理 | stateDiagram-v2 |
| アーキテクチャの変更 | サブグラフ付きの flowchart |
レビューの例:
### 新しいトークンフロー
```mermaid
sequenceDiagram
Client->>Server: Request (expired token)
Server-->>Client: 401 + refresh
Client->>Server: New request
```
アンチパターン
| 間違い | 正しい |
|---|---|
| 網羅率が不完全な状態でマージ | 最初に Issue の要件を 100% 実装 |
| Issue へのリンクがない PR | すべての PR に、関連する Issue に対して Closes #X がある |
| ブランチへのプッシュ | フィーチャーブランチ + PR |
| チェックボックスレビュー | 6 パス分析 (網羅率チェックから開始) |
| コーディネーターが実装 | エージェントを派遣 |
| すべてのステップで一時停止 | PR の決定のために一時停止 |
| CI をスキップ | CI を待つ |
| 「コア要件は完了」 | すべての要件が完了、例外なし |
| マージしてから Issue を手動でクローズ | マージ時に自動クローズするために Closes #X を使用 |
| テキストのみの複雑な変更 | フロー/状態の Mermaid ダイアグラム |
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
DEVFLOW: Agent Development
5-phase workflow for coordinated multi-agent development.
⚠️ MANDATORY: 100% Issue/Task Coverage
Every phase must verify that 100% of original issue/task requirements are being addressed.
- Phase 1: Extract ALL requirements from original issue
- Phase 2: Dispatch agents with complete requirement lists
- Phase 3: Review must verify 100% coverage before quality check
- Phase 5: Cannot merge until 100% of original requirements implemented
Incomplete implementations = SEND BACK, do not proceed.
Phase 1: Oracle Assessment
- Assess codebase state with Oracle
- Identify completed work, remaining work, dependencies
- Extract ALL requirements from original issue/task (
gh issue view <number>) - Break down into parallelizable tasks ensuring ALL requirements are covered
Phase 2: Parallel Implementation
Dispatch Docker agents:
- Clone repo, format locally (
cargo +nightly fmt) - Branch as
feat/nameorfix/name - Open PR to correct base branch with
Closes #Xin body - Never push to existing branches
PR MUST include issue links:
Closes #XorFixes #Xfor issues being addressed- "Related Issues" section in PR body
- Verify:
gh pr view --json closingIssuesReferences
Phase 3: Ultra-Critical Review
After CI passes, run 6-pass review:
| Pass | Focus |
|---|---|
| 0.5 | 100% issue/task coverage verification (MANDATORY FIRST) |
| 1 | Runtime/compile failures |
| 2 | Patterns, imports, dead code |
| 3 | Abstractions, hard-coded values |
| 4 | Environment compatibility |
| 5 | Verification commands |
| 6 | Context synthesis |
CRITICAL: Pass 0.5 (issue coverage) MUST pass before proceeding. If coverage < 100%, send agent back immediately.
Review Escalation
- Escalate to coordinator first — Architecture/tradeoff questions
- Coordinator applies good judgment — Based on codebase patterns
- Escalate to human when needed — Significant risk or uncertainty
Review Timing
- Pre-PR review: After agent work, before PR creation
- Post-PR review: After PR creation, before merge
Phase 4: Human Approval
Pause for: PR approval, complex decisions requiring human judgment.
Continue through: workstream setup, agent dispatch, CI fixes, review feedback.
Phase 4.5: FINAL COVERAGE GATE
MANDATORY: Before any merge, perform LINE-BY-LINE requirement verification.
# Extract ALL requirements from issue
gh issue view <number> --json body --jq '.body' | grep -E "^\- \["
gh issue view <number>
Create verification table:
| Requirement | Status | Evidence |
|-------------|--------|----------|
| [from issue] | ✅ | `file:line` |
| [from issue] | ❌ MISSING | Not in PR |
| [from issue] | ⚠️ PARTIAL | [what's missing] |
**Honest Assessment**: X% (Y of Z requirements)
| Coverage | Action |
|---|---|
| 100% | ✅ Proceed to merge |
| < 100% | ❌ Return to Phase 2 with line-by-line gap list |
Phase 5: Merge & Continue
Before merge, verify issue linking:
gh pr view <NUMBER> --json closingIssuesReferences
# Must show linked issues - if empty, send back to fix
Merge PRs in dependency order. Only after Final Coverage Gate passes AND issues are linked. Issues auto-close on merge.
Mermaid Diagrams in Reviews and PRs
Reviews and PRs SHOULD include Mermaid diagrams when changes involve flows, states, or architecture.
| Change Type | Diagram |
|---|---|
| Flow change | flowchart before/after |
| API modification | sequenceDiagram |
| State handling | stateDiagram-v2 |
| Architecture change | flowchart with subgraphs |
Example in review:
### New Token Flow
```mermaid
sequenceDiagram
Client->>Server: Request (expired token)
Server-->>Client: 401 + refresh
Client->>Server: New request
```
Anti-Patterns
| Wrong | Right |
|---|---|
| Merge with incomplete coverage | 100% of issue requirements implemented first |
| PR without issue links | Every PR has Closes #X for related issues |
| Push to branch | Feature branch + PR |
| Checkbox review | 6-pass analysis (starting with coverage check) |
| Coordinator implements | Dispatch agents |
| Pause every step | Pause for PR decisions |
| Skip CI | Wait for CI |
| "Core requirements done" | ALL requirements done, no exceptions |
| Merge then close issue manually | Use Closes #X for auto-close on merge |
| Text-only complex changes | Mermaid diagrams for flows/states |