القائمة
機能開発の一気通貫ワークフロー。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Codexに専門レビュアーロールを割り当てて並列レビュー。修正は行わない。
サブエージェント1体+Codex1体の軽量クロスレビュー。普段使い向け。修正は行わない。
playwright-cliでブラウザ動作確認を標準化された手順で実施する。
機能開発の一気通貫ワークフロー。
最大6サブエージェントを並列起動し、スコアベースで集約したレビューレポートを出力する。修正は行わない。
レビュー → 修正 → 再レビューを全員LGTMが出るまで回す。デフォルトは /cross-review。
استنادا إلى تصنيف SOC المهني
| name | feature-dev |
| description | 機能開発の一気通貫ワークフロー。 |
| user_invocable | true |
ヒアリングから実装・レビュー・動作確認までを一気通貫で実行するオーケストレーションスキル。
/feature-dev [--auto]
--auto: 自動化拡張。レビュー完了後に日記・コミット＆プッシュ・worktree cleanupまで自動実行するfeature-dev開始時に、以下のタスクを全て TaskCreate で登録する。
各Phase完了時に TaskUpdate で completed にマークし、次のPhaseに進む前にタスクリストを確認する。
Phase 0: Discovery
Phase 0A: Codebase Exploration
Phase 0B: Clarifying Questions
Phase 0C: Architecture Design
Phase 1: Worktree Setup
Phase 2: Implementation + Verification
Phase 3: Browser Check (1st)
Phase 4: Review Cycle
Phase 5: Browser Check (2nd)
Phase 6: Completion Report
Phase 7: Commit & PR
--auto の場合は追加:
Phase 8: Diary
Phase 9: Cleanup
test-once → tsc → fix が通っても「完了」ではない。タスクリストを見て次の未完了Phaseに進む。
ユーザーから実装内容をヒアリングし、要件を整理する。
既存コードを深く理解する。Exploreエージェントを2-3体並列で起動し、それぞれ異なる観点で調査する。
Sサイズの変更ではスキップ可。
Phase 0Aの調査結果と要件を突き合わせ、曖昧な点を全て洗い出す。
質問をまとめてユーザーに提示し、回答を得てからPhase 0Cへ進む。 ユーザーが「任せる」と言った場合は、自分の判断を提示して明示的な確認を取る。
2-3体の code-architect 的なエージェントを並列起動し、異なるアプローチで設計案を作る。
| エージェント | フォーカス |
|---|---|
| A | 最小変更 — 既存コード最大活用、変更量最小 |
| B | クリーン設計 — 保守性・拡張性重視 |
| C | 実用バランス — 速度と品質のバランス（省略可） |
各案について以下を提示する:
おすすめ案とその理由を述べた上で、ユーザーに選択を求める。 ユーザーが事前に「承認不要」と明示している場合はおすすめ案で進行する。
/worktree-setup スキルを実行する。
add-tags, fix-sync）/worktree-setup <name> を実行.worktrees/<name> の絶対パスサブエージェントまたはエージェントチームで実装する。
parallel-agents.md のルールに従う。特にworktree環境では作業ディレクトリの絶対パス明示が必須。
実装前にフロントエンドのdev serverを起動する。TanStack Routerの routeTree.gen.ts はViteプラグインが自動生成するため、dev server起動中にルートファイルを作成すれば自動反映される。tsr generate コマンドは未使用export削除等の副作用があるため使わない。
cd <worktreeパス>/apps/frontend && pnpm dev &
オーケストレータ（自分）は実装作業をしない。 コードの読み書きはサブエージェントに委譲し、自分はPhase管理・検証・判断に専念する。自分が手を動かすと実装詳細にコンテキストが埋まり、Phase構造を見失う原因になる。エージェント失敗時のリカバリも、自分で修正するのではなく別エージェントを再起動する。
エージェントの完了報告は信用しない。以下を自分で実行する:
cd <worktreeパス> && pnpm run test-once && pnpm run tsc && pnpm run fix
さらに、新しいパラメータ・新しいロジックが実際に使われることをテストで検証する。「パラメータを受け付ける」テストだけでは不十分。「そのパラメータが計算結果に影響する」ことまで担保されているか確認し、不足していればテストを追加する。
新機能のUIコンポーネントが既存の横断的パターンに従っているか確認する。既存の類似機能と照合し、漏れがあれば対応する。
useTranslation を使っているか。翻訳ファイル（packages/i18n/locales/{ja,en}/）に名前空間が追加されているかaccessibilityLabel（Mobile）や aria-label（Web）が設定されているかdark: プレフィックスのスタイルが適用されているか全パスするまでPhase 3に進まない。
/browser-check スキルを実行する。ただしポートはworktree環境のものを使う。
並列確認: 複数画面の確認が必要な場合、サブエージェントに playwright-cli -s <session名> を使わせることで並列化できる（例: フロントエンドとmobileを同時確認）。
worktree環境ではメイン環境とポートが分離されているため、自分で起動する:
cd <worktreeパス>/apps/backend && pnpm dev &
cd <worktreeパス>/apps/frontend && pnpm dev &
apps/admin-frontend 等、他のフロントエンドアプリが確認対象に含まれる場合はそれも起動し、.env がworktreeのバックエンドポートを向いていることを確認する。
cd <worktreeパス>/apps/mobile && npx expo start --web で起動test-once → tsc → fix を通す/review-cycle スキルを実行する。
-C パスはworktreeパスを指定test-once → tsc → fix を必ず通すPhase 4の修正でリグレッションが入っていないことを確認する。
/browser-check スキルを実行（Phase 3と同じ手順）ユーザーに以下を報告する:
worktreeのブランチで:
cd <worktreeパス>
git add -A
git commit -m "<コミットメッセージ>"
git push -u origin wt/<name>
--auto でもpushは確認する）push後、PRを作成する:
cd <worktreeパス>
gh pr create --title "<PRタイトル>" --body "$(cat <<'EOF'
## Summary
<実装内容の要点を1-3行>
## Test plan
<テスト・動作確認の結果>
🤖 Generated with [Codex](https://Codex.com/Codex)
EOF
)"
--auto 指定時の追加Phase/write-diary スキルを**メインリポジトリ（worktreeではない）**で実行する。worktreeブランチに含めない。理由: 並行して複数の feature-dev を走らせた場合、日記が必ずconflictするため。
npx kill-port <APIポート> <Viteポート>
絶対に node.exe や node プロセスを直接killしないこと。Codex自身がNode.jsで動いているため自滅する。
ポートkillに失敗した場合（プロセスがロックしている等）は、その旨ユーザーに伝えてPhase 9を完了としてよい。手動対処コマンドを提示する。
/worktree-cleanup <name> を実行--auto のPhase 7-9は連続実行）playwright-cli を使う。-s <session名> で複数セッションを並列実行できるため、Phase 3/5のブラウザ確認を並列化可能。詳細は /playwright-cli スキル参照