develop

name	develop
description	開発ワークフロー。計画から実装、テスト、ドキュメント、セルフレビュー、PR作成までを一貫して行う。
argument-hint	["やりたいことの概要"]

開発ワークフロー

このスキルは開発を計画からPR作成まで一貫して行います。 計画フェーズでは ultrathink を用いて深い分析を行い、見落としを最小化します。

現在のリポジトリ状態

• ブランチ: !git branch --show-current
• Git状態: !git status --short
• 直近コミット: !git log --oneline -5

フェーズ間のユーザー確認ルール

• 確認必須: Phase 1（計画）、Phase 2（ブランチ作成）、Phase 6（セルフレビュー結果の提示）、Phase 7（コミット・PR）
• 自律実行可: Phase 3（実装）、Phase 4（テスト）、Phase 5（ドキュメント）、Phase 6 内のラウンド1〜3（セルフレビュー＋自律修正）
  • ただし問題が発生した場合や判断に迷う場合はユーザーに確認すること

ワークフロー

Phase 1: 要件整理と計画 [確認必須]

1. ユーザーの要望 $ARGUMENTS を受け取る
2. CLAUDE.md のアーキテクチャセクションを参照し、関連モジュールを特定する
3. 特定した関連モジュールのソースコードを読み、現在の実装を理解する。具体的には:
   • 変更対象モジュールのソースコード全体
   • 変更対象モジュールが依存しているモジュールの公開インターフェース（関数シグネチャと呼び出し箇所）
   • 変更対象モジュールに対応する既存テストファイル
4. 過去のレビュー知見の確認: .claude/review-lessons.md が存在する場合は読み込み、今回の変更に関連するレビュー指摘パターンがないか確認する。関連するパターンがあれば、計画段階で対策を織り込む。あわせて .claude/HARNESS.md の俯瞰表に目を通し、今回の変更が既存のどの Guides / Sensors にカバーされるかを意識する（Sensors で捕捉できないリスクは計画段階で明示する）
5. 影響分析: 変更による既存機能への影響を構造的に分析する a. 呼び出し元追跡: 変更・追加する関数名で Grep し、全ての呼び出し元を列挙する b. アーキテクチャ整合性分析: CLAUDE.md のアーキテクチャセクションに記載された設計制約（層境界、状態管理ルール、依存方向等）に照らして、変更が違反しないか確認する c. 影響を受ける機能の列挙: 上記から影響を受ける可能性のあるユーザー向け機能を具体的に列挙する d. エッジケースの洗い出し: プロジェクトの /pj-checklist スキル（.claude/skills/pj-checklist/SKILL.md）が存在する場合はそのエッジケースセクションを参照し、該当するパターンがないか確認する。存在しない場合は一般的なエッジケース（nil/空値、並行処理、リソース解放、境界値）を検討する e. 通知設計: 新しい silent/notify 系パラメータを追加する場合、その関数が呼び出す全関数で通知呼び出し（vim.notify, log.Println 等）を Grep し、呼び出し元と呼び出し先で通知が重複しないよう責任を1箇所に決める
6. 以下の観点で計画を整理し、ユーザーに提示する:
   • 目的: 何を実現するか
   • 影響モジュール: どのファイルを変更するか（CLAUDE.md のモジュール責務と照合）
   • 実装方針: どのように実装するか（既存パターンに従う）
   • 影響分析結果: 呼び出し元、アーキテクチャ整合性、影響を受ける機能、エッジケース
   • 過去レビュー知見: 関連するパターンがあれば、対策をここに記載する
   • テスト方針: どの関数をテストするか
   • ドキュメント更新: どのドキュメントファイルを更新するか、更新する内容の概要
   • 懸念事項・リスク: 既存機能への影響、エッジケース
   • 代替案: 別のアプローチがあれば提示
7. 変更規模が大きい場合（影響モジュールが4つ以上、または新規モジュール追加を含む場合）は複数PRへの分割を提案する
8. ユーザーとの対話で計画を洗練させる（合意に至るまで繰り返す）

重要: 計画段階では絶対にコードを書かないこと。Read/Grep/Glob のみ使用する。

Phase 2: ブランチ作成 [確認必須]

計画合意後：

1. 作業ツリーの状態を確認する
   • クリーンな場合: そのまま続行
   • 未コミットの変更がある場合: 変更内容をユーザーに報告し、stash するか commit するか指示を仰ぐ。勝手に変更を破棄しないこと
2. main ブランチを最新に更新する: git fetch origin && git checkout main && git pull origin main
3. 変更の種類に応じたブランチを作成する:
   • 機能追加: feat/<簡潔な説明>
   • バグ修正: fix/<簡潔な説明>
   • リファクタリング: refactor/<簡潔な説明>
   • ドキュメント: docs/<簡潔な説明>
4. ブランチ名はユーザーに提案し、確認を取ってから作成する

Phase 3: 実装 [自律実行可]

1. 計画に従いコードを実装する
2. CLAUDE.md に記載のコーディングパターンに従うこと
3. 実装時のチェック観点:
   • 重複ロジックの検索: 新しいロジックを書く前に、既存コードに同等の処理がないか Grep で検索する。ある場合はヘルパーに抽出して再利用する
   • 新パラメータの呼び出しチェーン伝播: フラグ系パラメータ（silent, force 等）を追加した場合、その関数が内部で呼ぶ全関数を Grep で列挙し、内部関数が同種の動作（通知、確認等）を独自に行っていないか確認する。行っている場合、新パラメータを伝播するか抑制手段を用意する
   • クリーンアップパスの網羅性: 新しいリソースを作成する場合、既存のクリーンアップ関数でカバーされるか確認する
   • 非同期バリアのカウント: 並列非同期操作の完了を待つバリアパターンでは、マジックナンバーではなく操作リストから長さを導出する
   • プロジェクトの /pj-checklist スキルが存在する場合は、その実装チェックリストも適用する
4. 一連の関連する編集が完了した区切りごとに、CLAUDE.md に記載のフォーマッターでフォーマットする
5. 実装完了後、既存テストを実行して既存機能を壊していないか確認する

Phase 4: テスト [自律実行可]

1. 変更対象モジュールの既存テストファイルを読み、テストのスタイル・構造・ヘルパーの使い方を把握してから新規テストを書く
2. 新規・変更した関数に対するテストを追加する
3. テスト不要の判断基準: 以下の全てを満たす関数はテスト不要
   • 条件分岐やデータ変換を含まない
   • 外部 API を1つ呼ぶだけのラッパー
   • 戻り値の加工をしない
4. 回帰テスト確認: Phase 1 で「影響を受ける機能」として列挙した項目について、既存テストでカバーされていることを確認する。カバーされていない影響範囲がある場合は、回帰テストを追加する
5. アサーション品質の確認: テストが意図した動作を実際に検証しているか確認する
   • 機能を無効化してもテストがパスする場合、アサーションが不十分
   • テストの説明文（it(), t.Run() 等）が実際の検証内容と一致しているか確認する
6. テスト追加後、フォーマッターでフォーマットし、テストスイートを実行する

Phase 5: ドキュメント更新 [自律実行可]

CLAUDE.md に記載のドキュメントファイルそれぞれについて更新が必要か判断し、必要なものを更新する。

実装とドキュメントの双方向整合性チェック:

以下のチェックを実行する。片方向だけでは不十分で、ドキュメントにあるが実装にない（未実装の記載）と実装にあるがドキュメントにない（記載漏れ）の両方を検出する必要がある:

• キーマップ/キーバインドの双方向チェック: ドキュメント記載と実装が一致するか Grep で相互確認する
• UIテキストと動作の一致: 表示テキスト、説明文、通知メッセージが実際の動作と一致しているか
• フォーマット文字列の一致: ドキュメントの表示フォーマット記載が実装の出力と一致しているか
• 設定オプションのデフォルト値: ドキュメントの記載とコードの定義値が一致しているか
• アーキテクチャドキュメントの関数リスト: 関数の追加・削除・リネームが反映されているか

いずれのドキュメントも更新不要と判断した場合はその理由をユーザーに説明すること。

Phase 6: セルフレビュー [自律実行→結果は確認必須]

CLAUDE.md に記載の品質チェックコマンド（lint, format-check, test 等）を実行し、全てパスすることを確認する。

全チェックがパスするまで次に進まないこと。

失敗時の対応:

1. エラー内容を分析し、修正を試みる
2. 修正後、品質チェックを再実行する
3. 3回連続で失敗した場合: エラー内容をユーザーに提示し、対処方針について相談する

品質チェックをパスした後、/self-review スキルを呼び出して3ラウンドのセルフレビューを実行する。

レビュー結果をユーザーに提示する:

• 変更ファイル一覧と各ファイルの変更行数
• 各変更の概要
• セルフレビューで検出・修正した問題（あれば）
• 残っている懸念事項（あれば）

Phase 7: コミットとPR作成 [確認必須]

ユーザーの承認後、/pr スキルを呼び出してコミットとPR作成を行う。

注意事項

• 破壊的な操作（force push, reset --hard, checkout ., clean -f 等）は絶対に行わないこと
• CLAUDE.md に記載のプロジェクト固有ガイドラインに全て従うこと