uipath-planner

UiPath Planner — 設計とタスクの導出

2つの役割を1つのエントリーポイントで実行します。

1. 設計 — プロセス定義書（PDD）を、実装可能なソリューション設計書（SDD）に変換します。対象範囲（単一製品または複数プロジェクトのソリューション）を選択し、SDDを作成します。

2. 計画 — SDD（またはPDD以外の依頼）からスキルごとのタスクリストを導出し、専門家に振り分け、実行中の TaskCreate 呼び出しを発行します。

作業そのものは実行しません。出力はSDDのMarkdown、計画／タスクのMarkdown、および実行中のタスクです。実装は常に専門家に引き継ぎます。

このスキルには3つの経路があり、Entry Guardによって決定されます。

• Phase D — 設計。 入力がPDD、または明示的な「設計して／アーキテクチャを設計して」という依頼です。SDDを作成します。SDDの書き込みをもってターンを終了し、次のターンでLane Aを続行します。sdd-generation-guide.mdを参照してください。ケース管理の設計は、Phase DのCase Design Laneを通じて行います（case-design-lane-guide.md）。対話形式で設計し、最後にCase Reviewの確認を1回行います。
• Lane A — PDD主導。 入力は ## Planner Handoff マーカーを含むSDDです（Phase Dで作成したもの、または手動で作成したもの）。SDDを読み取り、タスクを導出し、実行中のタスクを発行します。ユーザーへのプロンプトは0～2回です。pdd-driven-lane-guide.mdを参照してください。
• Lane B — 非PDD。 SDDがなく、PDD以外の複数プロジェクトにわたる依頼です。希望を聞き取り、プロジェクトの種類を判定し、計画を作成して、実行中のタスクを発行します。プロンプトは0～3回（最大5回呼び出し）です。non-pdd-lane-guide.mdを参照してください。

このスキルを使う場面

• ユーザーがPDDまたはプロセスに関する知識ソース（PDD、Confluenceページ、BPMNモデル、会議／Zoomの記録、SOP、要件文書など。PDF／Word／Markdown／.txt／.bpmn形式または貼り付け）を提供し、それを基に設計または構築するよう依頼する場合 → Phase D
• ユーザーがUiPathオートメーションの設計／アーキテクチャ設計／SDDの生成を依頼する場合 → Phase D
• ユーザーがSDDのパスを指定する場合 → Lane A
• 依頼が複雑で、個別に構築できる複数のプロジェクトにまたがり、それぞれに別の専門家が必要な場合（単独で動作するRPAプロセスや、個別に構築する必要があるエージェントをFlowがオーケストレーションする場合） → Lane B
• 依頼が曖昧な場合（適合する専門家が明確でない、または「何を構築できますか？」という依頼）

単一プロジェクトのタスクでは、このスキルを使わないでください。専門家を直接呼び出してください。1人の専門家が最初から最後まで担当する場合、プロジェクト内に複数の要素が含まれていても、その依頼は単一プロジェクトです。スクリプトノード、インラインのHITL承認ステップ、独自のソリューションラッパーを含むFlowは、1つの uipath-maestro-flow タスクです。インラインノード（HITL QuickForm、スクリプト、コネクタ、インラインエージェント）とソリューションの足場づくりは、専門家が自身で行う作成作業のサブステップであり、オーケストレーションする別個のスキルではありません。これらを別々のスキルとして数えて計画を発行するのは、最もよくある誤った起動です。このスキルを使うのは、個別に構築できるプロジェクト（別々の .uipx プロジェクト）にまたがる作業、またはPDDをアーキテクチャに変換する作業に限ります。

重要なルール

1. 計画と設計のみを行い、オートメーションのコードは作成しないでください。 出力はSDDのMarkdown（Phase D）、計画／タスクのMarkdown（Lane A／B）、および実行中の TaskCreate 呼び出しです。XAML、C#、Python、JSON、プロジェクト／足場ファイルは絶対に作成しないでください。実装は常に専門家に引き継ぎます。（SDD／計画の作成は、このスキルが行う唯一のファイル作成です。）

2. まずエントリーガードを実行します。 入力を確認し、ほかのことを始める前に Phase D／Lane A／Lane B に振り分けます。

3. アーキテクチャを設計する前にスコープを選択します（Phase D）— すべての製品をプラットフォームの制約で判定します。 単一製品（RPA Process／Library／Test Auto、Maestro Flow、Maestro BPMN、Case、Agents、Coded Apps、API Workflows）か、複数プロジェクトの Solution かによって、テンプレートとプロジェクト構造が決まります。Product Selection Guide を使用します：Constraint Gate → Level 1 → 1.5（RPA サブタイプ）→ 1.75（Solution の構成）→ 2.5（プロジェクトの分割）。提供モデル（Cloud／Automation Suite／スタンドアロン。Phase D の開始時に確認）により、platform-availability-guide.md を通じて利用できない製品を除外します。ユーザーが除外した製品を再度提示することはありません。

4. SDD はアーキテクチャのみを記述し、タスクリストは含めません。 Phase D では SDD（プロジェクト構造、データ定義、テスト戦略など）を作成します。タスクの導出は Lane A の役割です。SDD に Task 1／Task N のテンプレートや、実装 用の TaskCreate 呼び出しを含めてはいけません。SDD の最後には ## Next Steps セクションを置きます。（進捗追跡用の TaskCreate 呼び出しは別用途として許可されています。）

5. すべての SDD に ## Planner Handoff ヘッダーと `` マーカーを記載します。 これは検出に必須の契約です。Entry Guard はどちらか一方のシグナルを検出します（意図的に冗長化しています）。Generated by: uipath-planner。フィールド：Status（draft → ready）、Execution autonomy、Delivery model、SDD scope、solution-root ブロック（ソリューションスコープのみ：Solution root SDD、Solution ID、Project SDD role root|child、Independently executable: no（子では不可。ルートの Project Inventory と SDD Index のみが実行可能なエントリとなり、子とルートは単一の正式なタスクファイルを共有します））、Project list セクション、Tasks file、Generated by、Generation date、Template validation。最初の段階的な書き込みでは Status: draft を設定します。SME による解決とテンプレートのスーパーセット検証が完了した後に限り、Phase D で ready（および Template validation: passed）に切り替えます。マーカーはプランナー作成の SDD であることを示し、Status フィールドは利用可能かどうかを示します。Lane A は ready のみからタスクを導出します（フィールドがない場合はレガシーとみなし、ready として扱います）。すべてのテンプレートで、このヘッダーは ## Document History の後に配置します。

6. テンプレートのセクション構成を、必須のスーパーセット契約として遵守します。 単一プロダクトのスコープは <PROCESS_NAME_KEBAB>-sdd.md に、ソリューションスコープは概要を <SOLUTION_NAME_KEBAB>-solution-sdd.md に、プロジェクトごとの SDD を <PROJECT_NAME_KEBAB>-sdd.md に記述します。ユーザーが SDD の出力パスを指定した場合は、これらのデフォルトではなく、指定されたパスを使用します。書き込み後、生成した H2/H3 見出しをテンプレートの目次と比較します。生成された見出しの集合は、必ずテンプレートの見出しのスーパーセットでなければなりません。テンプレートで必須の H2/H3 が欠けている場合、それは SDD の欠陥であり、[SME REVIEW] 項目ではありません。再生成してください。

7. テストは必須であり、徹底して行います。「ハッピーパスのみ」を提案してはいけません。 Phase D では、ハッピーパス、エッジケース、エラーシナリオ、Master Projects の E2E を含む完全な Testing Strategy セクションを記述します。計画には、生成スキルごとに必須のテストタスクを追加し、そのスペシャリストのテスト用リファレンスへ誘導します。手順をインラインで説明してはいけません。実装スペシャリストは実行時にスコープを縮小できますが、SDD と計画では縮小しません。

8. 再説明せず、適切な担当へ誘導します。 計画には、どのスキルをどの順序で読み込むかを記載します。スペシャリスト内部のフロー（ターゲット設定、OR 登録、XAML パイプライン、HITL のフィールド／結果スキーマ、認証、テスト手順）は説明しません。HITL ステップでは、業務上の意図のみを渡します（「マネージャーが経費を承認または却下する。却下時には理由を追加できます」）。フィールドレベルの仕様は記述せず、スキーマの形は HITL スペシャリストに選ばせます。

9. フェーズごとのプロンプト予算。 Phase D は独自のチェックポイントモデルで実行します（sdd-generation-guide.md を参照）。数値による厳密な上限はありません。Lane A と Lane B の上限は、それぞれ AskUserQuestion の呼び出し 5 回です。実行自律性について尋ねるのは 1 回だけとし（Phase D の開始時）、その内容を引き継ぎヘッダーに記載します。Lane A はそれを読み取り、再度尋ねません。Phase D のフローで解決したスコープ／UI に関する回答は、SDD を通じて後続フェーズに引き継ぎます。

10. 不足箇所は [DEFAULT] または [SME REVIEW] で補います。業務ルールを黙って創作してはいけません。 業界標準のパターン（リトライ回数、タイムアウト）には [DEFAULT] を、業務知識の不足には [SME REVIEW] を使用します。最終化する前に、ユーザーとともに [SME REVIEW] 項目を解決します（これらは Status: ready への切り替えを妨げますが、Phase 3 Step 0 のスケルトン書き込みは妨げません）。Agent/Coded App の不足箇所については、AskUserQuestion を使って（不足箇所を補って進めるか、別のプロダクトにするか）確認します。自動的に別の方法へ切り替えてはいけません。

    • この 2 つのトークンが不足箇所を示す語彙のすべてであり、文字列の完全一致が重要です。 後続のすべての利用者は、Action Required — SME Review Items ブロック、件数、Status: ready への切り替え、Lane A での前提の引き継ぎ、ファイル内を検索するレビュー担当者を含め、[SME REVIEW]／[DEFAULT] との完全一致で項目を検出します。
    • マーカーは、角括弧の中に何も加えず、そのまま記載します。 説明は閉じ角括弧の後ろに記載します。例：| UiPath version | [SME REVIEW] not recorded in the PDD |。説明をマーカーの中に入れてはいけません（[SME REVIEW — not recorded]）。別の語句に置き換えてもいけません（[PLACEHOLDER]、[TBD]、[TODO]、<fill in>、N/A、「確認予定」のような文章）。マーカーに装飾を加えたり別の名前にしたりすると、上記のすべての利用者から認識されず、不足箇所が気付かれないまま消えてしまいます。
    • 別の文書から内容を対応付けたりコピーしたりする場合（ソース SDD からクライアントテンプレートへ、PDD から SDD へ、ある SDD セクションから別の SDD セクションへ）、マーカーをバイト単位でそのまま引き継ぎます。 自分が記載していないマーカーを書き換えると、他の人が記録した不足箇所が失われます。自分が見つけた不足箇所には新しいマーカーを追加し、既存のマーカーは決して編集しないでください。

11. Solution ビルドの最終成果物は、パックされた .uipx です。 SDD の ## Next Steps セクションでは、ユーザーに uipath-solution スキルを案内します（uip solution init → プロジェクトごとに project add → resources refresh → pack）。プロジェクトフォルダーだけでは納品物になりません。例外：デリバリーモデル上の制約ゲートによって Solutions がブロックされる場合（スタンドアロン、2.2510 より前の Automation Suite、またはユーザーによる除外）は、Next Steps を uipath-platform 経由でルーティングする、パッケージごとの Orchestrator 公開に書き換えます。

12. SDD のアーキテクチャを計画にコピーしたり、セレクターや UI ターゲットを作り出したりしてはいけません。 計画ではスキルプロンプト内で SDD のセクションパスを参照し、アーキテクチャの内容を重複して記載しません。セレクターには開発時のアプリケーション調査が必要です。専門担当者に任せてください。

13. Case Management SDD の唯一の作成者です。 会話形式、uipath-maestro-case からのビルド引き継ぎ、ドラフトの最終化、PDD 主導など、すべてのケース設計パスで Case Design Lane（case-design-lane-guide.md）を実行します。このレーンが会話、1 回の確認、書き込みを担当します。ケースモデルとそのデフォルト値は case-design-layers-guide.md に、レンダリングの仕様はケース SDD テンプレートに記載されています。設計時に解決するのは ID のみです。スキーマの検出、プロジェクトのスキャフォールディング、見つからない場合の作成は決して行いません。これらはビルド時の作業であり、ゲートの判断として記録します。レーンのファイルは Read ツールで開き、cat は決して使わないでください。 設計時に読むファイルは厳密に 3 つです。レーンガイド、レイヤーガイド、ケース SDD テンプレートです。case-sdd-conformance-checklist.md はその中に含まれません。最後にゲートのサブエージェントが使用します。設計のみの依頼（caseplan.json より前に終了する依頼）では、読み取りセットの後、設計に関する推論を行う前に、最初のツール呼び出しとして sdd.md をディスクに作成します。このシードの内容は読み取りセットに依存しないため、セクションごとに追記します。実施ペースは、レーンの § Sketch bounded no-build の項目 0 に従います。

エントリーガード

ほかの作業に着手する前に、このガードを実行します。

0. Product design-lane signals — checked first. Some products register a
   dedicated Phase D design lane (today: Case Management —
   references/case/case-design-lane-guide.md). Route to Phase D — Design through
   the product's lane when any of these fire (the path taxonomy stays the three
   paths above; a lane is Phase D's product-specific entrance):
   - a build request handed off by that product's build skill because its
     design input is missing (same conversation) → the lane's Build
     handoff mode,
   - a design request for that product with no PDD → the lane, direct,
   - the product's design draft exists (or is named) and the user asks to
     finalize it → the lane, draft finalization.

1. No document path?
   - Explicit design/architect language ("design this", "architect this",
     "generate an SDD"), OR an inline-described process with enough detail to
     substitute for a PDD (process steps + applications + exceptions) → Phase D — Design.
     A design/SDD request that is thin on process detail still routes to Phase D —
     elicit the missing steps/applications/exceptions via `AskUserQuestion`
     (Phase 1) rather than degrading to a Lane B plan.
   - Otherwise → Lane B — Non-PDD. Lane B is the default for document-less
     multi-project requests.

2. Document path → read its first ~50 lines.
   - Contains `## Planner Handoff` OR `` → Lane A — PDD-driven.
     (Either signal alone is sufficient — redundant on purpose.)
   - Reads as a PDD **or any process-knowledge source** — a process
     description (steps + applications + exceptions) in a PDD, Confluence
     page, BPMN model, meeting/Zoom transcript, SOP, or requirements doc;
     or a binary .pdf/.docx the user calls a PDD → Phase D — Design. Less-structured
     sources (transcripts, thin wikis) still route to Phase D but trigger
     heavier Phase 1 elicitation.

3. Otherwise (no marker, ambiguous, or unparseable) — ask via AskUserQuestion:

   > What is the document at <path>?
   > 1. Process Definition Document (PDD) — author the SDD (Phase D — Design), then derive tasks
   > 2. Solution Design Document (SDD) — proceed with task generation (Lane A — PDD-driven)
   > 3. Other context — read it; use its content to resolve Lane B elicitation
   >    questions (skip any question it answers) and as plan input (Lane B — Non-PDD)

4. Route per the choice. For an SDD with no handoff header, proceed with safe
   defaults — see pdd-driven-lane-guide.md Step 1 for the default set and how
   defaults are surfaced to the user.

ファイル名や拡張子だけでパターンマッチしてはいけません。信頼できないためです。## Planner Handoff 見出しと `` マーカーが、検出の基準となります。Phase D は両方を決定論的に書き込み、ガードはどちらか一方を検出します。

フェーズ D — 設計（概要）

開始条件：入力が PDD である場合、または設計／アーキテクトの依頼が明示されている場合です。3 つのフェーズで構成されます。詳細は sdd-generation-guide.md を参照してください。ユーザーへの質問はすべて選択肢を番号で示す形式にします。

1. フェーズ 1 — PDD の分析とスコープの選択。 実行モード（Autonomous または Interactive）とデリバリーモデル（Cloud／Automation Suite／スタンドアロン）を 1 回のまとめた呼び出しで質問します。ただし、PDD または依頼に記載されている場合、あるいは uip login status の事前確認でセッションの BaseUrl から特定できる場合は、デリバリーモデルの質問を省略します。PDD 全体を読み、構造化された情報（環境と制約に関するシグナル、現状／あるべき姿を含む）を抽出し、ニーズプロファイルをまとめます（ステップ 3.5 — 製品はキーワードではなくニーズを根拠に選択します）。その後、Constraint Gate → Level 1（主要スコープ）→ Level 1.5（RPA のサブタイプ）→ Level 1.75（ソリューションの構成）→ Level 2.5（プロジェクトの分解）を実行します。ステップ 2.5 では、認証済みの uip ライブラリ検索を実行します（CLI 認証が必要です）。Interactive モードでは、推奨スコープを先頭に、代替案をその下に示した概要を提示します。Autonomous モードでは、そのまま続行します。
2. フェーズ 2 — アーキテクチャレビュー。 製品固有のテンプレートを読み込みます。アーキテクチャの中核セクションを作成します。Interactive モードでは、レビュー用に提示します。
3. フェーズ 3 — SDD 全体の生成。 ステップ 0 は必須のゲートです。フェーズ 3 のセクションを生成する前に、SDD の骨組み（ヘッダー + ## Planner Handoff ヘッダー／マーカーと Status: draft + ## Decisions Made／## Recommended Scope + フェーズ 1／2 のセクション）をディスクに書き込みます。その後、残りの各セクションを生成するたびに追記します。これにより、ウォッチドッグによって強制終了された場合でも、評価可能なファイルが残ります。ディスクへの書き込みは進捗タスク 4 であり、決して最後のタスクではありません。綿密な Testing Strategy を含む残りすべてのセクションを生成します。最終化する前に [SME REVIEW] 項目を解決します（未解決の項目には記録済みのデフォルト値を引き継ぐため ready を妨げません。draft のままにするのは、アーキテクチャを妨げる項目のみです）。上位集合のチェックに合格した後、最後の書き込みで Status を ready に変更します。SDD の書き込みはターンの境界です。自律モードでは、SDD の概要の後にターンを終了し、次のターンで Lane A に進みます（1 ターン内で両方のフェーズを続けて実行しないでください）。

Lane A — PDD 駆動（概要）

開始条件：Planner Handoff マーカーを含む SDD が検出された場合（またはフェーズ D で作成した場合）です。

1. SDD の ## Planner Handoff ヘッダーを読みます。Status: draft の場合はタスクの導出を拒否します（フェーズ D が未完了、または SME 項目がブロック要因となっています。再開または再生成を提案してください。フィールドがない場合はレガシーとして扱い、ready とします。ready の SDD にある、デフォルト値を引き継いだ未解決の SME 項目は、前提条件としてタスクに引き継ぎます）。フェーズ D で選択された実行の自律性を再利用し、再度質問しないでください。SDD scope: solution の場合は、ルートアルゴリズムを実行します。Solution ルートを特定し、インデックスに記載されたすべての子を検証し（存在すること、同じ Solution ID であること、ready であること）、すべての子のアーキテクチャを読み、共有リソースを統合し、正規のタスクファイルを 1 つ出力します（pdd-driven-lane-guide のステップ 3 を参照）。

2. <process>-tasks.md がすでに存在する場合は、「続行／再生成」を質問します（プロンプト 1 回）。plan-and-tasks-format.md → 再生成ロジック を参照してください。

3. SDD のプロジェクトリストセクションを解析します。マルチスキルパターンを選択します。

4. SDD の Application Inventory に UI アプリケーションが記載されており、回答がすでに確定していない場合に限り、UI の一括質問（質問 3 つ、呼び出し 1 回）を行います。

5. タスクを導出します。<process>-tasks.md を書き込みます。

6. Execution autonomy: interactive の場合は、レビューのために EnterPlanMode を実行します。autonomous の場合は、ライブタスクを直接出力します。

7. TaskCreate の呼び出しと addBlockedBy のエッジを出力します。引き継ぎます。

手順の全容：pdd-driven-lane-guide.md。

レーン B — 非 PDD（概要）

トリガー条件：SDD ではない、ドキュメントのないマルチプロジェクトのリクエスト（明示的な設計／アーキテクチャに関する表現や、インラインで記述されたプロセスがフェーズ D を示さない場合のデフォルトルートです）。

1. ステップ 1 — 質問する前に検出（プロンプトなし）：提供されたコンテキストドキュメントを読み、ファイルシステムを検出（クロスプラットフォームの Glob／Read／Grep）、複数スキルのパターンを分類し、必要性に基づいてプロジェクトタイプを推定し、デリバリーモデルを決定します。

2. ステップ 2 — 単一スキルで終了：1 つのプロジェクトを 1 人のスペシャリストが最初から最後まで担当する場合 → レーン B を終了し、検出したコンテキストを渡して、そのスペシャリストを直接読み込みます（プランファイルもタスクもありません）。

3. ステップ 3 — 質問をまとめて実施：生成方法＋実行の自律性＋プロジェクトタイプのフォールバック（まだ曖昧な場合）＋デリバリーモデル（ゲート付きプロダクトが候補の場合）を、1 回の AskUserQuestion 呼び出しで確認します。すでに解決済みの質問は省きます。

4. ステップ 4 UI バッチ — プランに uipath-rpa での UI オートメーションが含まれる場合のみ実施します。

5. YYYY-MM-DD-<feature>.md を docs/plans/（プロジェクトあり）または ./plans/（プロジェクトなし）に書き込みます。すべてのタスクプロンプトにプランのパスを含めます。

6. 先に調査する場合 → EnterPlanMode。同時に実行する場合 → プランをテキストとして出力し、タスクをその場で作成します。

手順の全文：non-pdd-lane-guide.md。

スキルの対応範囲

各スペシャリストが担当する内容の概要です。プラン内で各スキルの内部フローを説明しないでください。各スキルはそれぞれの手順を個別に記述しているため、ここで重複させると内容にずれが生じます。

スキル	管理対象	認証を処理しますか？	デプロイを処理しますか？
uipath-rpa	RPA ワークフロー（XAML および C# でコーディング）：作成、編集、ビルド、実行、デバッグ。ライブアプリの探索や調査を含む、UI オートメーションの作成工程全体をすべて管理します。	いいえ（Studio に依存）	いいえ — .uipx の複数プロジェクトには uipath-solution、単一の非ソリューションパッケージには uipath-platform に委ねます
uipath-agents	AI エージェント — コードベース（LangGraph / LlamaIndex / OpenAI Agents）およびローコード（agent.json）	はい（uip login）	はい — エンドツーエンド
uipath-coded-apps	Web アプリ（.uipath/ ディレクトリ）：ビルド、同期、パッケージ化、公開、デプロイ	はい（uip login）	はい — エンドツーエンド
uipath-functions	コーディングされた Functions — Python（uip function new -l py；Pydantic による型付き I/O）または TypeScript/JavaScript（-l ts / js、デフォルトは TypeScript；defineFunction とスキーマファーストの型付き I/O） — 変換、カスタム認証 API 呼び出し、ERP/IS 接続クエリ向けの、アトミックで決定論的なロジックです。サーバーレス、または RPA ロボット上で実行されます。JS/TS 関数は、ジョブ実行関数または HTTP エンドポイント（Coded App バックエンド）として提供されます。関数ごとに呼び出し方式は 1 つです。Maestro（Flow/BPMN）、ツールとしてのエージェント、Orchestrator API、または HTTP トリガーから呼び出されます。LLM/エージェントのループはありません（その用途には uipath-agents を使用します）	はい（uip login）	はい — uip function pack/publish
uipath-rules	Business Rules プロジェクト — プロジェクトごとに 1 つの .dmn 決定テーブル（DMN 1.5）：uip rules init、refresh、validate、debug。BPMN のビジネスルールタスク、Case の business-rule タスク、RPA から呼び出されます	はい（debug では uip login が必要）	いいえ — uipath-solution を介した uip solution pack/publish/deploy
uipath-maestro-flow	RPA、エージェント、アプリをオーケストレーションする .flow ファイル	はい（uip login）	一部 — .uipx でラップされたソリューションの Orchestrator へのデプロイは uipath-solution、単一の非ソリューションパッケージは uipath-platform
uipath-maestro-bpmn	.bpmn ファイル — RPA、エージェント、API、HITL を対象とする、標準ベースの BPMN 2.0 プロセスオーケストレーション（ゲートウェイ、イベント、境界タイムアウト、サブプロセス、マルチインスタンス）。インラインの userTask/HITL ノードも作成します。	はい（uip login）	はい — uip maestro bpmn を介してパッケージ化、アップロード、公開／デプロイ、実行します。.uipx でラップされたソリューションの Orchestrator へのデプロイは uipath-solution
uipath-maestro-case	Case Management の作成 — SDD から caseplan.case を作成します（case pack で caseplan.case.bpmn にコンパイルします。.bpmn を直接作成する場合は uipath-maestro-bpmn を使用します）	はい（uip login）	一部 — Studio Web と Orchestrator に公開します。.uipx ソリューションのデプロイは uipath-solution
uipath-api-workflow	API Workflows（JSON document.dsl）：作成、ローカル実行（uip api-workflow run）、コネクターアクティビティ	はい（uip login）	いいえ — uipath-solution を介した uip solution pack/publish
uipath-human-in-the-loop	HITL ノードの作成 — Flow プロジェクト内の承認ゲート、エスカレーション、書き戻し検証。コーディングされたエージェントの HITL には uipath-agents を使用します。BPMN / Case / RPA では、それぞれインラインで管理します（userTask / タスクタイプ / Action Center）	いいえ（作成のみ）	いいえ — ホストプロジェクトに含まれます
uipath-platform	認証（uip login）、Orchestrator（フォルダー、プロセス、ジョブ、マシン、ユーザー、ロール）、リソース（アセット、キュー、ストレージバケットとバケットファイル、ライブラリ、Webhook、トリガー）、Integration Service（コネクター、接続、アクティビティ、IS トリガー）、Data Fabric のエンティティ／レコード／ファイル／選択肢セット（uip df）、トレース、ライセンス	はい（認証ハブ）	はい — 単一の非ソリューションパッケージと、デプロイ後の Orchestrator 側の操作に対応
uipath-ixp	Document Understanding / IXP — 半構造化ドキュメント（請求書、フォーム）からの抽出：タクソノミー、モデル、分類／抽出／検証。スタンドアロンプロジェクト、またはプライマリが消費する抽出ステップです	はい（uip login）	一部 — uip ixp を介してモデルを公開／タグ付けします。ホストプロジェクトによって消費されます
uipath-connector-builder	uip is connectors builder を介した、Integration Service のカスタムコネクターのディスク上での作成（REST+JSON） — 必要な統合用のカタログ項目がない場合にコネクターを作成します（API Workflows / Maestro / Agents に必要です。RPA では代わりに API を直接呼び出せます）	はい（uip login）	はい — インポート／公開がデプロイにあたります（uip is connectors）
uipath-mcp-servers	UiPath AgentHub MCP サーバーの登録（6 種類：uipath、coded、command、remote、swagger、platform）と、uipath タイプのサーバーでのリソースツールの作成（automation、agent、agentic-process、api-workflow）。Orchestrator リソース、外部 HTTP MCP エンドポイント、OpenAPI 仕様、公開済みのコーディングされたエージェント、ローカルサブプロセスコマンド、またはファーストパーティの UiPath サービスを MCP ツールとしてラップします。FastMCP / Python mcp SDK の作業には使用しません。	はい（uip login）	はい — 登録がデプロイにあたります（AgentHub に直接送信します）
uipath-solution	.uipx ソリューション向けの uip solution ライフサイクル（初期化、パッケージ化、公開、デプロイ、有効化）。PDD 主導のフローでは最後のスキルとして実行されます（.uipx ソリューションのデプロイ）。	はい（uip login）	はい — 複数プロジェクトからなる Solution（.uipx）のデプロイに対応します

参考資料のナビゲーション

フェーズ D — 設計

ファイル	目的
SDD 生成ガイド	フェーズのオーケストレーター — フェーズ 1、2、3 の手順を段階的に説明します
ケース設計レーンガイド	ケース設計の対話 — 開始、テナントの状況確認、作成ポリシー、1 回のケースレビュー、書き込み
ケース設計レイヤーガイド	ケースモデルと設計上のすべての デフォルト — 骨格（トリガー、ステージ、10 種類のタスク）、ゲート（ライフサイクルルール、終了、順序付け、セカンダリーレーン）、データ（変数、出力、式）、時間（SLA、エスカレーション、応答）、命名規則、終了チェックリスト
PDD 分析ガイド	形式を問わず、PDD から構造化データを抽出する方法
ビジネスルールガイド	検証ルールと判断ルール、推論ルールの違い、DMN 形式の決定テーブル、推論リスト。RPA §4 または BPMN §5 を記入する際に読み込みます。
製品選定ガイド	制約ゲート（提供モデル＋除外条件のフィルター）、レベル 1（主要なスコープ）、レベル 1.75（ソリューションの構成）、レベル 2.5 パート B（製品横断のプロジェクトリストの統合）、レベル 3（機能追加）、テンプレートのマッピング
プラットフォームの利用可否ガイド	製品 × 提供モデルの利用可否マトリックス（Cloud／Automation Suite／スタンドアロン）、ブロックされた製品の代替案、不確かなセルの検証ルール。制約ゲートの実行時に必ず読み込みます。すべての提供モデルに適用されます。「Cloud は一様ではありません」。バリアント（GovCloud／Dedicated／Test Cloud）やテナントごとの権限設定によって、Cloud 列の製品が利用できない場合があります。
RPA 製品ガイド	RPA レベル 1.5（サブタイプ）、レベル 2（作成モード）、レベル 2.5 パート A（RPA の分解）、R-07 の命名、REFramework。レベル 1 が RPA の場合、またはソリューションに RPA が含まれる場合に読み込みます。
パッケージ選定ガイド	NuGet パッケージの選定、Integration Service と NuGet のルール、製品ごとの依存関係マネージャー。§14 のパッケージ欄または同等の項目を記入する際に読み込みます。
テナントライブラリ検索ガイド	uip or libraries list と JMESPath フィルタリングを使ってデプロイ済みライブラリを検索するステップ 2.5 の手順 — 認証の事前確認、順位付け、結果が 0 件の場合の分岐、手動での代替手段。
有人再認証パターンガイド	人間だけがログインできるポータルの自動化（ハードウェア 2FA トークン、スマートカード、生体認証）の設計契約 — 引き継ぎ地点、状態確認後の再開、有人ロボット、uipath-rpa へのルーティング。PDD でスクリプト化できない対話型サインインが示された場合に読み込みます。
ASDD クロスウォークガイド	クライアント向けの Word SDD／ASDD を生成します。テンプレートのパスについてユーザーに警告し、Markdown SDD を各セクションに対応付け、不足部分を算出します。標準 UiPath SDD テンプレート用のクロスウォークが含まれます。ユーザーが正式なドキュメントを希望する場合、ステップ 2.5 で読み込みます。

SDD テンプレート

ファイル	目的
RPA テンプレート	RPA プロセス／ライブラリ／テスト自動化用の SDD テンプレート
フローテンプレート	Maestro Flow 用の SDD テンプレート
BPMN テンプレート	Maestro BPMN 用の SDD テンプレート
ケース管理テンプレート	ケース管理用の SDD テンプレート（後続の Case Definition Blueprint の形式）
エージェントテンプレート	UiPath Agents 用の SDD テンプレート
コード化アプリテンプレート	コード化アプリ（Web）用の SDD テンプレート
API ワークフローテンプレート	API ワークフロー用の SDD テンプレート

スクリプト（フェーズ D）

スクリプト	目的
scripts/docx-extract.{sh,ps1}	.docx 形式の PDD → UTF-8 の Markdown ＋ 抽出したスクリーンショット（pandoc）。Word 形式の PDD が文字化けして表示される場合は、フェーズ D のステップ 1 で実行します。COM 経由で Word を操作してはいけません。クロスプラットフォーム対応の同等スクリプト： macOS/Linux/Git-Bash では bash …/docx-extract.sh、Windows では pwsh -File …/docx-extract.ps1（または Windows PowerShell 5.1 の場合は powershell -File …）を実行します。2 つのファイルの動作は同一に保ってください。
scripts/sdd-to-docx.{sh,ps1}	生成された SDD の Markdown → 書式設定済みの .docx。企業向けの --reference-doc は任意です。Word 形式の出力をユーザーが求めた場合に限り、フェーズ D のステップ 2.5 で実行します。同じクロスプラットフォーム対応の同等スクリプトの実行方法（.sh は bash、.ps1 は pwsh -File）を使用します。

レーン A・B — 計画

ファイル	目的
PDD 駆動型レーンガイド	レーン A のエンドツーエンドの手順 — SDD のヘッダーを読み取り、プロジェクト一覧を解析し、タスクを導出して tasks.md を作成し、ライブタスクを出力します
非 PDD レーンガイド	レーン B のエンドツーエンドの手順 — 情報の聞き取り、プロジェクトタイプの推定、ファイルシステムの検出、UI の一括処理、plan.md の作成
マルチスキルパターンガイド	名前付きのマルチスキルパターン（RPA の構築＋デプロイ、ローカル／デプロイ済みリソースを使う Flow、RPA ツールを使う Agent など）。両方のレーンで使用します。

| 計画とタスクの形式 | ヘッダーのスキーマ、タスク行のスキーマ、識別タプル、ステータス状態、保持しながら再生成するアルゴリズム、TaskCreate へのマッピング、ハルシネーション防止ルール、品質ルール |

アンチパターン

1. エントリーガードを省略する。 必ず最初に入力を確認してください。PDD を汎用ドキュメントとして黙って扱うと、成果物の品質が低下します。
2. 自動化コードを記述したり、プロジェクトを変更したりする。 作成するのは SDD とプラン／タスクの Markdown のみです。探索優先の Lane B モードでは、変更を伴わない uip による調査が上限です。
3. 単一プロジェクトの依頼をプランとして扱う — 最もよくある誤作動です。インラインノードのルールは、「このスキルを使用する場合」の「スキップ」段落にあります。
4. PDD の構成を SDD にそのままコピーする。 SDD では実装に合わせて内容を再構成します。PDD の文書構成をそのまま踏襲するものではありません。
5. ニーズのプロファイルが別の選択肢を示しているのに、デフォルトで RPA Process を選ぶ。 キーワードではなく、統合したニーズに基づいて Product Selection Guide の判断ツリーを使ってください。真に判断や推論が必要なら Agents、ステージ／SLA／承認ライフサイクルが必要なら Case Management です（ルールで表現できる判断に「AI」を加えても、それは依然として RPA です）。PDD に複数の連携プロジェクトが記載されているのに、単一製品のスコープを無理に選ぶのも同じ誤りです。その場合は Solution を提案してください。
6. SDD 内に Implementation Plan／タスクリストを生成する。 SDD はアーキテクチャのみを扱い、## Next Steps で終わります。タスクの導出は Lane A の役割です。
7. プランや SDD に、スペシャリスト内部のフローを記述する。 ターゲット構成、OR 登録、スキャフォールディング、認証、パック／公開、テスト手順、HITL フィールドスキーマは、いずれもスペシャリスト独自のドキュメントで管理します。これらを本文に含めると、内容の乖離が生じます。
8. テストカバレッジの深さを尋ねる。 テストは常に徹底して行います。ユーザーが迅速な MVP を望む場合、実装スペシャリストが実行時に範囲を絞ります。プランナーがその選択肢を提示することはありません。
9. ファイルシステムのシグナルに反するスキルを推奨する。 .flow → uipath-maestro-flow であり、uipath-rpa ではありません。
10. スクリーンショットからセレクターを推測したり、プランナー／ライブラリ／ファイルシステムがすでに答えられることをユーザーに尋ねたりする。 まずデフォルトを使い、ユーザーにしか決められない事項に限ってプロンプトを使ってください。
11. ## Planner Handoff の見出しを変更したり、`` マーカーを削除したりする。 どちらのシグナルだけでも検出には十分ですが、両方とも残してください。両方を削除すると、Lane A の検出が気づかれないまま機能しなくなります。
12. 顧客のプラットフォームで実行できない製品を推奨したり、除外された製品を再提案したりする。 Automation Suite の案件で、デフォルトでクラウド最新製品（Maestro、Coded Apps、Document Understanding）を選ぶのは、最もコストの高い設計ミスです。ブロックされた製品がレビューを通過しても、納品時に失敗するためです。Constraint Gate を実行し、ユーザーが「X は望まない」と言ったら、そのセッション全体で X を選択対象から除外してください。