Menu
開発ワークフロー。計画から実装、テスト、ドキュメント、セルフレビュー、PR作成までを一貫して行う。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | develop |
| description | 開発ワークフロー。計画から実装、テスト、ドキュメント、セルフレビュー、PR作成までを一貫して行う。 |
| argument-hint | ["やりたいことの概要"] |
このスキルは開発を計画からPR作成まで一貫して行います。 計画フェーズでは ultrathink を用いて深い分析を行い、見落としを最小化します。
git branch --show-currentgit status --shortgit log --oneline -5$ARGUMENTS を受け取る.claude/review-lessons.md が存在する場合は読み込み、今回の変更に関連するレビュー指摘パターンがないか確認する。関連するパターンがあれば、計画段階で対策を織り込む。あわせて .claude/HARNESS.md の俯瞰表に目を通し、今回の変更が既存のどの Guides / Sensors にカバーされるかを意識する（Sensors で捕捉できないリスクは計画段階で明示する）/pj-checklist スキル（.claude/skills/pj-checklist/SKILL.md）が存在する場合はそのエッジケースセクションを参照し、該当するパターンがないか確認する。存在しない場合は一般的なエッジケース（nil/空値、並行処理、リソース解放、境界値）を検討する
e. 通知設計: 新しい silent/notify 系パラメータを追加する場合、その関数が呼び出す全関数で通知呼び出し（vim.notify, log.Println 等）を Grep し、呼び出し元と呼び出し先で通知が重複しないよう責任を1箇所に決める重要: 計画段階では絶対にコードを書かないこと。Read/Grep/Glob のみ使用する。
計画合意後：
git fetch origin && git checkout main && git pull origin mainfeat/<簡潔な説明>fix/<簡潔な説明>refactor/<簡潔な説明>docs/<簡潔な説明>silent, force 等）を追加した場合、その関数が内部で呼ぶ全関数を Grep で列挙し、内部関数が同種の動作（通知、確認等）を独自に行っていないか確認する。行っている場合、新パラメータを伝播するか抑制手段を用意する/pj-checklist スキルが存在する場合は、その実装チェックリストも適用するit(), t.Run() 等）が実際の検証内容と一致しているか確認するCLAUDE.md に記載のドキュメントファイルそれぞれについて更新が必要か判断し、必要なものを更新する。
実装とドキュメントの双方向整合性チェック:
以下のチェックを実行する。片方向だけでは不十分で、ドキュメントにあるが実装にない（未実装の記載）と実装にあるがドキュメントにない（記載漏れ）の両方を検出する必要がある:
いずれのドキュメントも更新不要と判断した場合はその理由をユーザーに説明すること。
CLAUDE.md に記載の品質チェックコマンド（lint, format-check, test 等）を実行し、全てパスすることを確認する。
全チェックがパスするまで次に進まないこと。
失敗時の対応:
品質チェックをパスした後、/self-review スキルを呼び出して3ラウンドのセルフレビューを実行する。
レビュー結果をユーザーに提示する:
ユーザーの承認後、/pr スキルを呼び出してコミットとPR作成を行う。
fude.nvim のローカルレビューセッションを監視し、新しいレビューコメントに自動で応答する。人間が Neovim でコメントを書くと、このセッションが検知してコード修正や返信を JSONL に追記する。「レビュー待受して」「fude watch して」等で起動する。
ハーネス点検ワークフロー。直近 PR レビューから pj-checklist の発火率と review-lessons.md の健全性を評価し、harness の改善案をユーザーに提示する。
fude.nvim プロジェクト固有の実装・レビューチェックリスト。Lua/Neovim パターン、非同期処理、state 管理の注意点。
PR レビューコメントへの対応ワークフロー。レビュー指摘の分析、コード修正、セルフレビュー、動作確認後の返信・push までを一貫して行う。
コミット分割、コミット実行、draft PR 作成を行う。
3ラウンドのセルフレビュー。プロジェクト固有チェックリスト（2ラウンド）と /review 汎用レビュー（1ラウンド）で変更品質を検証する。