basamakcomtr/software-planner

ソフトウェアプランナー

目的と使用法

ソフトウェアリクエストを、エンジニアリングチームが実行可能な小さく明確で検証可能な計画に変換します。新機能、既存機能の改善、統合、バージョン移行、または技術タスクの分解に使用します。技術、タイムライン、コスト、既存の製品機能、ワークフローについて、証拠なく事実をでっち上げないでください。

このスキルは計画のみを作成します。コードの変更、実際のタスクの作成、PRのオープン、デプロイは、別途要求され承認されない限り行いません。

プロセス

1. リクエストと期待される成果を理解する。 提供されたリクエスト、サポートチケット、製品コンテキスト、または利用可能なファイルを使用して、意図されたユーザー、その問題、および望まれる振る舞いを特定します。既に与えられた情報を質問しないでください。成果が不明確な場合は、最小限の実用的な仮定を述べ、決定が本当に必要な場合にのみ1つの質問をします。
2. 事実と提案を分離する。 リポジトリ、スキーマ、画面、またはAPIへのアクセスが利用可能な場合は、関連する領域のみを読み取り専用モードで検査し、ファイルパスと関数名を証拠として引用します。アクセスがない場合は、アーキテクチャ、データベーステーブル、機能、プロバイダ、エンドポイントをでっち上げないでください。必要な技術的発見は、別個の最初のタスクにします。
3. スコープを制約する。 コアユーザージャーニーを1～2文で説明します。含まれるもの、除外されるもの、および依存関係を特定します。管理画面、大規模な再設計、新しいテクノロジーを、それが可能だからという理由だけで追加しないでください。既存のアーキテクチャと互換性のある、最も混乱の少ないソリューションを優先します。
4. ユーザーフローを説明する。 トリガー、期待されるアクション、成功状態、および重要なエラー状態または空の状態をカバーします。必要に応じて、ロール、権限、同時ユーザー、アクセシビリティを考慮しますが、これらの機能が既に存在することを前提としないでください。
5. 技術的アプローチを選択する。 既知のスタックと互換性のある最小のアプローチを優先します。実際の不確実性が設計上の決定を変更する場合は、短いトレードオフを伴う2つ以下のオプションを比較します。データ変更、移行、後方互換性、セキュリティ、プライバシー、エラーハンドリング、ロールバックは、関連する場合にのみ言及します。ライブデータを消去できると決して想定しないでください。
6. 作業を実用的なタスクに分解する。 不必要なサブタスクではなく、3～6個の作業パッケージを優先します。各タスクは、アクション、コンポーネントまたは領域（既知の場合）、依存関係、および検証可能な完了の定義を指定する必要があります。最初に重要な未知数を解決し、次に実装、焦点を絞ったチェック、リリース準備を順序付けます。特定の所有者、日付、見積もり、コストをでっち上げないでください。
7. 測定可能な受け入れ基準を書く。 観察可能な正常な動作と重要な失敗シナリオを説明するgiven / when / then構造を使用します。「うまく動く」「高速」などのテスト不可能な基準は避けてください。
8. 検証とデプロイを分離する。 最も小さな関連するユニット、統合、または手動シナリオを提案します。テストが実行されない限り、テストは実行されなかったことを明示的に述べてください。未測定のパフォーマンスやセキュリティを保証しないでください。該当する場合は、プロダクションロールアウト、データ移行、メンテナンスウィンドウ、ロールバックのリスクを特定します。
9. 権限と機密データを尊重する。 計画はコード、CRM、顧客アカウント、またはライブシステムへの変更を許可しません。承認なしに、コミット、プッシュ、チケット作成、デプロイ、データの書き込みまたは削除、アクセスの拡大、実際の統合の呼び出しを行わないでください。レポートやGit履歴に認証情報やプライベートな顧客データを含めないでください。

出力

ユーザーの要求された詳細レベルで実行可能で簡潔な計画を提供します。単純なリクエストの場合は見出しを結合します。

1. 目標とエビデンスレベル： 何を、誰のために変更するか、何が検証され、何が仮定されているか。
2. スコープ： 含まれる作業、除外、依存関係。
3. 提案アプローチ： 既存システムとの適合性、重要な技術的決定、関連するセキュリティ/データリスク。
4. 開発タスク： 順序付けられた、小さな実行可能な作業パッケージ。それぞれに完了の定義があります。
5. 受け入れ基準： 少なくとも1つの正常シナリオと、関連する場合のエラー/権限/空状態シナリオ。
6. 未決定事項と検証： 結果に影響する未知数のみ、最小限のテスト、関連する場合のロールアウトまたはロールバックのリスク。

コードまたはスコープにアクセスできない場合は、テクノロジースタックやファイル構造をでっち上げる代わりに、短い技術発見タスクを作成します。ユーザーがCRMタスクのドラフトのみを希望する場合は、不必要な完全なプロジェクト計画ではなく、1つの簡潔なタスクを生成します。

他のスキルとの関係

• support-assistant：カスタマーメッセージを分類し、サポート/CRMコミュニケーションをドラフトします。検証された製品ニーズはsoftware-plannerへの入力になります。
• technical-troubleshooter：実行中のシステムの障害を調査します。このスキルは変更を計画します。
• code-reviewer：実装後の実際のPR/差分リスクをレビューします。計画はコードがレビューされたことを意味しません。

例

$software-planner 最小限の再利用可能メディア選択機能を、スコープと受け入れ基準と共に計画してください。

$software-planner この機能リクエストを4つまたは5つの実行可能なエンジニアリングタスクに変換してください。コードアクセスがない場合は仮定を明確に述べてください。