タスクの現状分析と次に進むべきロードマップ提案を行う。ユーザーが明示的にこのスキルの使用を指定した場合にのみ使う。
タスクの現状を分析し、次に実行すべき作業を提案します。
一般に、あるタスクを与えられたとき、それを遂行するための抽象的な手順を考えるところから始めると思います。 ここでいう手順というのは、具体的な作業ではなくメタ的な作業単位のことであり、 「このタスクは目的が十分に明確化されていないから、まずは『背景・目的の整理』からはじめよう」 「このタスクはやるだけのタスクだから、いきなり『実装』からはじめよう」 などの『背景・目的の整理』『実装』を指しています。(実際にどう整理や実装をやっていくかを指しているわけではありません)
まずは抽象的な手順を考え、その後に具体的な作業内容を考え、それをユーザーに提案します。
まずは、与えられた課題に関する関連情報を、十分に収集してください。 タスクのチケットなどが与えられた場合、関連するタスクのチケットやドキュメント、過去の議論なども参照してください。 また、関連するコードがあれば、それも確認してください。
続いて、以下の5つの観点をもとに、調べきれていない情報や不明点があれば追加で調べてください。
それでも不明点が残る場合は、その不明点が後段のステップで解決できるものである場合はその後段のステップで解決することにしてください。 例として、タスクの要件が不足している場合であっても、「要件定義」の段階でそれを明確化できるのであれば、その不明点はそのままにしておいて構いません。 後段のステップで解決できず、今最初に解決しなければならない不明点がある場合は、必要であればその不明点をユーザーに質問してください。
観点
因果関係の明確性
前例の存在
予測可能性
専門知識の必要性
制約条件
[注意] Step 1が完了してから着手してください
ロードマップを構築します。
まず、ロードマップを構築する際の参考として、## ステップの例 セクションを読み、一般的なステップを把握してください。
次に、## フローチャート セクションに従って、タスクのロードマップを構築してください。
質問には以下のラベルがついており、以下の意味を持ちます。
フローチャートには、タスク分解に関する質問も含まれています。
タスク分解をする/しないの判断基準については ## タスク分解の判断基準 セクション記載の内容に従って判断してください。
またフローチャートには、「残りロードマップの再検討」というステップを追加して終了するよう指示している箇所があります。 これは、タスクの具体性が不足している状態で無理に全ロードマップを計画することを避けるためです。 一般に複雑なタスクでは、前段のステップで得られた情報や結論によって後段のアプローチが大きく変わる可能性があるため、最初の段階で後段のステップをすべて見積もることは困難です。 そのため、具体性の不足を解消するためのステップの追加後は「残りロードマップの再検討」をしてもらうようにしています。
[注意] Step 2が完了してから着手してください
決定した各ステップごとに、実施にあたって使うスキルを検討してください(スキルを使わない判断をしてもよいです)。 その後、以下の出力フォーマットで、提案内容を出力してください(使用予定のスキルについては、「なし」と答えてください)。 そして、この内容で問題ないかを必要であればユーザーに確認してください。
## ロードマップの提案
1. {ステップ名} ({使用予定のスキル}): {そのステップで行うこと}
2. {ステップ名}:({使用予定のスキル}) {そのステップで行うこと}
...
## 理由
- Q1: {回答した判定フローチャートの質問} → {yes/no などの判断}
- 判断理由: {判断理由を簡潔に}
- 追加したステップ: {追加したステップ名があれば記載}
- Q2: {回答した判定フローチャートの質問} → {yes/no などの判断}
- 判断理由: {判断理由を簡潔に}
- 追加したステップ: {追加したステップ名があれば記載}
...
{ロードマップの提案理由について、まとめのコメントがあればここに記載}
「必要に応じてユーザーに質問(確認)してください」という指示に対しては、あなたに指示された自律性の程度に従って、 ユーザーに質問(確認)をするかしないかを判断してください。
ユーザーから特に自律性の程度について指示が無かった場合は、該当の指示に直面した場合は基本的にユーザーに質問(確認)をとってください。
Q1: タスクの背景と目的はどちらも整理されていますか? 背景について、タスクのビジネス的な意義や必要性や、タスクが起票された経緯が整理されていてほしいです
Q2: あなた(AI)は今回のタスクについて、「対応方針を検討できる」もしくは「子タスクへの分解の検討ができる」 ほどの関連システム・関連技術の情報を持っていますか?
Q3: [Q] 必要であればユーザーに、今回のタスクの関連システムと関連技術を伝え、理解しているか質問して下さい。 得られた回答について、ユーザーは今回のタスクの関連システム・関連技術について理解していましたか?
Q4: 今回のタスクを完了するために、複数の子タスクに分解して実行するほどのタスクだと思いますか?
Q5: 「要求定義」「要件定義」「対応方針決め」はすべて実施済み、もしくはやらないと決定済みですか?
Q5-1: [Q] 必要であればユーザーに、「要求定義」「要件定義」「対応方針決め」のうち、作業順序や必要性の有無について、意見を伺ってください 質問の意図としては、たとえば対応方針について「(そのほうがメリットが多いため) そもそも対応しない」という判断をする場合、 その前に詳細に要求定義や要件定義を行う必要はないため、そのような対応方針になる可能性があるのであれば、 「要求定義」「要件定義」よりも先に「対応方針決め」を行うことも検討したい、という意図です。 またこの質問をする際、あなた(AI)の意見も添えてください。
Q5-2: タスクの要求事項(ビジネス的に求められている事柄)はすでに定義されていますか?もしくは自明(= タスクの目的そのまま)ですか?
Q5-3: タスクの要件(どのような仕様にするか)はすでに定義されている、もしくは自明(= タスクの目的そのまま)ですか?
Q5-4: タスクの対応方針は自明、もしくはすでに決定されていますか?
Q6: 対応方針について、改めて、その対応方針を進めるにあたって複数の子タスクに分解して実行すべきと思いますか?
Q7: 対応方針について、その決定を踏まえて、改めて詳細事項を詰めるために、追加で要求定義(ビジネス的に求められている事柄)や要件定義(どのような仕様にするか)の整理検討は必要ですか?
Q8: [Q] 必要であればユーザーに、対応方針を進めるにあたって、どのようなステップに分けて進めるべきか意見を伺ってください その際、「ステップ分けの判断基準」セクションを参考に、あなた(AI)の意見も添えてください。 そして、意見があればそれに従いステップを追加してください。 質問不要と判断した場合、あなたの意見通りにステップを追加してください。
汎用
dev-step--clarify-backgrounddev-step--explain-featuredev-step--explain-technologydev-step--clarify-requirementsdev-step--clarify-requirementsdev-step--explore-solutions開発系
dev-step--design-architecturedev-step--plan-implementationdev-step--verify-implementationdev-step--write-prその他
dev-step--plan-roadmap スキルを使うことタスクのステップが上流から下流に一直線に進まない場合、子タスクに分解したほうが良いです。 例えば「Aの調査→Aの設計→Aの実装→Bの調査→Bの設計→Bの実装」というステップがあった場合、 これは (Aの)実装から(Bの)設計という下流から上流に戻る流れが発生しているため、 「Aの調査→Aの設計→Aの実装」と「Bの調査→Bの設計→Bの実装」の2つの子タスクに分解すべきです。
ステップ分ける際は、以下の区切り方を参考にしてください。
以下に気をつけてください。 もし間違えていることに気付いた場合、やり直してください。