turntuptechnologies-ai PR 作成手順
変更をレビュー可能な PR として提出する。デフォルトブランチ（main/master）へ直接 push しないことを最優先で守る。
手順
- 作業ブランチにいることを確かめる。 デフォルトブランチ（
main/master）にいるなら<type>/<short-desc>（例:feat/login-form,fix/null-crash）でブランチを切る。既に作業ブランチならそのまま使う。 - 関連する変更だけをコミットする。 メッセージは Conventional Commits 形式
<type>: <要約>（feat/fix/docs/refactor/test/choreなど）。要約は命令形・簡潔に、言語はリポジトリ/Issue の慣習に合わせる。 - push して
gh pr createで PR を作る。 タイトルも Conventional Commits 形式（例:feat: ログインフォームを追加）、本文は下記テンプレ。対応する Issue があればCloses #<N>を入れる（merge 時に自動クローズ）。作成後、PR の URL を報告する。
PR 本文テンプレート
見出し構成は固定。プロ―ズ（説明文）の言語はリポジトリの慣習に合わせる。
## 概要 / Summary
<この PR が何を・なぜ変えるか。1〜3 行>
## 変更点 / Changes
- <主要な変更を箇条書き>
## テスト / Testing
- <どう動作確認したか。未実施なら理由>
Closes #<N> <!-- 対応 Issue があれば。なければ削除 -->
タイトルの良い例 / 悪い例
| ✅ 良い | ❌ 悪い | 理由 |
|---|---|---|
fix: ログイン失敗時に null 参照でクラッシュする問題を修正 |
バグ修正 |
type 無し・何のバグか不明 |
feat: CSV エクスポート機能を追加 |
feat: いろいろ更新 |
「いろいろ」は変更の主目的を表さない |
docs: README のセットアップ手順を現行コマンドに更新 |
fix: README 修正 |
ドキュメントのみの変更は docs（fix はコード挙動の修正） |
refactor: 認証処理を middleware に集約（挙動変更なし） |
feat: 認証まわり改善 |
挙動変更が無いなら refactor |
ルール・コツ
- main/master へ直接 push・直接コミットしない。 必ずブランチ → PR を経由する。
- タイトルの
typeは変更の主目的に合わせる（バグ修正はfix、機能追加はfeat、ドキュメントのみはdocs）。複数種類が混ざる場合は主目的の type を選び、迷ったら分割を検討する。 - ステージ前に
git status/git diff --stagedで意図しない変更（秘密情報・生成物）が混ざっていないか確認する。 - リポジトリにブランチ保護や PR テンプレート（
.github/PULL_REQUEST_TEMPLATE.md）があれば、それに従う。 ghの認証が無い場合はgh auth statusで確認し、ユーザーに案内する。
完了条件
以下を全て満たしたら完了。満たせない項目があれば、黙って省略せず理由を報告する。
- 現在のブランチが main/master ではない（作業ブランチで commit している）
- コミットメッセージと PR タイトルが Conventional Commits 形式（
<type>: <説明>） - push 済みで、
gh pr createが成功し PR の URL を報告した - 対応 Issue がある場合、PR 本文に
Closes #Nが入っている - PR 本文にテンプレの見出し（概要/変更点/テスト）が揃っている
補足
- 社名・内部 URL・認証情報などの固有情報はコミット/PR 本文に書かない。