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: ビルドプロセスやツールの変更