新規機能開発/修正時には実装と同時にドキュメントの作成もしてPRに含めればいいのでは

新規の機能開発時、こういうふうにするといいのではというメモ

考え方として、変更に柔軟に対応できることと、

1. WIP PRを作成する
2. 開発する機能についてのドキュメントを書く（mdファイルとか）
   2. できれば同じリポジトリにあると良いと思う。cpilotを使った開発では恩恵を受けられる。
   2. wip：ドキュメントのフォーマットはどうあるべきか？
   3. 概要（機能の目的や背景）
   4. 仕様（目的を達成するために必要な情報）
   5. 仕様のソース
   3. （あれば）外部連携先
   4. 処理フロー
   4. エラー
   5. リクエストとレスポンスはopenApiがあるからここに書くと二重管理になりそう。リンクでよいか？
   6. ...
3. テストコードを書く
4. 実装コードを書く
5. PRをopenにしてレビュー依頼する
   6. レビューのルールも決めておくと良さそう。
   7. レビュー段階（それぞれの段階で引っかかるものがあればその時点でレビューを終えてコメントを返す。）
   7. まずドキュメントをレビューする（ロジックは正しいか、仕様のぬけもれはないか etc...）
   8. 次にテストコードをレビューする（ドキュメントの仕様を満たしているかをちゃんと確認できるコードがかけているか）
   8. 最後に実装コードをレビューする（ドキュメントで設計したロジックを満たせているか）
   7. その他ルール
   8. 誤字脱字は無視する（変更が前提なので割に合わない。一番最後リリース前とかで良い。酷いものでなければずっとそのままでよいかも）
   8. ...
6. レビュー対応

考えの元になっているもの
ドキュメントをPRに含めること：一流エンジニアの思考法のドキュメント書いたほうがいいアドバイスの話から
PRレビューを段階に分けること：間違いだらけの設計レビューの内容から