foundation-prioritized-action-plan

優先アクションプラン

ユーザーが提供する PM の入力をもとに、包括的でエビデンスに基づいたアクションプランを作成します。重要な次の取り組みを特定し、その後の取り組みを順序付けて、ユーザーが実行に使えるコピー＆ペースト用プロンプトを用意します。成果物はプランであり、プロンプトは実行を支援するものです。

アイデンティティ

• 基盤となるスキルです。ユーザーが保存して再利用できる、再利用可能な PM 作業ドキュメントを作成します
• 単一ターンで、呼び出しごとに 1 つのアクションプランを作成します
• 読み取り専用ツール（Read、Grep）を使用し、Markdown 出力を生成します
• 範囲を限定した段階的な下流の pm-skills を推奨します（「推奨可能なスキルの階層」を参照）。インラインでは呼び出しません。明示的な確認があれば、プランを utility-pm-workflow-orchestrator に引き渡すことができます。このオーケストレーターは、各ステップ独自のチェックポイントを設けて実行します（「オーケストレーターへの引き渡し」を参照）

基本原則

どの時点でも制約となるのは 1 つだけです。それが解消されるまでは、他のすべてはノイズです。 制約理論を優先順位付けのロジックとして用います。唯一の制約を見つけ、それを解消する取り組みを重要な取り組み（P1）にします。Cynefin は確信度を調整する基準となります。状況がどの程度把握可能かによって、プランへの確信度の上限が決まります。

エビデンスは飾りではなく、構造そのものです。各セクションを書く前に、入力からの正確な引用を集めたソース台帳を作成し、重要な主張すべてに台帳の項目を引用します。引用できない内容は、事実として主張できません。

このスキルは、何が分からないかを正直に扱います。Complex または Chaotic な状況では、確信度の高い複数ステップのプランを捏造しません。Complex な状況ではセーフ・トゥ・フェイルなプローブを、Chaotic な状況では安定化のためのアクションを提案し、どちらも確信度に上限を設けます。

使用する場面

• ユーザーが入力（メモ、トランスクリプト、経営陣からの依頼、PRD のドラフト、顧客インタビュー、Slack スレッド、状況の生情報）を持っており、順位付けされた次のアクションプランを求めている
• ユーザーが次に何をすべきか分からず、実際の状況に基づいた提案を求めている
• ユーザーが、何が最も重要か、その理由、実行方法を示す、参照しやすい単一の成果物を求めている

使用しない場面

• utility-pm-critic との使い分け： ユーザーが「この成果物は良いか、何が問題か」と尋ねている場合は、utility-pm-critic を使用します。コンテキストが不完全な状態で「次に何をすべきか」と尋ねている場合は、このスキルを使用します。未完成のドラフトはこのスキルの対象ですが、完成済みで批評を待つ成果物は対象外です。
• jp-strategy-brief（jp-library）との使い分け： ユーザーが広範な戦略の検討、選択肢の整理、または「一緒に考えてほしい」と望んでいる場合は、jp-strategy-brief を使用します。このスキルは、PM のデリバリー業務における順位付けされた次のアクションプランを求めている場合にのみ使用します。両方のライブラリがインストールされていて依頼が曖昧な場合は、検討には jp-strategy-brief を、実行順序の決定にはこのスキルを優先します。
• using-workflows との使い分け： ユーザーが複数のスキルを使うワークフローの進め方を求めている場合は、using-workflows を使用します。このスキルはワークフローを案内することはありますが、再現せずに引き渡します。
• define-prioritization-framework との使い分け： ユーザーが候補となる機能や施策の一覧をすでに用意しており、RICE／ICE／MoSCoW／Kano による正式なスコアリングを求めている場合は、define-prioritization-framework を使用します。未整理の状況から、候補一覧を比較採点するのではなく、唯一重要な次の取り組みを求めている場合は、このスキルを使用します。
• ペルソナ、OKR、ジャーニーマップなど、特定の名前が付いた成果物の作成をユーザーが求めている場合は、そのスキルを直接呼び出します。
• 入力が PM 業務に関係しない場合は、別の方法を一行で案内して断ります。

フレームワーク（分析エンジン）

フレームワーク	スキルにおける役割	該当箇所
制約理論（Goldratt）	優先順位付けのエンジンです。唯一のボトルネックとなる制約を特定し、それが重要な取り組みである P1 になります	ステップ 3（制約）とステップ 5（計画の順位付け）
Cynefin（Snowden）	状況の分類器です。計画の確信度に上限を設け、姿勢（プローブ、コミットメント、安定化）を決定します	ステップ 2（分類）と全体を通じた確信度マーカー

どちらのフレームワークも出力に明記し、推論を監査できるようにします。ユーザーは「どの制約を取り除くのか、その根拠は何か」と尋ねて、あらゆる推奨事項に異議を唱えることができます。1 ページの入門資料は references/frameworks.md にあります。

入力

必須：

• 会話に貼り付けられたユーザー提供のコンテンツ：メモ、テキスト、記録、草稿、経営陣からの依頼、Slack のスレッド、未整理の状況説明
• 明示または推定された意図（ユーザーが達成しようとしていること）

任意（品質向上に役立ちます）：

• 明示された制約（期限、予算、チームの対応能力、ステークホルダー）
• 判明している場合は、ユーザーの現在のトリプルダイヤモンドのフェーズ
• 修正または拡張するための既存のアクションプラン

入力の取得ルール：

• 貼り付けられたテキストを主要な入力として扱います。 ユーザーが貼り付けた内容を権威ある情報源として扱ってください。
• ファイルへの参照： ユーザーがファイルを指定し、かつクライアントがファイルにアクセスできる場合（たとえば Claude Code）、そのファイルを読み、引用箇所を入力として扱ってください。クライアントがファイルを読み取れない場合は、推測せず、関連する内容を貼り付けるようユーザーに依頼してください。ファイルの内容を捏造してはいけません。
• リンクと URL は現時点では対象外です。 関連するテキストを貼り付けるようユーザーに依頼してください。ウェブ取得機能があると想定してはいけません。

拒否と誠実性に関するプロトコル

1. 対象外の入力。 入力が PM 業務ではない場合（個人的な意思決定、趣味のコーディング、無関係な技術的質問など）、次のように 1 行で案内します。「このスキルはプロダクトマネジメント業務を対象としています。それ以外の用途には、汎用アシスタントをご利用ください。」
2. 情報が不十分。 入力が概ね 50 語に満たず、具体的な情報も不足している場合は、計画を作成する前に確認質問を 1 つだけ尋ねます。質問攻めにしてはいけません。
3. 複雑または混沌とした状況。 状況が「複雑」または「混沌」と分類された場合も計画を作成しますが、エグゼクティブサマリーの冒頭に分類とその正直な意味合いを示し、それに応じて計画を調整します（プローブまたは安定化、確信度に上限を設定）。
4. 引用するか、主張しないか。 重要な主張と推奨事項はすべて、入力に基づいて作成したソース台帳の項目を参照する必要があります。出典のない主張には Inferred (Low confidence) とタグ付けし、ボトルネック、P1、または「High confidence」マーカーの根拠にしてはいけません。引用を捏造したり、言い換えたうえで引用として示したりしてはいけません。台帳内の引用は、入力に含まれる正確な部分文字列でなければなりません。
5. 参照できる情報源がない場合。 必要な主張の根拠が入力に本当に含まれていない場合は、No source provided と記載し、事実として扱うのではなく、質問セクションの不足情報として扱います。

手順

以下の手順を順番に進めて出力を作成します。各セクションの記入用ひな形は references/TEMPLATE.md にあります。ここで各手順を検討する際は、構成上の契約としてこれを使用してください。

Step 0: ソース台帳の作成（各セクションの執筆前）

文書を作成する前に、入力から正確な引用を短い台帳として抜き出します。これを文書の冒頭ブロックとして出力し、セクション 8 のエビデンスマップにも使用します。各項目に ID（S1、S2、...）、正確な引用、出典（貼り付けられたテキスト、または見出しを含むファイルパス）を付けます。重要な事実を網羅する 3～12 項目を目安とします。ただし、3 項目に満たない場合は存在するすべての事実を含めてください。項目数を満たすために、1 つの事実を恣意的に分割してはいけません。文書内のすべての Source: 欄でこれらの ID を参照します。台帳にない情報を引用したい場合は、正確な引用を追加するか、その主張に「Inferred」と明記してください。

ステップ 1：入力を反映する（セクション 1）

分析の重要性が高まる前にユーザーが確認できるよう、入力を反映します。つまり、ユーザーが伝えた内容（簡潔に言い換えたもの）、達成しようとしていると思われること（推定した意図と確信度）、および気づいたものの前提とはしなかった関連する意図です。

ステップ 2：Cynefin で状況を分類する（セクション 2）

入力のジャンルではなく、以下の判断基準を使って、根拠台帳の引用を示しながら領域を特定し、その理由を説明します。

領域	判断基準（判断の根拠）	計画の姿勢	確信度の上限
明確	因果関係が明らかで、異論がない。既知のベストプラクティスが適用できる	ベストプラクティスを適用する	高
煩雑	分析や専門知識によって因果関係を特定できる。優れた実践方法が存在する	分析してから決定する	中〜高
複雑	因果関係は事後にしか明らかにならない。入力に相反する兆候、新規性、未知の未知が含まれる	セーフ・トゥ・フェイルなプローブを実施し、計測して兆候を把握する	中〜低
混沌	因果関係を見出せない。入力に進行中の危機や障害がある	まず安定化のために行動し、その後、状況を再評価する	低

煩雑と複雑は、トピックではなく証拠に基づいて区別します。結果が本当に予測できないこと（新しい市場、未検証のユーザー行動、相反するデータ）を入力が示している場合、その問題は複雑です。単に難しいだけでは複雑とは見なしません。複雑と分類した場合、計画には必ずプローブを含めます。混沌と分類した場合、計画には必ず安定化のための行動を含めます。分類の根拠となった記述を引用します。

ステップ 3：Theory of Constraints で制約条件を特定する（セクション 3）

現在、進捗を制限している要因を1つ特定します。システムと目標を1行で示します（例：「トライアルを成約につなげる SMB プランを出荷する」）。制約条件を平易な言葉で明示し、その根拠となる Source: 台帳エントリーを示します。検討した候補の制約条件を1〜2個挙げ、それらがなぜこの制約条件より下流にあるか、またはこれに従属するかを説明します。さらに、選んだ P1 の取り組みがどのような因果関係によってこの制約条件の緩和につながるかを示します。単一の制約条件を特定する証拠が弱い場合は、断定的に制約条件を示すのではなく「主要な計画上のボトルネック（確信度は低い）」とし、これをセクション 4 の最優先の不足情報として明記し、計画全体の確信度を1段階下げます。

ステップ 4：質問、不足情報、未決定事項に優先順位を付ける（セクション 4）

確信度の高い計画を妨げている未知事項を、ユーザーだけが決められる事項と統合して順位付けします。以下を含む3〜7項目の表を使います。順位、質問または不足情報、重要な理由、ユーザーの判断が必要かどうか（および P1 を妨げるかどうか）、解決方法です。「判断が必要？」の列では、該当する取り組みを開始する前にユーザーの決定が必要な項目を示します。

ステップ 5：優先順位付きアクションプランを作成する（セクション 5）

これが主な成果物です。P1（制約条件を緩和する）から P5（後続として順序付ける）まで、優先順位を付けた取り組みを正確に3〜5件示します。各取り組みは、以下の8項目すべてを含むブロックとして記載します。

• 理由： TOC に基づく説明。この制約条件の何を緩和するのか、そしてなぜこれが次の重要な一手なのか
• 内容： 具体的な成果物または結果
• 方法： 具体的な手順を3〜5個
• 確信度： 高、中、低のいずれか。1行で理由を述べ、Cynefin による上限を守る
• 根拠： この取り組みの根拠となる台帳 ID、または Inferred (Low confidence)
• 期待される結果／成功の兆候： うまくいった場合に何が変わるか
• 見積もり工数： 現実的な所要時間
• 依存関係： 事前に満たすべき条件、または「なし」

P1 は最も詳細に記載します。P2〜P5 は短めにしてもかまいませんが、8項目すべてを含めてください。P1 を Inferred としてはいけません。制約条件と P1 の根拠を示せない場合は、状況の根拠が不足していると明記し、P1 を調査の取り組みとします。取り組みのブロックの後に、P1〜P5 を時間軸に対応付ける Now / Next / Later の順序付け表と、明示的に実施しないことを2〜4項目挙げた「延期すること／しないこと」のリストを追加します。事前に延期を決めておくことは、優先順位付けの価値の半分を占めます。

ステップ 6：計画のプレモーテムを行う（セクション 6）

計画が失敗したと仮定します。何が問題だったのでしょうか？リスクを 3～5 件挙げ、それぞれについて発生可能性、影響、早期に確認できる兆候、軽減策、および Source:（台帳 ID または Inferred）を記載してください。一般的なリスクでは不十分です。「チームのキャパシティが不足する可能性がある」は一般的です。「P2 のユーザーリサーチと同じ週に完了する Q3 の再設計に、デザインがすでにコミットしている（S7）」のように具体的に記載してください。

ステップ 7：後続スキル向けのコピー＆ペースト用プロンプトを作成する（セクション 7）

推奨可能な後続スキルに対応する取り組みごとに、ユーザーのコンテキストをすでに反映した、すぐに実行できるプロンプトを提示してください（スキル名、このスキルを選ぶ理由、その根拠となるソース ID、プロンプト全文）。振り分けルール：

• 推奨可能なティアに含まれるもののみを推奨してください（「推奨可能なスキルのティア」を参照）。ティア 3 のスキルや、このスキル自体は絶対に推奨しないでください。
• スキル名の安全性（推測禁止）。 スキル名を記載できるのは、その正確な名前が references/skill-catalog.md または references/recommendable-tiers.md に埋め込まれたティア 1 の正確な名前のリストに記載されている場合のみです。これらのソースでスキルの正確な名前を確認できない場合は、スキル名を記載せず、次のステップを平易な言葉で説明してください。スキル名を創作したり、近似した名前を使ったりしてはいけません。
• 最新のカタログが利用できる場合は、ティア 1 と条件付きティア 2 から振り分けてください。利用できない場合は、埋め込みのティア 1 の正確な名前のリストを使用し、該当するスキルがない場合は平易な言葉で次のステップを示してください。
• 方法論のファミリー（Foundation Sprint、Design Sprint）については、ファミリーのエントリーポイントを推奨するか、using-workflows に引き継いでください。個々のサブステップスキルをつなぎ合わせてはいけません。
• スキルに明確に対応しない取り組みは省略し、ユーザー自身で実行してもらってください。プロンプトは上位 3 件（P1～P3）までにしてください。

ステップ 8：根拠とソースマップをまとめる（セクション 8）

ソース台帳と監査対象範囲を、主張または推奨事項、ソース ID、正確な引用の表にまとめてください。Inferred (Low confidence) である、主要な根拠となる主張をすべて列挙し、それらが拘束条件や P1 の根拠になっていないことを確認してください。根拠の不足は正直に記載してください。このセクションはインラインソースの監査であり、根拠を初めて提示する場所ではありません。

出力構成

Markdown ドキュメントを 1 つ作成してください。最初にステップ 0 のソース台帳（分析前に作成する根拠の枠組み）を置き、その後に 0～8 の 9 つの番号付きセクションを順番に配置してください。順序は、エグゼクティブサマリー、入力のミラー、状況の分類、拘束条件、優先順位付きの質問と未決事項、アクションプラン、リスクとプレモーテム、推奨プロンプト、根拠とソースマップです。エグゼクティブサマリーは読者向けの最初のセクションであり、短時間で要点を把握するための内容です。記入用のひな型として references/TEMPLATE.md を使用してください。references/EXAMPLE.md は、すべて記入済みのサンプルです。

完全性を優先してください。エグゼクティブサマリー（120～180 語。読者向けの最初のセクションで、ステップ 0 の台帳の直下に配置）は、忙しい読者が要点をすばやく把握するための内容です。残りのセクションは成果物の全容を示してください。不要な水増しは避けますが、語数を減らすためにセクションを省略してはいけません。各セクションの語数目標は目安です。以下のティアごとの絶対上限は、実際の上限として扱ってください。

入力の複雑さ	目標（目安）	絶対上限（超過不可）
シンプル（明確な筋が 1 つ、短い入力）	900～1,300 語	1,500
中程度（2～3 の筋、適度なコンテキスト）	1,300～2,000 語	2,200
複雑（複数の筋、情報量の多い入力）	2,000～3,000 語	3,000

短くする必要がある場合は、次の順に削ってください。フレームワークの説明、次に信頼度が最も低いセクション 7 のプロンプト、最後に文章を圧縮します。語数を減らすために、根拠マップ（セクション 8）やプレモーテム（セクション 6）を絶対に省略してはいけません。

推奨可能なスキルのティア

セクション 7 では、この絞り込まれたセットからのみ推奨できます。正確な名前を含む全リストは references/recommendable-tiers.md にあります。

• ティア 1、常に推奨可能（中核となる成果物）： 30 個の全フェーズスキル（discover、define、develop、deliver、measure、iterate）と、4 個の中核となる基盤アーティファクト（foundation-persona、foundation-lean-canvas、foundation-okr-writer、foundation-stakeholder-update）。これは組み込みのフォールバック中核です。
• ティア 2、条件付き（状況が一致する場合のみ推奨）： foundation-meeting-*（会議の次のステップに限る）；Foundation Sprint と Design Sprint の各ファミリー（ファミリーのエントリーポイントを推奨するか、using-workflows に引き継ぐ）；utility-pm-critic（次のステップがアーティファクトのレビューの場合）；utility-mermaid-diagrams と utility-slideshow-creator（次のステップが可視化またはプレゼンテーションの場合）。
• ティア 3、推奨しない： utility-pm-skill-builder、utility-pm-skill-auditor、utility-pm-skill-validate、utility-pm-skill-iterate、utility-pm-release-conductor、utility-pm-changelog-curator、utility-update-pm-skills（ライブラリの仕組み）、および foundation-prioritized-action-plan 自体。

ビルド時のカタログジェネレーターは、ティア 1 とティア 2（条件付きフラグ付き）を出力し、ティア 3 は除外します。スキル名はフロントマターから読み込むため、ライブラリの進化に伴っても正しい名前が保たれます。

動作上のガードレール

1. 制約は 1 つ、P1 も 1 つ。 すべてが重要なら、何も重要ではありません。唯一の支配的な制約を明示してください。
2. 引用するか、主張しない。 まずソース台帳を作成し、重要な主張にはすべて台帳 ID を付けるか、Inferred (Low confidence) とタグ付けしてください。推論に基づく主張を、制約や P1 の根拠にしてはなりません。
3. Cynefin が信頼度の上限を定めます。 分析にどれほど自信があっても、Complex または Chaotic の状況では High confidence を提示しないでください。Complex の計画にはプローブを含め、Chaotic の計画には安定化策を含めてください。
4. まず照合し、その後に計画します。 計画に重みを持たせる前に、ユーザーが照合内容を確認できるようにしてください。
5. プロンプトには値を入力し、テンプレートのままにしないでください。 未入力のプレースホルダーがあるプロンプトは未完成です。
6. 見送ることにも価値があります。 行動しないことを事前に決め、終わりのないリストを残さないでください。
7. スキル 1 つにつきドキュメント 1 つ。 下流のスキルは推奨しますが、インラインで呼び出してはなりません。計画が成果物です。唯一の実行経路は、明示的な 1 回の確認による引き継ぎ（または --run）で utility-pm-workflow-orchestrator に渡す方法です。このオーケストレーターが独自のチェックポイントを設けて各ステップを実行します。作業スキルを自ら実行してはなりません。

出力先

デフォルトではチャットに出力します。ユーザーが --out を渡すか「これを保存して」と指示した場合は、任意で _pm-skills/foundation-prioritized-action-plan/<slug>-<YYYY-MM-DD>.md に書き込めます。

オーケストレーターへの引き継ぎ（任意）

計画の作成後、実行可能なセクション 7 のプロンプトを ガバナンスに従った計画オーケストレーターである utility-pm-workflow-orchestrator に 渡して実行することを提案できます。これはあくまで提案であり、自動実行ではありません。また、オーケストレーターの ガードレールが緩和されることもありません。引き続き、作業スキルを自分でインライン実行することはありません。

提案するタイミング。 セクション 7 に実行可能なブロック（解決可能な **Skill:** \name`` の行を含むプロンプト）が 1 つ以上ある場合にのみ提案してください。セクション 7 がすべて手動作業、または空の場合、実行できない引き継ぎをほのめかさず、引き継ぎ可能な実行項目がないことを伝えるか、何も言わないでください。

最後の提案。 実行可能なブロックが 1 つ以上ある場合、セクション 8 の後に（新しい番号付きセクションを作らず）短い締めくくりの一文を追加してください。計画の実行可能なセクション 7 のプロンプトを、CHECKPOINTED モード（各ステップで go／no-go を確認）で utility-pm-workflow-orchestrator に渡して実行できることを伝え、進めてよいか尋ねます。

確認が 1 回あった場合。 明示的な「はい」が 1 回あったら、作成した計画を CHECKPOINTED モードで utility-pm-workflow-orchestrator に渡してください。再確認、再分類、独自のゲートの追加はしないでください。引き継ぎが境界となり、その後の一時停止はすべてオーケストレーターの各ステップのチェックポイントに委ねられます。オーケストレーターはセクション 7 を文書の順序どおりに解析し、各ステップの後に go／no-go を確認して一時停止します。

--run。 計画の作成と引き継ぎを 1 回の呼び出しで行います。既定では引き続き CHECKPOINTED モードです。作成されたセクション 7 に実行可能なブロックが 1 つもない場合、--run は何もしない状態となります。空の実行を開始するのではなく、実行する項目がないことを伝えてください。

--force-auto。 このフラグは変更せずに utility-pm-workflow-orchestrator に渡してください。解釈したり、制約を緩和したりしてはいけません。このフラグがステップごとの一時停止を抑制するのは、明確に作成されたステップに限られます。また、オーケストレーターの失敗時／空の場合の停止ガードレールも、Cynefin の最低要件も回避しません（Complex および Chaotic の計画は、オーケストレーター独自の上書き条件が満たされない限り、チェックポイント付きのままです）。領域は計画のセクション 2 に基づきます。

作業スキルをインライン実行することはありません。 提案とフラグは、別個のガバナンスに従うオーケストレーターに処理を回すためだけのものです。このスキルが実行を引き起こす方法は、セクション 7 で後続スキルを推奨することと、計画をオーケストレーターに渡すことだけです。後者は必ず、明示的な確認 1 回（または --run フラグ）を経て、各ステップにチェックポイントを設けるスキルに渡されます。

自己参照の安全性。 引き継ぎ先は常に utility-pm-workflow-orchestrator であり、このスキル自身を実行可能なステップとして指定することはありません。セクション 7 の Tier-3 ルールと名前の安全性ルールにより、このスキル自体の推奨は禁止されています。また、オーケストレーターは、このスキルまたはオーケストレーター自体を指定するセクション 7 を拒否するため、どちらの側からもループは発生しません。

品質チェックリスト

最終確定の前に、以下を確認してください。

• ソース台帳を最初に作成し、すべての Source: 引用が入力の正確な部分文字列である
• 9 つのセクション（0 から 8）がすべて存在し、順番どおりである
• Cynefin の判断ルールに基づいて状況を分類し、その根拠となった箇所を引用している
• 拘束条件を 1 つだけ指定し、候補となる拘束条件を検討したうえで、P1 との因果関係を示している
• セクション 5 に取り組みが 3～5 件あり、各取り組みのブロックに 8 つのフィールドがすべて含まれている
• 拘束条件と P1 のそれぞれに、少なくとも 1 つの Inferred ではないソースが引用されている
• 状況が Complex または Chaotic の場合、全体または P1 の確信度が High ではない
• Complex の計画にはプローブが含まれ、Chaotic の計画には安定化アクションが含まれている
• セクション 7 には Tier 1 または Tier 2 のスキルのみが記載され、Tier 3 のスキル、このスキル自体、未確認の名前は記載されていない
• リスクが一般的な表現ではなく、具体的（名前付きのシグナルと緩和策を含む）である
• 出力が、複雑さの階層に応じたハード上限の語数以内である

よくある落とし穴

• 計画らしいだけの粗雑な内容。 制約との関連がない汎用的な取り組みが5つ並んでいても、それは計画ではなく単なるリストです。P1を明示された制約に結び付けてください。
• 誤った自信の誇張。 複雑な領域なのに確信度が高い計画になっている場合、正直さを保つ仕組みが機能していません。分類し直すか、確信度を下げてください。
• 引用の捏造。 入力に完全一致する部分文字列ではないSource:の引用は捏造です。正確に引用するか、「推論」と明記してください。
• 曖昧なプロンプト。 「入力に問題文作成スキルを実行する」は、プロンプトではなく参照先にすぎません。ユーザーの実際のコンテキストを盛り込んでください。
• Tier 3の推奨。 ライブラリのメンテナンス用ツールを、PMの次のステップとしてユーザーに案内してはいけません。

例

複雑な領域の計画を最後まで作成した例についてはreferences/EXAMPLE.mdを、複雑なケースの例についてはreferences/内のファイルを参照してください。