GitHub Kanban MCP Server
日本語で応答して
下記の要件に従って処理やタスク管理を行って
---
# 🔄 リポジトリ要件定義プロンプト
## 🛠️ 環境設定
- GitHub CLI設定
- ghコマンドは認証済みとして進める
- https://github.com/Sunwood-ai-labs/github-kanban-mcp-server.git へのアクセスが可能
- MCPの設定
- インストールディレクトリ：
- Windows: `C:\Prj\MCP`
- Unix系: `~/prj/MCP`
- セットアップコマンド：
```bash
npx @modelcontextprotocol/create-server roulette-server -n "roulette-server2" -d "A Model Context Protocol server"
```
## 📋 タスク管理方針
1. プロジェクト開始時
- タスクを洗い出す
- 洗い出したタスクをGitHub issueとして登録する
- 各issueには適切なラベルと担当者を設定する
2. 進捗管理
- タスクの進捗は該当するissueにコメントとして報告する
- 進捗報告は具体的な実施内容と次のステップを含める
- ブロッカーや課題が発生した場合も、issueにコメントとして記録する
3. コミット管理
- 各コミットメッセージには関連するissue番号を含める
- 形式：`<絵文字> <タイプ> #<Issue番号>: <タイトル>`
## 🌟 基本方針
- 言語ポリシー
- コード中の変数名・関数名・クラス名・ファイル名などのコード要素：英語
- コメント、README、ドキュメント、コミットメッセージ：日本語
- README作成・整備
- `README.md`を必ず作成し、日本語で記述すること
- `README.md`には、`assets`ディレクトリに格納したSVGヘッダー画像を使用し、中央揃えで配置する
- SVGは角を丸めた形状、グラデーション、図形・テキスト・グラデーションに対するアニメーションを付与し、英語の洗練された表現を入れること
- `README.md`は変更が生じるたびに更新すること
- 重複コンテンツは避け、情報源を一元化する
- READMEの章には絵文字を付与して可読性を高める
## 💻 コーディング・ドキュメント作成原則
以下の原則はコードだけでなく、ドキュメント（Markdown形式のファイルを含む）にも適用される：
1. DRY（Dont Repeat Yourself）
- 同一・類似処理は関数・モジュール化することで再利用性を高める
- ドキュメントでも情報の重複を避け、必要に応じて相互参照を使用する
2. 責務の分離（Separation of Concerns）
- 各モジュール・クラス・関数は単一責務を明確にし、表現・ロジック・データ処理を分離する
- ドキュメントも目的別にファイルを分け、適切に構造化する
3. KISS（Keep It Simple, Stupid）
- コードは可能な限りシンプルに保ち、過度な複雑化を避ける
- ドキュメントも簡潔で理解しやすい記述を心がける
4. 分割統治（Divide and Conquer）
- 大きな問題は小さな単位に分割し、テスト・保守性を向上させる
- 大きなドキュメントは適切に章立てし、必要に応じて複数のファイルに分割する
5. 防御的プログラミング（Defensive Programming）
- 入力値検証、例外処理、エラー対策を行い、堅牢性とセキュリティを確保する
- ドキュメントでも想定外の使用シナリオや注意点を明記する
6. YAGNI（You Arent Gonna Need It）
- 現在の要件に集中し、不要な将来予測による過剰実装を避ける
- ドキュメントも現時点で必要な情報に焦点を当てる
7. 可読性とドキュメンテーション
- 変数・関数・クラス名は英語で、役割が一目でわかるような命名を行う
- コメントやREADMEでコードの意図・ロジックを日本語で明確に説明する
- ドキュメントは一貫した書式とスタイルを維持する
8. テスト駆動開発（TDD）とユニットテスト
- 基本機能にはユニットテストを用意する
- TDDを推奨し、要件定義→テスト→実装→リファクタリングのサイクルを確立する
- ドキュメントも定期的にレビューし、正確性を確認する
9. バージョン管理とコードレビュー
- Gitで変更履歴を管理し、プルリクエストを通じてコードレビューを行う
- ファイルを変更したら、変更があったファイルごとにコミットを行い、履歴管理を明確化すること
- ドキュメントの変更も同様にバージョン管理し、レビューを行う
10. SOLID原則の適用
- SRP, OCP, LSP, ISP, DIPを考慮し、拡張性・保守性の高い設計を行う
- ドキュメントも単一責任の原則に従い、適切に構造化する
## 📝 コミットメッセージ形式
- コミットメッセージは以下の形式に従うこと:
```
<絵文字> <タイプ> #<Issue番号>: <タイトル>
<本文>
<フッター>
```
- タイトル（コミットメッセージの1行目）の先頭には必ず絵文字を付与し、日本語で記述すること
- タイプは以下のいずれかとする：
- feat: 新機能
- fix: バグ修正
- docs: ドキュメントの変更
- style: コードスタイルの変更（動作に影響しない）
- refactor: リファクタリング
- perf: パフォーマンス改善
- test: テストの追加・修正
- chore: ビルドプロセスやツールの変更