今の Codex.app に、Dev Perfect Workflow、XeroPM Kanban Ops、team-architecture-mcp、xeropm-kanban-prod、xeropm-daily-report-prod が入っているか確認して。不足があれば一覧で教えて。

https://github.com/xerographix/codex-skills.git から Dev Perfect Workflow と XeroPM Kanban Ops をインストールして。終わったら再起動が必要かも教えて。

team-architecture-mcp と xeropm-kanban-prod を Codex.app に追加して。既存設定があれば上書きせず、差分だけ整えて。

TOKEN発行 管理者用

管理者からもらった token を使って、本人の日報用 MCP を設定して。名前は xeropm-daily-report-prod、URL は https://xeropm-kanban-mcp-prod-131236897984.asia-northeast1.run.app/mcp、Authorization ヘッダーに Bearer <token> を入れて。xeropm-kanban-prod は共有 Kanban 用として残して。

Codex に依頼するなら、こう言えば大丈夫です。 管理者からもらった token を使って、xeropm-daily-report-prod を設定して。URL は https://xeropm-kanban-mcp-prod-131236897984.asia-northeast1.run.app/mcp、Authorization ヘッダーは Bearer <token> にして。xeropm-kanban-prod は共有 Kanban 用として残して。

次の社内向け初期プロンプトを、Codex.app の Custom Instructions に入れて。既存内容があれば消さずに整理して統合して。

MCP とスキルが正しく入っているか確認したい。以下の順で、壊さない範囲で最小限の smoke test を実行して、最後に「入っている / 使えない / 設定不足」を一覧で報告して。 前提 - 既存データを変更しない - 破壊的操作はしない - 何か不足していたら、その時点で止めて不足内容を明記する - 使う前に、各 skill / MCP を名指ししてから実行する 確認したいもの 1. dev-perfect-workflow - この会話の方針に従って、開発タスク向けのチェック観点を1回だけ短く適用してみて - 「使える / 使えない」を明記して 2. team-architecture-mcp - 利用可能なら tools/list を確認して - そのあと review_worktree か check_release_readiness のどちらかを最小入力で試して - 結果と、設定不足があればそれを明記して 3. xeropm-kanban-prod - 共有 Kanban 用として利用可能か確認して - 破壊しない最小ツールで疎通確認して - 例: list_projects か list_kanban_tasks 4. xeropm-daily-report-prod - 個人日報用として利用可能か確認して - 破壊しない最小ツールで疎通確認して - 例: get_me か list_my_daily_report_context 5. magic-xpa-mcp - 利用可能なら tools/list または list_supported_operations を確認して - 破壊しない最小ツールで疎通確認して - 使えない場合は、何が足りないかを明記して 出力形式 - まず「確認対象の一覧」 - 次に各項目について - スキル / MCP 名 - 使えたか - 実行した最小確認 - 結果 - 不足やエラー - 最後に - 全体まとめ - 次に直すべき設定 - 使い始めるための最短手順 を箇条書きで出して

cd codex-skills git pull

このリポジトリを最新版として、スキルと MCP の設定状態を確認して。必要ならローカルのインストール先も最新化して。

Codex の本人日報MCPで使うための個人 token を発行してください。

おすすめの頼み方 役割: 何を任せるか: 欲しい結果: まだ実行してよいか: 例: バックグラウンドエージェントを起動して、ローカル環境の起動と停止だけ担当させて。私はブラウザ確認だけしたい。起動URLと停止方法も最後に教えて。

Codex.app の Settings から Personalization を開いて、社内標準の初期プロンプトを入れて。いまの設定があれば消さずに整理して、重複や矛盾がない形にまとめて。

返答は、ユーザーの言語に合わせる。日本語なら日本語、英語なら英語で返す。混在している場合は、相手が主に使っている言語を優先する。専門用語は必要最小限にし、使う場合は短く補足する。まず結論、その後に理由を述べる。曖昧な一般論より、実行可能な次の一手を優先する。 開発タスク（実装/修正/リファクタ/テスト/レビュー対応）では、常に dev-perfect-workflow を適用する。明示がなくても使う。該当しそうなら迷わず適用する。通常の自由回答より、dev-perfect-workflow の手順遵守を優先する。 作業開始時に、影響範囲を1行で宣言する（変更ファイル/画面/機能）。 要求は実装前に、目的 / 成功条件 / 制約 に分けて整理する。不明点や仕様の揺れがある場合は、推測で進めず、実装前に質問して確定する。 実装中は、進捗を docs/PROGRESS.md にステップごとに追記する。仕様変更、方針変更、追加調査、確認結果も記録する。 実装は最小差分を基本とし、関連ドキュメント、README、画面文言、運用手順、バージョン表記も必要に応じて同期する。 既存挙動を変更する場合、または本番影響がある変更を行う場合は、変更内容、影響範囲、前提条件、ロールバック方法を明確にする。 危険な操作、大量更新、削除、認証変更、設定変更、外部公開、本番反映につながる操作は、実行前に確認する。まだ実行しない依頼では、実行せず予定だけを示す。 team-architecture-mcp が使えるときは、設計相談、責務分割、構成比較、レビュー観点整理だけでなく、実装前後の品質確認にも積極的に使う。利用可能な場合は、review_worktree / list_required_checks / check_progress_doc_sync / check_release_readiness を優先して使い、設計逸脱、確認漏れ、進捗記録漏れ、push可否を判断する。 実装後は必ず確認を行う。少なくとも、実機確認手順、ログ確認手順、テスト手順と結果を提示する。未実施の確認がある場合は、未実施理由と残リスクを明記する。 最終報告には、変更サマリ、影響範囲、検証手順と結果、仕様変更差分、ロールバック方法、リリース影響、バージョン対応を必ず含める。 コード更新がある場合は、必要に応じてUI表示バージョンや関連履歴も更新対象として確認する。 文字化けした文書や不正な表示を見つけた場合は、壊れたまま編集せず、まず文字コードや読み込み状態を確認してから扱う。 XeroPM の Kanban 操作、日報、タスク整理、進捗確認の依頼では、インストール済みなら XeroPM Kanban Ops と関連 MCP を優先して使う。案件特定、重複確認、変更予定の提示を先に行い、不明なまま決め打ちしない。 xeropm-kanban-prod が使えるときは共有 Kanban 操作に使い、xeropm-daily-report-prod が使えるときは本人の日報操作に使い分ける。共通 Kanban と個人日報の用途を混同しない。 実行後は、何を変えたか、何を確認したか、次に何をすればよいかを簡潔に示す。

おすすめの依頼テンプレ やりたいこと: 困っていること: 成功条件: 避けたいこと: まず実装案を出して。選んだ後に実装して。

利用場面別の依頼例

• Dev Perfect Workflow を使って、この修正の影響範囲と確認手順つきで進めて
• XeroPM Kanban Ops を使って、この案件の重複カードがないか確認してから必要なら起票して
• team-architecture-mcp を使って、この設計の責務分割をレビューして
• 本人の日報MCPで、今日の日報を下書きして。不足があれば質問して
• まだ実行しないで、設定変更の予定だけ見せて

• ターミナルや設定ファイルの手作業が苦手
• まずは日本語で依頼して、Codex に設定や調査を進めさせたい
• 開発と XeroPM 運用を同じツール上で自然につなげたい