Communitygithub.com

wicttor/pwrl

計画→作業→レビュー→学習。最小限の規律あるエージェント開発フレームワーク。

pwrl とは？

PWRL Plan（Pure Skill Orchestrator）は、AIエージェント（Claude Code, Cursor, Codexなど）向けの決定的なパイプライン型計画立案フレームワークです。スコープ設定（pwrl-plan-scope）→リサーチ（pwrl-plan-research）→設計（pwrl-plan-design）→生成（pwrl-plan-generate）の4フェーズを順次実行し、実装可能な計画書を `docs/plans/` に出力します。各フェーズは独立したマイクロスキルとして実装されており、エージェントの分岐やフォールバックパスは一切存在しません。計画の複雑さに応じてFAST/STANDARD/DEEPの3つのテンプレートが自動選択され、学習履歴との統合や依存関係のトポロジカルソート、循環依存の検出といった高度な機能を備えています。エラーハンドリングも各フェーズで明示的に行われ、ユーザーに明確な回復手段を提供します。

対応✓Claude Code~Codex CLI~Cursor✓Antigravity
npx skills add wicttor/pwrl
オリジナルを見る→すべてのスキルを見る

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

ドキュメント

PWRL 計画 — 純粋スキルオーケストレーター

実行に引き渡せる永続的な実装計画を作成します。スコープ → リサーチ → 設計 → 生成という決定的なマイクロスキルパイプラインをオーケストレーションします。エージェント依存やフォールバックパスはありません。

目的

計画は実行前に決定事項、構造、アプローチを捉えます。これにより以下が可能になります：

  • 明確なスコープと成功基準
  • 特定されたリスクと依存関係
  • 受け入れ基準を伴う具体的な実装ユニット
  • 関連する学習を通じた知識の再利用
  • 作業が脱線しないという確信

コアワークフロー：4フェーズパイプライン

入力（タスク説明）
  ↓
フェーズ1：スコープ（pwrl-plan-scope）
  → コンテキスト収集、ドメイン検証、要件のブートストラップ
  → 出力：スコープコンテキスト成果物
  ↓
フェーズ2：リサーチ（pwrl-plan-research）
  → パターン発見、リスク特定、外部調査の推奨
  → 出力：調査結果成果物
  ↓
フェーズ3：設計（pwrl-plan-design）
  → ユニット分解、依存関係マッピング、複雑性評価
  → 出力：ユニット分解を含む設計成果物
  ↓
フェーズ4：生成（pwrl-plan-generate）
  → テンプレート選択、計画レンダリング、学習埋め込み、docs/plans/に保存
  → 出力：ファイルに保存された最終計画書
  ↓
出力（実行準備完了の計画ファイル）

フェーズ詳細

フェーズ1：スコープ（pwrl-plan-scope）

目的: 計画ワークフローのエントリポイント。コンテキストを収集し、既存の計画と学習を確認し、ドメインを検証して、スコープコンテキストオブジェクトを返します。

マイクロスキル: pwrl-plan-scope

入力:

  • ユーザーがタスク説明、要件ドキュメント、または目標を提供
  • 空の入力はユーザーに「何を計画しますか？」と促す

処理:

  1. docs/plans/ 内の既存計画を確認。再開/レビュー/アーカイブ/削除/新規を提案
  2. ドメインを検証（ソフトウェア vs 非ソフトウェア）
  3. 問題フレーム、意図する動作、成功基準をブートストラップ
  4. docs/learnings/INDEX.md で関連する学習を検索
  5. docs/requirements/ と docs/brainstorms/ で一致するドキュメントを検索
  6. コンテキストをユーザーと確認
  7. 対話モードを質問:
    • 詳細: 各フェーズでステップバイステップの対話（レビュー、確認、調整）
    • Yolo: フェーズ1からフェーズ4まで完全自動化、最終確認のみ
  8. interaction_mode を含むスコープ成果物を生成

出力: スコープコンテキスト成果物（以下を含む）:

  • 問題フレーム、意図する動作、成功基準
  • 関連する学習（HIGH関連性）
  • 特定された学習ギャップ
  • 見つかった要件
  • interaction_mode（詳細 または yolo）

参照: pwrl-plan-scope/SKILL.md 詳細ワークフロー

フェーズ2：リサーチ（pwrl-plan-research）

目的: ローカルパターン、テクノロジースタック、リスクの高い領域を発見します。必要に応じて外部調査を推奨します。

マイクロスキル: pwrl-plan-research

入力: フェーズ1からのスコープコンテキスト成果物

処理:

  1. package.json、Dockerfile、コードベース構造からテクノロジースタックを検出
  2. ローカルパターン（アーキテクチャ、非同期スタイル、テスト、構成）を発見
  3. リスクの高い領域（セキュリティ、パフォーマンス、移行、分散システム、コンプライアンス）を特定
  4. リスクの高い領域に対する外部調査を推奨（オプション）
  5. 関連する学習からの洞察を統合
  6. 調査結果を編集

出力: 調査成果物（以下を含む）:

  • テクノロジースタック検出
  • 特定されたローカルパターン
  • 推奨事項を含むリスク領域
  • 外部調査結果（実行された場合）
  • 学習統合メモ

参照: pwrl-plan-research/SKILL.md 詳細ワークフロー

フェーズ3：設計（pwrl-plan-design）

目的: 作業を実装ユニットに分解し、依存関係とリスクを特定し、複雑性を評価します。

マイクロスキル: pwrl-plan-design

入力: スコープコンテキスト + 調査結果

処理:

  1. 成功基準とリスク領域から作業ユニットを特定
  2. ユニット間の依存関係をマッピング（トポロジカルソート）
  3. 循環依存関係を検出。リファクタリングを促す
  4. リスク軽減ユニットを作成
  5. 複雑なワークフローの場合、Mermaid図を生成（5ユニット以上）
  6. 複雑性を評価（LOW/MEDIUM/HIGH）
  7. 工数を推定
  8. 分解内容をユーザーと確認

出力: 設計成果物（以下を含む）:

  • テストシナリオと受け入れ基準を含む実装ユニット（U1、U2、...、UX）
  • 依存関係グラフとトポロジカル順序
  • リスク軽減策
  • Mermaid図（複雑な場合）
  • 複雑性評価と工数見積もり

参照: pwrl-plan-design/SKILL.md 詳細ワークフロー

フェーズ4：生成（pwrl-plan-generate）

目的: テンプレート（Fast/Standard/Deep）を選択し、テンプレートを使用して計画をレンダリングし、学習を埋め込み、docs/plans/ に保存します。

マイクロスキル: pwrl-plan-generate

入力: 設計成果物（フェーズ3から） + スコープ成果物（フェーズ1から）

処理:

  1. 複雑性/ユニット数/工数に基づいてテンプレートを自動選択。曖昧な場合はユーザーに確認
    • FAST: 複雑性LOW、1～3ユニット、5時間未満
    • STANDARD: 複雑性MEDIUM、4～8ユニット、5～20時間
    • DEEP: 複雑性HIGH、9ユニット以上、20時間以上
  2. テンプレート固有の形式で計画をレンダリング
  3. スコープから上位3～5件のHIGH関連性学習を埋め込み
  4. ユニークなファイル名を生成：YYYY-MM-DD-NNN-<slug>.md
  5. ファイル名の衝突を処理（シーケンスを増分または既存を更新）
  6. 計画を docs/plans/ に保存

出力: ファイルに保存された計画書（以下を含む）:

  • 問題とスコープ
  • 成功基準
  • 実装ユニット（テンプレート固有の詳細レベル）
  • リスク分析（STANDARD/DEEP）
  • 関連する学習（STANDARD/DEEP）
  • 学習ギャップ（DEEP）
  • ロールアウトメモ（STANDARD/DEEP）

参照: pwrl-plan-generate/SKILL.md 詳細ワークフロー

計画テンプレート

テンプレート最適な用途ファイル数リスク時間
FASTバグ修正、小さな調整1～3LOW5～15分
STANDARDほとんどの機能4～8MED30～45分
DEEPアーキテクチャ、セキュリティ、移行9以上HIGH1～2時間

参照 references/planning-tiers.md 完全なテンプレート判断基準とテンプレート例。

コア原則

  • 決定的パイプライン: フェーズは常に順番に実行：スコープ → リサーチ → 設計 → 生成（分岐なし、フォールバックなし）
  • 決定事項に集中: アプローチ、構造、リスク、順序を捉える（コードのシミュレーションではない）
  • 適切なサイズ: 小さなタスク → 短い計画。複雑な作業 → より構造化
  • 計画と実行を分離: 計画中に実装をシミュレートしない
  • 具体的に: 具体的なファイル、コンポーネント、依存関係を使用する
  • 移植性を維持: リポジトリ相対パスのみを使用する
  • 透過的な成果物: 各フェーズは次のフェーズのために明示的な出力成果物を生成する

エラーハンドリングと復旧

哲学: 暗黙の失敗ではなく、明示的に失敗する。各フェーズには復旧提案を含む明確なエラーハンドリングがあります。

フェーズ1（スコープ）エラー

  • 空の入力: タスクの説明をユーザーに促し、再試行
  • 非ソフトウェアドメイン: エラーを返し、代替ツールを提案
  • 曖昧な入力: 明確化の質問をし、ユーザーの応答でブートストラップ
  • 学習/要件なし: 続行（エラーではない）

復旧: ユーザーは再試行、明確化の提供、または中止が可能

フェーズ2（リサーチ）エラー

  • コードベース分析の失敗: 最小限のテクノロジースタック情報で続行
  • リスクの高い領域の特定: 外部調査を推奨。ユーザーは承認またはスキップ可能

復旧: ユーザーは調査の承認、スキップ、または手動調査が可能

フェーズ3（設計）エラー

  • 循環依存関係の検出: サイクルパスを報告。ユーザーにリファクタリングを促す
  • ユニット数が多すぎる（15以上）: 複雑性について警告。統合を提案
  • 詳細不足: テストシナリオの追加またはユニット分割を促す

復旧: ユーザーはリファクタリング、統合、または認識した上で続行が可能

フェーズ4（生成）エラー

  • ファイル名の衝突: オプションを提供：更新、増分、またはキャンセル
  • テンプレート選択の曖昧さ: ユーザーにテンプレート選択を促す
  • ファイル書き込み失敗: 権限/ディレクトリを確認。再試行または手動保存を提案

復旧: ユーザーはアクションを選択するか、手動で保存可能

主要な出力

各計画には以下が含まれます（テンプレート依存）:

  • 問題とスコープ: 明確な問題フレームと意図する動作
  • 成功基準: 完了のための1～3つの具体的な条件
  • 実装ユニット: 依存関係、ファイル、アプローチ、受け入れ基準を持つ名前付きU-ID
  • 関連する学習: 適用性メモ付きのリンクされた学習ファイル（STANDARD/DEEP）
  • 学習ギャップ: 実装後のドキュメントが必要な領域（DEEP）
  • テンプレート固有のセクション: リスク分析、代替案、ロールアウトメモ（STANDARD/DEEP）

対話方法

  • すべての決定にプラットフォームの ask_user_questions 拡張を使用
  • 一度に1つの質問をする
  • 可能な場合は選択式質問を使用
  • 入力が空の場合は、「何を計画しますか？タスクまたはプロジェクトを説明してください。」と質問する
  • エラー発生時には明確な復旧提案を提供する

アーキテクチャ：エージェントルーティングなし

以前のバージョンとの違い:

以前: スキルがエージェントの有無を検出し、エージェントに委譲するか、モノリシックなフォールバックを実行していた（2つのコードパス）

以後: スキルはマイクロスキルを直接順次呼び出す。単一の決定的パイプライン、分岐なし：

pwrl-plan orchestrator
├── 1. pwrl-plan-scope を呼び出し → スコープ成果物を取得
├── 2. pwrl-plan-research を呼び出し → 調査成果物を取得
├── 3. pwrl-plan-design を呼び出し → 設計成果物を取得
└── 4. pwrl-plan-generate を呼び出し → 計画ファイルを保存

利点:

  • ✅ 理解が容易（単一コードパス）
  • ✅ テストが容易（分岐ロジックなし）
  • ✅ 保守性が高い（マイクロスキルが独立してテスト可能）
  • ✅ 構成性が高い（マイクロスキルが他のワークフローで再利用可能）
  • ✅ エラーハンドリングが優れている（各フェーズで明示的）

マイクロスキルリファレンス

関連ドキュメント

テストと検証

包括的なテストカバレッジ:

  • pwrl-plan-scope 向け30以上のテスト（U1.1）
  • pwrl-plan-research 向け25以上のテスト（U1.2）
  • pwrl-plan-design 向け35以上のテスト（U1.3）
  • pwrl-plan-generate 向け30以上のテスト（U1.4）
  • 完全オーケストレーションパイプライン向け30以上の統合テスト

後方互換性:

  • 以前のバージョンと同じ入出力動作
  • 既存の計画は正常に生成される
  • ユーザー向けの破壊的変更なし

よくある質問

Q: フェーズが失敗した場合はどうなりますか？スキップしたり再試行したりできますか？

A: はい。各フェーズには復旧提案を含む明示的なエラーハンドリングがあります。再試行、明確化の提供、スコープの変更、または中止が可能です。暗黙の失敗はありません。

Q: 1つのマイクロスキルだけを使用できますか（例：設計からの生成のみ）？

A: オーケストレーターは4つのフェーズすべてを順番に呼び出すことを想定しています。単一のマイクロスキルを使用したい場合は、名前を指定して直接呼び出してください：/pwrl-plan-scope、/pwrl-plan-design など。

Q: なぜエージェントルーティングがないのですか？

A: エージェントは価値なしに複雑性を追加していました。マイクロスキルパイプラインは決定的で、テスト可能で、理解が容易です。直接スキル呼び出しはよりシンプルで保守性が高いです。

Q: これを他のワークフローに拡張できますか？

A: はい！マイクロスキルは再利用可能です。例えば、pwrl-work はユニット分解に pwrl-plan-design を使用できます。docs/guides/micro-skill-patterns.md を参照してください。

ステータス: 純粋スキルパイプライン（エージェントルーティングなし） バージョン: 2.0（エージェント依存アーキテクチャからリファクタリング） 作成日: 2026-06-11

関連スキル

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community