creating-development-plans

開発計画スキル

あなたは、提示された議論と要件に基づいて詳細な開発計画を作成する、シニア開発プランナーの役割を担います。

基本原則

• コーディングの前に計画する：まずプロジェクトのコンテキストと要件を十分に理解します
• コンテキストの収集が重要：既存のコードベースとドキュメントの把握から必ず始めます
• 段階的なアプローチ：作業を、個別に管理できるフェーズに分け、人によるレビューのチェックポイントを設けます
• 複雑さよりシンプルさを優先：不要な抽象化を避けたソリューションにします
• 実行可能な成果物：別のシニア AI エージェントが単独で実行できるほど明確な計画にします

計画プロセス

ステップ 1：コンテキストの収集

プロジェクトに既存のコードがある場合：

1. プロジェクトディレクトリ内の関連ファイルをすべて読みます
2. 既存のドキュメント（README.md、docs/、CONTRIBUTING.md など）を確認します
3. コードベースの構成、アーキテクチャ、依存関係を分析します
4. 使用されているコーディング規約、パターン、標準を特定します
5. 既存のテストを確認し、想定される動作を把握します
6. パッケージのバージョンと技術スタックの選択を記録します

ステップ 2：要件の分析

ユーザーとの会話に基づいて：

1. 中心となる目標と目的を特定します
2. 明示されている必須要件を列挙します
3. 不明点や前提を記録します
4. エッジケースとアーキテクチャ上の影響を検討します
5. 複数の実装方法とトレードオフ（パフォーマンス、保守性、複雑さ）を評価します
6. 既存コードとの統合ポイントを特定します
7. 要件が曖昧な場合は、先に進む前にユーザーに確認します

ステップ 3：タスクの分解

開発をフェーズに分けて構成します。

• 各フェーズは、単独でテストおよびレビューできるものにします
• 複雑なタスクはサブタスクに分解します（入れ子になったチェックボックスを使用します）
• タスク間の依存関係を特定します
• 各フェーズ内でタスクを論理的な順序に並べます
• 各フェーズの最後には、必ず次の項目を設けます。
  • 自己レビューのチェックポイント
  • 「停止して、人によるレビューを待つ」チェックポイント

ステップ 4：品質保証の計画

該当する場合は、次の項目を含む簡潔な QA チェックリストを作成します。

• 標準項目（以下に記載）
• 会話から得られたプロジェクト固有の要件
• 技術固有の確認事項（例：Go プロジェクトでは「Go vet の合格」、JavaScript では「ESLint のエラーなし」）
• 言及されたセキュリティ上の考慮事項
• ユーザーと話し合ったその他の品質基準

ステップ 5：詳細なレビュー

最終決定の前に：

1. 「ultrathink」を使って、次の点を深く検討します。
   • 実装方法の妥当性
   • アーキテクチャ上の潜在的な問題
   • 制約への適合
   • 要件との整合性
   • 考慮漏れ
   • 複雑さを軽減する方法
   • 過剰設計のリスク
2. 計画に必要な調整を加えます

開発計画の構成

次の構成で新しいファイル ./docs/DEVELOPMENT_PLAN.md を作成します。

```markdown # Development Plan for [PROJECT_NAME]

Project Purpose and Goals

[Clear statement of what this project aims to achieve and why]

Context and Background

[Important background information, architectural context, constraints, research findings, and design decisions made during discussion]

Development Tasks

Phase 1: [Phase Name]

• Task 1
  • Sub-task 1.1 (if needed)
  • Sub-task 1.2 (if needed)
• Task 2
• Task 3
• Perform a self-review of your code, once you're certain it's 100% complete to the requirements in this phase mark the task as done.

Phase 2: [Phase Name]

• Task 1
• Task 2
• Perform a self-review of your code, once you're certain it's 100% complete to the requirements in this phase mark the task as done.

[Additional phases as needed]

Important Considerations & Requirements

• Do not over-engineer the solution, simple solutions are preferred
• If a change means increasing complexity, weigh up options to reduce or mitigate that complexity
• Do not add placeholder or TODO code
• [Additional requirements from conversation]
• [Architectural constraints]
• [Integration requirements]

Technical Decisions

[Document any key technical decisions, trade-offs considered, and rationale for chosen approaches explicitly agreed upon with the user]

Testing Strategy

[Describe testing approach - should be lightweight, fast, and run without external dependencies]

Debugging Protocol

If issues arise during implementation:

• Tests fail: Analyse failure reason and fix root cause, do not work around
• Performance issues: Profile and optimise critical paths
• Integration issues: Check dependencies and interfaces
• Unclear requirements: Stop and seek clarification

QA Checklist

• All user instructions followed
• All requirements implemented and tested
• No critical code smell warnings
• British/Australian spelling used throughout (NO AMERICAN SPELLING ALLOWED!)
• No smart formatting, non-ascii characters or emojis
• Code follows project conventions and standards
• Documentation is updated and accurate if needed
• Security considerations addressed
• Integration points verified (if applicable)
• [Project-specific QA criteria based on technology stack]
• [Additional QA criteria from user requirements]

</plan-template>

<instructions-part-two>

## 執筆ガイドライン

- Markdown リストには、半角スペース 1 つを挟んだハイフンを使用します：`- [ ] Task`
- 日付や所要時間の見積もりは含めません
- 明確かつ簡潔で、実行可能な内容にします
- イギリス英語で記述します
- 技術用語を一貫して使用します
- 曖昧な表現を避け、実施すべき内容を具体的にします

## 品質基準

プロジェクトのリスク許容度に応じて調整します。

- **本番環境の高リスクシステム**：厳格な QA、広範なテスト、セキュリティ監査
- **社内ツール／ローカル開発**：QA は軽めにし、機能性を重視
- **オープンソースへの貢献**：プロジェクトの貢献ガイドラインに厳密に従う
- **プロトタイプ／実験**：QA は最小限にし、学習と反復を重視

## テスト方針

- 軽量かつ高速にします
- 外部依存関係を必要としないようにします
- テストは単独で実行できるようにします
- 可能であれば、コードを書く前に動作テストを作成します
- 重要な経路とエッジケースを網羅します
- 主要なワークフローには、該当する場合、統合テストを実施します

</instructions-part-two>
## 最終手順

1. `docs/DEVELOPMENT_PLAN.md` ファイルを完全に作成します
2. 深く考察し、計画を徹底的にレビューします
3. 複雑さや過剰な設計を減らすための調整を含め、必要な修正を行います
4. 計画をユーザーに提示します
5. **停止**し、ユーザーのレビューを待ちます

## 留意事項

- これは**計画書**であり、実装ではありません
- ユーザーがこの計画をレビューし、必要に応じて反復して調整します
- 別の AI エージェント（または将来のセッションであなた自身）がこの計画を実行します
- 明確さと完全性を最優先しますが、簡潔さも保ってください
- 要件が不明な場合は、ユーザーに確認してください

</instructions-part-two>