manji-standard-server

docs/spec/ の仕様書を元に、docs/work/YYYYMMDD_<feature>.md として実装計画書を作成する。Phase 分解・影響範囲・テスト戦略・リスクを構造化し、実装前にユーザー承認を取る。「実装計画立てて」「work 書いて」「どう進めるか計画して」などで起動。

差分や指定コードを構造化されたレビュー観点（正確性・設計・テスト・可読性・セキュリティ）で読み、優先度付きで指摘する。修正は提案するが勝手に書き換えない。「レビューして」「コードレビュー」「セカンドオピニオン」などで起動。

未知のコードベースを最短で把握するための構造化探索を行う。言語・ビルドツール・アーキテクチャ・テスト方針・主要なエントリポイントを短時間でレポート化する。「このプロジェクト教えて」「コードベース調べて」「初見で入ったから概要ほしい」などで起動。

未コミットの変更を依存関係と関心事に基づいて適切な粒度のコミットに分割する。自動生成物・手動実装・テスト・ドキュメントを分離し、レビューしやすい履歴を作る。「コミット分けて」「良い粒度でコミット」「この変更コミットにして」などで起動。

バグ調査を場当たり的でなく体系的に進める。再現→仮説→検証→修正→回帰テストの順序を守り、仮説と事実を分けて記録する。「バグ調査して」「なぜか動かない」「デバッグ手伝って」などで起動。

汎用的な開発オーケストレーター。docs/spec/ の仕様と docs/work/ の実装計画書を軸に、Phase 分解と PDCA サイクルで実装を進める。自分は実装せず、各 Phase を Task で専門 agent / Explore / Plan に委託する。「開発進めて」「実装オーケストレートして」「機能実装して」などで起動。

実 DB を起動して Handler → Usecase → Service → Repository を貫通させる integration test を書く。fixture 分離、TestMain/global setup、トランザクション単位のロールバックによるテスト間隔離、API エンドポイントを HTTP 経由で叩く E2E 的検証を扱う。単体テスト(mock 前提)は対象外で `backend-test-writer` に委譲する。「integration test 書いて」「E2E テスト追加して」「DB 込みのテスト書いて」などで起動。

コミット履歴と差分から質の高い Pull Request 説明文を生成する。Summary / Changes / Test plan / Risk を構造化し、レビュアーが 30 秒で理解できる PR を作る。「PR 説明書いて」「PR description 作って」「pull request の本文を整えて」などで起動。

コードを触る前にリファクタの影響範囲・順序・ロールバック戦略を計画する。依存関係を洗い出し、安全に進められる小さなステップに分解する。「リファクタ計画立てて」「影響範囲調べて」「安全に直す手順を作って」などで起動。

答えを先に出さず問い返しで思考を整理するソクラテス式の壁打ち相手を務める。バグ調査・設計判断・方針決定で、ユーザー自身が答えに辿り着くのを助ける。「壁打ちして」「rubber duck」「一緒に考えて」「考えを整理したい」などで起動。

新機能の仕様書を docs/spec/ 配下に作成する。実装詳細を含めない純粋な仕様（目的・振る舞い・ルール・境界）に絞ってマークダウン化する。「仕様書作って」「spec 書いて」「〜の仕様まとめて」などで起動。

docs/spec/ 配下の既存仕様書を新しい決定事項や変更に合わせて更新する。差分をわかりやすく提示し、整合性を保ちながら最小限の変更で書き換える。「spec 更新して」「仕様書を最新化して」などで起動。

既存コードに対してテストが不足している箇所を体系的に洗い出し、優先度付きリストにする。コード複雑度・変更頻度・障害リスクを軸に評価する。「テスト不足どこ？」「テストギャップ調べて」「カバレッジ穴探して」などで起動。

実装前 or 実装後にテスト戦略を立てる。どの層に何をテストするか、ケースの網羅性、既存基盤の活用方針を計画書化する。実装スキルには踏み込まず、テストの設計に集中する。「テスト戦略立てて」「テスト計画書いて」などで起動。

テスト計画（test-planner 成果物）または既存の仕様に基づいて、プロジェクト既存パターンに合わせた**単体テスト(mock 前提)**を書く。言語・フレームワーク非依存で、既存テストの構造を踏襲することを最優先する。実 DB を起こす integration test は `backend-integration-test-writer` に委譲する。「テスト書いて」「このコードのテスト追加して」などで起動。

docs/spec/ の仕様書を元に、docs/work/YYYYMMDD_<feature>.md として実装計画書を作成する。Phase 分解・影響範囲・テスト戦略・リスクを構造化し、実装前にユーザー承認を取る。「実装計画立てて」「work 書いて」「どう進めるか計画して」などで起動。