開発の進め方
要望の整理からPull Requestまで、開発は一続きの仕事として扱います。顧客の声もバックログもIssueも、設計、実装、検証、文書更新も、途中で別の仕事に切り替わりません。入口はproduct:devに一本化し、迷ったら自然文で依頼します。入口を増やさない理由は単純で、どの入口を使うべきか考えること自体が手間だからです。工程ごとにSkillを分けると、その迷いが依頼のたびに発生します。
標準フロー
- Intent: 目的、利用者、完了条件、許可された外向き操作を一文で固定する
- Inspect: リポジトリの指示、現在の状態、既存のIssueとPull Request、関連する仕様と実装を確認する
- Design: 外側の価値から内側の実装へ進める
- Implement: 仕様とテストを同じ変更範囲で更新し、別件を混ぜない
- Verify: 変更範囲に必要なformat、lint、型検査、テストを実行する
- Record: コードから読めない意思決定を
.docs/へ残す - Deliver: 依頼された地点まで進めて、結果を確認する
順番には理由があります。最初の2つを飛ばして実装に入ると、並行作業の変更を上書きしたり、Issueで決まっている方針と食い違ったりするためです。
完了の定義
コードが変わっただけでは、完了と呼びません。必要な検証と成果物が揃って、はじめて完了です。テストは実装後に別の担当へ渡す後工程ではなく、実装と同時に進む検証活動で、結果が揃うまで完了にしません（テスト戦略）。実施できなかった検証、既存の失敗、残ったリスクは、成功と区別して報告します。
外向き操作の境界
Issue起票、push、Pull Request、mergeなど、リポジトリの外の状態を変える操作は、依頼された地点までに限定します。commitやパッケージの追加は手元に閉じる操作ですが、これも依頼の範囲を超えては行いません。調査、レビュー、プレビューは読み取り専用で始めます。
一方で、mergeまで明示された依頼では、承認済みの工程ごとに再確認を挟みません。確認を返すのは、結果を変える選択が未決定の場合、権限が不足する場合、依頼の対象外へ拡張が必要になった場合だけです。確認の粒度を細かくしすぎると、人間が承認を機械的に押すだけになり、確認の意味が失われます。
ブランチとworktreeの境界
primary checkout（手元の作業コピー）のブランチは切り替えません。Issueの実装はIssueごとのlinked worktreeへ隔離し、git switchやgh pr checkoutでprimary checkout自体を別ブランチへ動かしません。この境界があると、複数の作業が同じ作業コピーを取り合って壊すことがなくなります。他の人やAIが作業中の変更は、無関係な整形、削除、巻き戻しをせず保護します。
記録
コードから読めない意図、顧客の声、製品判断は.docs/へ残します（仕様書を残す）。ファイルを丸ごと再生成せず、矛盾した部分だけを更新します。CHANGELOGには、利用者にとって価値のある変更だけを記録します。