docs: add commit/PR message rules and workflows #8
Conversation
- プロンプトインジェクションガードルール（日英）を新規追加 - 外部ソース（RAG、Web、API等）からの攻撃に対する多層防御を実装 - Instruction Quarantine機構による命令隔離 - SECURITY_ALERTによる攻撃検知と通知 - Cursor環境固有のファイル・ブラウザ操作制限 - 高度な攻撃（Payload Splitting、マルチモーダル、難読化）への対策 - ユーザー設定可能なセキュリティレベル（厳格/標準/開発） - 設計・脅威分析ドキュメント（日英）を追加 - README（日英）にガードレール関連ファイルの説明を追加 Refs: #improve-prompt-injection-guard
- コンテキストベース検出の運用を信頼済みソース・学習機能との連携として明記 - セキュリティレベル設定のアラート表示範囲をINFO/WARN/CRITICALで明示 - 除外判定の具体的な手がかり（署名付きドキュメント、コードブロックマーカー等）を追記
- INFO level and higher → WARN level and higher に変更 - Strict/Standard/Developmentの3段階の論理的な階層を維持 - 日本語版との整合性を確保
- .cursor/rules/prompt-injection-guard.mdc のセクション1-6で、運用ガイド参照を「2-2/2-3」から正しい「2-1/3-2」に訂正 - doc/prompt-injection-guard.md および .en.md に関連ドキュメントへの相互参照を追加 - 設計背景（custom_instruction_plan）と実装ルールへのリンクを概要セクションに記載 - 3層のドキュメント構造（設計→実装→運用）の可読性と保守性を向上
- .cursor/rules/prompt-injection-guard.en.mdc の旧セクション2（User-configurable options）を削除 - 新セクション2（Reference for user settings and operational guide）に置き換え - 運用ガイド（doc/prompt-injection-guard.en.md）への参照に統一 - 日本語版との構造的一貫性を確保
- GPT-5.1最適化の記述を日本語版に追加 - スラッシュコマンド規約の記述を削除（実際のルールに含まれていないため） - 日英両版の整合性を確保
- コミットメッセージの書式に関するガイドラインを日本語で作成 - 必須フォーマット、プレフィックス、サマリの書き方を明記 - メッセージ生成の原則や禁止事項を詳細に記述 - .gitignoreから不要なエントリを削除
- commit-message-format.mdc を言語指定・Conventional Commits 準拠の汎用ルールに整理 - README/README.en にコミットメッセージ規約の概要と参照方法を追記
- .gitignore から .cursor/commands/ の無視設定を削除 - commit-only.md などのカスタムコマンド定義をリポジトリに含める
- commit-message-format.mdc の language 記述と README の説明を微調整 - commit-only/commit-push/commit-push-pr コマンドをスタック非依存の汎用テンプレートに整理 - PR メッセージ専用ルールファイル pr-message-format.mdc を追加
- Add English commit/PR message rule files under .cursor/rules (commit-message-format.en.mdc, pr-message-format.en.mdc). - Add generic commit/PR workflow command templates under .cursor/commands (commit-only.en.md, commit-push.en.md, commit-push-pr.en.md). - Add documentation on rule/workflow separation in doc/rules-and-workflows(.en).md and link from both READMEs. - Remove prompt injection guard references from READMEs to focus on reusable rule and workflow docs.
WalkthroughこのPRは Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as 開発者
participant Shell as エディタ/CLI
participant Workflow as ワークフロー (.cursor/commands/*)
participant Rule as ルール (.cursor/rules/*.mdc)
participant Git as Git (ローカル/リモート)
participant GH as GitHub/MCP
Dev->>Shell: ワークフロー起動 (例: commit-push-pr)
Shell->>Workflow: テンプレート読み込み・引数/モード渡し
Workflow->>Rule: コミット/PR書式の検証要求
Rule-->>Workflow: バリデーション結果
alt バリデーション成功
Workflow->>Git: git add / git commit（メッセージ整形）
Workflow->>Git: git push origin/branch
Workflow->>GH: PR作成リクエスト（MCP/gh、AI生成 or 手動）
GH-->>Workflow: PR作成結果
Workflow-->>Shell: 実行結果表示
else バリデーション失敗
Workflow-->>Shell: エラーと修正指示を表示
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 注目ポイント:
Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Comment |
![windsurf-bot[bot]](https://avatars.githubusercontent.com/in/1066231?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (8)
.cursor/rules/pr-message-format.mdc (1)
36-68: テンプレート例と共に、実践的な PR メッセージ例があると一層わかりやすくなります現在のテンプレート（行40-64）は構造を示していますが、実際のコミット履歴や差分に基づいた具体的な PR メッセージ例（例えば、新機能追加時や重要なバグ修正時など）が複数あると、開発者がパターンを理解しやすくなるでしょう。テンプレートと異なるバリエーション例があれば、より実用的になる可能性があります。
doc/rules-and-workflows.en.md (1)
66-66: 英文文法の改善提案現在の "Requires Given/When/Then comments in tests" という表現は、LanguageTool による指摘の通り、より自然な表現に改善できます。以下のいずれかの形式が文法的により正確です：
- "Tests should include Given/When/Then comments"
- "Requires that tests have Given/When/Then comments"
- "Requires Given/When/Then structure in test comments"
特に上記の最初の案が、一般的で読みやすいでしょう。
修正案：
- Requires Given/When/Then comments in tests. + Tests should include Given/When/Then comments.これにより、文法的により自然で、かつ実装者にとってもわかりやすくなります。
.cursor/commands/commit-only.md (1)
19-33: git add -A の動作をより明示的に説明すると、安全性が向上します現在のテンプレートでは
git add -Aを使用していますが、このコマンドはステージング対象にすべての変更ファイル（修正・削除・新規作成を含む）を含めます。開発者によっては「意図しないファイルもステージングされてしまった」というシナリオを経験することがあります。以下のいずれかの改善が考えられます：
- 注釈で
git add -Aの動作を明示- より選別的な
git add .やgit add <file>を代替案として記載git statusで事前確認を強調特に行38-40（ステップ実行版）では
git statusとgit diffで確認してから進む設計になっており、この点は good practice です。A) 安全な一括実行版でも同様の確認プロセスをコメント化して示すと、より安全性が高まるでしょう。修正案：
### A) 安全な一括実行（メッセージ引数版） ```bash +# 注意: git add -A は修正・削除・新規作成を含むすべての変更をステージングします MSG="<Prefix>: <サマリ（命令形/簡潔に）>" \ git add -A && \ git commit -m "$MSG"または、より安全な代替案： ```diff -git add -A && \ +git add . && \あるいは、事前確認を促す注釈：
+# 1) 事前に変更内容を確認 +git status && git diff --cached + # 2) 変更をステージング git add -A.cursor/rules/pr-message-format.en.mdc (1)
40-64: テンプレート構造は明確ですが、実践的な PR メッセージ例が追加されると一層有用になります現在のテンプレート（行40-64）は構造を示していますが、実際のシナリオ別例（新機能追加、重要なバグ修正、パフォーマンス改善、大規模リファクタリングなど）が複数あると、開発者がパターンを体感しやすくなり、より実装しやすくなるでしょう。日本語版と同様に、バリエーション豊かな実例があれば、ルール適用時の判断基準がより明確になります。
.cursor/commands/commit-push.en.md (1)
23-54: フォースプッシュの可能性と既存リモートブランチの扱いについて、より明示的な説明があると安全性が向上します現在のテンプレートでは
git push -u origin <current-branch>を使用していますが、開発者によってはフォースプッシュ（git push -f）の誘惑に駆られることがあります。以下の改善が考えられます：
- コメント内で「フォースプッシュは避けるべき」という警告を明記
- 既存リモートブランチがある場合は
git pushで十分という説明git push -uオプションの動作（新規ブランチ作成時の upstream 設定）を明示特に A) 安全な一括実行版ではコマンドが簡潔なので、注釈で補足するとより safe になるでしょう。
修正案：
# Optional quality checks (only if needed) # Example: # ./scripts/lint.sh && ./scripts/test.sh && ./scripts/build.sh || exit 1 git add -A && \ git commit -m "$MSG" && \ -git push -u origin "$BRANCH" +# Note: -u flag sets upstream. For existing remote branches, use 'git push' without -u +git push -u origin "$BRANCH" +# ⚠️ Never use 'git push -f' (force push) without explicit team agreementあるいはより簡潔に：
+# For new branches: 'git push -u' sets upstream tracking +# For existing branches: 'git push' is sufficient git push -u origin "$BRANCH"README.en.md (1)
28-33: 行 28-33: 英文の連続する文頭の改善を検討してください静的解析ツールで指摘されているように、行 30-32 にかけて「If」で始まる文が3つ連続しています。読みやすさと文体のバリエーションを向上させるため、以下のように改善することをお勧めします：
現在：
2. If the path exists, save `v5.en.mdc` (English) or `v5.mdc` (Japanese) there. 3. If you also want to enforce the test strategy rules, save `test-strategy.mdc` (Japanese)... 4. To enable the commit message format rules, save `commit-message-format.mdc` (Japanese)...改善案：
2. Save `v5.en.mdc` (English) or `v5.mdc` (Japanese) in that folder. 3. To enforce the test strategy rules, also save `test-strategy.mdc` (Japanese)... 4. To enable the commit message format rules, save `commit-message-format.mdc` (Japanese)...このように改善することで、「To」という統一感のある導入句を使いながら、文頭の単調さを避けることができます。
.cursor/commands/commit-push-pr.md (1)
55-55: 行 55: Markdown 形式でのリンク表記に統一してください静的解析ツール (markdownlint) で指摘されているように、行 55 のベア URL を Markdown リンク形式に変更することをお勧めします。ドキュメント内で一貫性のある表記となります。
現在：
> 注意: MCP（Model Context Protocol）はエージェントからGitHub等の外部サービスを安全に操作するための標準プロトコルです。本手順ではPR作成にMCPのGitHub連携を使用します。利用にはMCP対応環境の設定が必要です。参考: https://modelcontextprotocol.io/改善案：
> 注意: MCP（Model Context Protocol）はエージェントからGitHub等の外部サービスを安全に操作するための標準プロトコルです。本手順ではPR作成にMCPのGitHub連携を使用します。利用にはMCP対応環境の設定が必要です。参考: [Model Context Protocol](https://modelcontextprotocol.io/)このように改善することで、リンク形式が統一され、読みやすさと保守性が向上します。
.cursor/commands/commit-push-pr.en.md (1)
57-59: 行 57-59: URL を Markdown リンク形式に変更してください静的解析ツール (markdownlint) で指摘されているように、行 58 のベア URL を Markdown リンク形式に変更することをお勧めします。
現在：
> Note: MCP (Model Context Protocol) is a standard protocol for safely allowing agents to interact with external services like GitHub. > To use it for PR creation, you will need an MCP-compatible environment and GitHub integration. See: https://modelcontextprotocol.io/改善案：
> Note: MCP (Model Context Protocol) is a standard protocol for safely allowing agents to interact with external services like GitHub. > To use it for PR creation, you will need an MCP-compatible environment and GitHub integration. See: [Model Context Protocol](https://modelcontextprotocol.io/)このように改善することで、Markdown 形式として一貫性が保たれ、可読性が向上します。
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
.cursor/commands/commit-only.en.md(1 hunks).cursor/commands/commit-only.md(1 hunks).cursor/commands/commit-push-pr.en.md(1 hunks).cursor/commands/commit-push-pr.md(1 hunks).cursor/commands/commit-push.en.md(1 hunks).cursor/commands/commit-push.md(1 hunks).cursor/rules/commit-message-format.en.mdc(1 hunks).cursor/rules/commit-message-format.mdc(1 hunks).cursor/rules/pr-message-format.en.mdc(1 hunks).cursor/rules/pr-message-format.mdc(1 hunks).gitignore(1 hunks)README.en.md(1 hunks)README.md(1 hunks)doc/rules-and-workflows.en.md(1 hunks)doc/rules-and-workflows.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
doc/rules-and-workflows.md
[uncategorized] ~79-~79: 連合関係がおかしいです。"リンクを張る"の間違いです。
Context: ...git commit/git push` など）と、その実行順序を書く。 - ルールファイルへの参照リンクを貼るが、ルールの中身を重複して書かない。 - **OSS ...
(RINKUWOHARU)
README.en.md
[style] ~30-~30: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...glish) or v5.mdc (Japanese) there. 3. If you also want to enforce the test strat...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
doc/rules-and-workflows.en.md
[style] ~66-~66: The double modal “Requires Given” is nonstandard (only accepted in certain dialects). Consider “to be Given”.
Context: ...lence and boundary cases). - Requires Given/When/Then comments in tests. - Define...
(NEEDS_FIXED)
🪛 markdownlint-cli2 (0.18.1)
.cursor/commands/commit-push-pr.md
55-55: Bare URL used
(MD034, no-bare-urls)
.cursor/commands/commit-push-pr.en.md
58-58: Bare URL used
(MD034, no-bare-urls)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (8)
.gitignore (1)
2-2: 新しいルールとコマンドをトラッキング対象に戻す適切な変更です
.cursor/commands/ディレクトリと.cursor/rules/配下の新規ルール定義ファイルをバージョン管理の対象にすることで、プロジェクト全体で一貫性のあるルール・ワークフローを共有できるようになります。コメント化は過去の文脈を保持するよい設計です。.cursor/rules/pr-message-format.mdc (1)
6-15: PR メッセージルールが包括的かつ整合的に定義されており、優れた設計ですcommit-message-format.mdc との関連性を明確に述べつつ、PR メッセージ固有の構造化要件（概要、変更内容、テクニカル詳細、テスト内容、関連Issue）を段階的に説明しています。複数プロジェクトでの再利用を想定し、language 属性や必須セクションをカスタマイズ可能に設計した点も評価できます。
.cursor/rules/commit-message-format.mdc (1)
6-77: Conventional Commits をベースにした包括的で実用的なルール定義です言語指定（language = "ja"）による複数プロジェクト対応、Prefix の明確な定義、メッセージ生成の原則（特に行60-66 で未コミット差分の確認を必須化している点）、および具体的な禁止事項（行97-102 で「検査を無効化するだけの変更」を明示的に禁止している点）が、高品質なコミット履歴の維持に貢献します。差分ベースのメッセージ生成という要件が AI にも明確に指示されており、自動化との親和性も高いです。
doc/rules-and-workflows.en.md (1)
1-49: Rules と Workflows の separation of concerns が卓越した設計で、プロジェクト全体のガバナンスを明確にしていますTerminology から Core Principles まで、段階的に概念を構築しており、読者が理解しやすい構成です。特に Principle 3（「プロジェクト固有のポリシーは Rules または README/CONTRIBUTING に住むべきで、Workflows には examples のみを記載する」）という指針が、ルールと実行フローの適切な分離を保証します。これにより、OSS 再利用時にも各プロジェクトが Rules をカスタマイズしつつ Workflows テンプレートを活用できるようになります。
.cursor/commands/commit-only.md (1)
1-6: シンプルで明確なスコープ定義のコマンドテンプレートです「コミットのみ」という限定的なスコープを明示し、ブランチ戦略やリモートプッシュは扱わないことを前置きしている点が優れています。これにより、このテンプレートを読む開発者は、このコマンドで何ができ、何ができないかが即座に理解できます。同時に、commit-message-format.mdc への参照を早期に示すことで、ルールとワークフローの関連性を明確にしています。
.cursor/rules/commit-message-format.en.mdc (1)
1-77: 日本語版と同等の品質で、英語圏の開発者にも理解しやすい包括的なルール定義ですlanguage = "en" という設定により、日本語版との並列運用が可能となります。Prefix 定義、メッセージ生成の原則、禁止事項が日本語版と consistent に保たれており、プロジェクト全体での一貫性が確保されています。特に、メッセージ生成時に未コミット差分の確認を必須化（行60-66）し、AI やスクリプト自動生成にもこの要件を適用している点が、高品質なコミット履歴の維持に貢献します。
.cursor/rules/pr-message-format.en.mdc (1)
1-83: PR メッセージの国際的な運用に対応した、包括的で実用的なルール定義です日本語版との完全な並列運用が可能となり、多言語プロジェクトでの一貫性が確保されます。特に、「Overview と Changes は通常必須だが、他のセクションはプロジェクト方針に応じてカスタマイズ可能」という柔軟性（行66-68）が、異なるプロジェクトニーズへの対応を可能にします。メッセージ生成時に実際の差分およびコミット履歴の確認を必須化（行70-76）し、意図的な情報の省略を禁止している点が、透明性と品質を確保します。
.cursor/commands/commit-push.en.md (1)
1-84: ブランチ保護とオプショナルな品質チェックを組み込んだ、バランスの取れたコマンドテンプレートですmain/master への直プッシュを防止するチェック（行28-30, 61-63）と、オプショナルな品質チェック（lint/test/build のコメント例）が含まれており、プロジェクト固有のニーズに合わせてカスタマイズしやすい設計です。「対話なし一括実行」と「ステップ実行」の 2 つのバリエーションを提供することで、開発者の好みや状況に応じた柔軟な運用が可能になります。commit-message-format.en.mdc への参照と、事前に diffs を確認する重要性を強調している点も、プロセスの透明性を確保しています。
- Fix Japanese grammar: change '貼る' to '張る' in doc/rules-and-workflows.md - Add note about here-document variable expansion (<<'EOF' vs <<EOF) in workflow files - Add clarification about branch references (main vs origin/main) in workflow files Addresses review comments #3, #4, and #5 from PR #8 Co-Authored-By: Kinopee <kinoshita@key-planning.co.jp>
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (3)
.cursor/commands/commit-push-pr.md (1)
63-79: ヒアドキュメントと変数展開の説明が適切です。63行目の
<<'EOF'で変数展開を防止し、コメント（81-82行目）で代替方法を明確に記載している点は評価できます。ユーザーが PR 本文に変数を含めたい場合に<<EOFを使うという選択肢が明確に説明されており、一貫性があります。.cursor/commands/commit-push-pr.en.md (2)
66-85: 変数展開の説明が明確で良好です。66行目の
<<'EOF'で変数展開を防止し、84〜85行目のコメントで代替方法を明確に記載している点は、ユーザーの混乱を防ぐ優れた対応です。PR本文に変数を含めたい場合に<<EOFを使うという選択肢が明確に説明されており、前のレビューコメントで指摘された懸念が既に適切に対処されています。
149-162: ブランチ参照の説明が丁寧で十分です。149〜162行目において、
git merge-base origin/main HEADでリモートの最新状態との比較を行い、一方gh pr create --base mainではローカルブランチ名を指定する理由が、162行目の詳細なコメントで明確に説明されています。"Both approaches are correct in their respective contexts" との記述により、ユーザーが両者の違いを理解しやすくなっており、前のレビューコメントで指摘された懸念が既に適切に対処されています。
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.cursor/commands/commit-push-pr.en.md(1 hunks).cursor/commands/commit-push-pr.md(1 hunks)doc/rules-and-workflows.md(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- doc/rules-and-workflows.md
🧰 Additional context used
🪛 markdownlint-cli2 (0.18.1)
.cursor/commands/commit-push-pr.en.md
58-58: Bare URL used
(MD034, no-bare-urls)
.cursor/commands/commit-push-pr.md
55-55: Bare URL used
(MD034, no-bare-urls)
🔇 Additional comments (1)
.cursor/commands/commit-push-pr.md (1)
147-159: ブランチ参照の説明が明確で良好です。147〜159行目において、
git merge-base origin/main HEADで最新のリモート状態と比較する方法が採用されています。159行目のコメントで「origin/main（リモートブランチ）」と「gh pr create --base main」の区別が丁寧に説明されており、読者の混乱を防ぐ配慮が感じられます。
Review Comments AddressedThank you for the thorough review! I've addressed the review comments as follows: ✅ Addressed CommentsComment #3 (Here-document variable expansion)
Comment #4 (Branch reference inconsistency)
Comment #5 (Japanese grammar correction)
📋 Comment Analysis (No Changes Required)Comment #2 (File naming convention)
📊 Summary
All changes have been committed and pushed to the |
Additional Review Comments AddressedI've addressed the new markdownlint warnings identified by CodeRabbit: ✅ Newly Addressed CommentsComment #6 (Bare URL in English workflow file)
Comment #7 (Bare URL in Japanese workflow file)
📊 Update Summary
Changes committed in 0eb0f29. 📋 Complete Review StatusTotal comments on PR: 8
|
- CHANGELOG(en/ja) にバージョン4.2の内容を追加 - README(en/ja) にコミット/PRルールとワークフローコマンドのサンプルを含む旨を追記
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
CHANGELOG.md (1)
6-18: バージョン4.2エントリは構造・内容ともに良好で、PR目標と一致していますが、詳細さの向上を検討してください。この変更ログエントリは全体的には構造が整然としており、PR目標の「コミット・プッシュ・PRルールの追加」および「ルール・ワークフロー分離ドキュメントの追加」を適切に反映しています。ただし、前バージョン（4.1）と比較すると、以下の点で詳細さに差があります：
ファイル名の明示: バージョン4.1では「test-strategy.mdc/en.mdc」など具体的なファイル名を列挙しており、これにより読者が変更内容を即座に把握しやすくなっています。バージョン4.2でも、以下のファイルを具体的に記載することで、より実用的な参考情報になると考えられます：
.cursor/rules/commit-message-format.mdc,.cursor/rules/commit-message-format.en.mdc.cursor/rules/pr-message-format.mdc,.cursor/rules/pr-message-format.en.mdc.cursor/commands/commit-only.*,.cursor/commands/commit-push.*,.cursor/commands/commit-push-pr.*（複数言語対応）doc/rules-and-workflows.md,doc/rules-and-workflows.en.md変更スコープの明確化: バージョン4.1では数値指標（「509行削減、425行追加」）や数語の簡潔な説明が組み込まれています。バージョン4.2でも、例えば「ワークフロー数: 3種類」といった補足があれば、変更規模を一目で理解できます。
PR目標との乖離: PR目標では「A .gitignore tweak was made to ensure .cursor/commands/ is tracked」と記載されていますが、このファイル追跡設定の変更はバージョン4.2に記載されていません。これが意図的なものであれば問題ありませんが、重要な設定変更であれば、専用項目や各セクション内での言及を検討してください。
推奨事項（オプション）: 詳細さを高めるため、各セクション内で具体的なファイルパスを追加するか、バージョン4.1のように補足指標を含めることをご検討ください。
README.en.md (1)
29-35: 使用手順のスタイルを統一すると、より読みやすくなります。現在の使用手順は、ステップ1～3では「If」で始まる条件付き構文を用いているのに対し、新しく追加されたステップ4～5では「To enable」で始まる命令形を採用しています。同じセクション内では、スタイルを統一することで、ユーザーにより一貫性のあるメッセージを伝えることができます。
以下のいずれかの方向で統一することをお勧めします：
方向1：条件付き構文で統一する場合
-4. To enable the commit message format rules, save `commit-message-format.mdc` (Japanese) and/or `commit-message-format.en.mdc` (English) under the same `.cursor/rules` folder. -5. To enable the PR message format rules, save `pr-message-format.mdc` (Japanese) and/or `pr-message-format.en.mdc` (English) under the same `.cursor/rules` folder. +4. If you also want to enforce the commit message format rules, save `commit-message-format.mdc` (Japanese) and/or `commit-message-format.en.mdc` (English) under the same `.cursor/rules` folder. +5. If you also want to enforce the PR message format rules, save `pr-message-format.mdc` (Japanese) and/or `pr-message-format.en.mdc` (English) under the same `.cursor/rules` folder.方向2：命令形で統一する場合（簡潔性重視）
-1. If `.cursor/rules` does not exist yet, create the folder. -2. If the path exists, save `v5.en.mdc` (English) or `v5.mdc` (Japanese) there. -3. If you also want to enforce the test strategy rules, save `test-strategy.mdc` (Japanese) and/or `test-strategy.en.mdc` (English) under the same `.cursor/rules` folder. +1. Create the `.cursor/rules` folder if it does not exist yet. +2. Save `v5.en.mdc` (English) or `v5.mdc` (Japanese) to that path. +3. To enforce the test strategy rules, save `test-strategy.mdc` (Japanese) and/or `test-strategy.en.mdc` (English) under the same `.cursor/rules` folder.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
CHANGELOG.en.md(1 hunks)CHANGELOG.md(1 hunks)README.en.md(1 hunks)README.md(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- CHANGELOG.en.md
🧰 Additional context used
🪛 LanguageTool
README.en.md
[style] ~31-~31: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...glish) or v5.mdc (Japanese) there. 3. If you also want to enforce the test strat...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🔇 Additional comments (7)
README.en.md (2)
37-38: 新しいドキュメント参照は適切に配置されています。ルールファイルとワークフローコマンドの責任分担を明確にする doc/rules-and-workflows.en.md への参照は、ユーザーがこのリポジトリの構造と使用パターンを正確に理解するうえで有効です。セクション配置も良好です。
39-52: ガードレール関連ファイルのドキュメントは、構成・詳細度・明確性ともに優れています。このセクションは、新しく導入される3つのmdcファイル（commit-message-format、pr-message-format、test-strategy）について、それぞれの役割（Role）と特性（Characteristics/Purpose）を系統的に説明しており、ユーザーがこれらファイルを正確に理解するのに大変有効です。
特に、各ファイルについて「役割は何か」「どのような特徴や背景があるか」を分離して記載することで、単なるファイル一覧ではなく、各ルールが存在する意味が伝わりやすくなっています。Conventional Commits への準拠、PR メッセージとコミットメッセージの整合性、テスト戦略の品質ガードレールなど、設計思想もしっかり反映されています。
README.md (5)
17-17: 「GPT-5.1 最適化」という記載について、PR目的との整合性を確認してください。このPRの主目的は、コミット/PRメッセージルールファイルとワークフローコマンドテンプレートの追加、および「ルール」と「ワークフロー」の役割分担に関するドキュメント化です。Line 17の「GPT-5.1 最適化」という記載は、このPRの主要な変更内容を直接的には反映していないように見えます。
この行が、単なるバージョン情報の更新なのか、あるいはPR内で言及すべき別の改善内容なのかを明確にしていただきたいです。もし、このバージョン情報の更新が本PRスコープ外であれば、別PRで取り扱うことを推奨します。
25-25: このリポジトリのベストプラクティス例としての位置づけが、明確に説明されています。本文で「本リポジトリ自体がベストプラクティス例として、コミットメッセージ／PRメッセージのルールファイルおよびコミット・プッシュ・PR作成のワークフローコマンドのサンプルを含んでいます」と明記することで、これ以降の「使用方法」セクションで紹介する新規ルールファイルとワークフローコマンドの意義が、ユーザーに対して一層明確に伝わります。PR目的への適合度が高く、読者にとって有用な追加です。
32-33: 使用方法の新規ステップが、既存パターンと整合性よく追加されています。コミットメッセージ規約とPRメッセージ規約の有効化手順（ステップ4～5）は、ステップ3のテスト方針ルール有効化と同じ形式で記述されており、ユーザーにとって理解しやすく、操作手順として一貫性があります。言語別オプション表記（日本語／英語）も統一されており、読者にとって親切です。
38-38: ルールとワークフローコマンドの役割分担を説明する統一的なドキュメントへの参照が、適切に追加されています。このリポジトリにおける「ルールファイル」と「ワークフローコマンド」という2種類の資産の役割分担を、
doc/rules-and-workflows.mdという統一的なドキュメントを通じて説明する仕組みは、ユーザーにとって非常に理解しやすく、PR目的である「ルールとワークフローの分離」の明確化に大きく貢献します。参考までに、この参照リンクが実際に機能するかどうか（
doc/rules-and-workflows.mdファイルの存在確認）をご確認ください。
40-53: 「ガードレール関連ファイル」セクションが、新規ルールファイルの役割と特徴を体系的に説明しています。新たに追加されたセクションは、各ガードレールファイル（コミットメッセージ形式、PRメッセージ形式、テスト方針）について、「役割」と「特徴」という2層構造で説明されており、ユーザーが各ファイルの目的と利用場面を一目で理解できる設計になっています。
特に以下の点が優れています：
- commit-message-format.mdc / .en.mdc: Conventional Commitsを基盤としながら、このリポジトリ独自のガイドライン（言語指定、差分ベースのメッセージ生成など）を含むことが明記されている
- pr-message-format.mdc / .en.mdc: コミットメッセージ規約との整合性を保ちながら、PR固有の構造化要件（Prefix付きタイトル、「概要」「変更内容」「テスト内容」など）を解説している
- test-strategy.mdc / .en.mdc: テストコードの品質ガイドラインとしての位置づけが、明確に示されている
ただし、実装ファイル側でこれら記載内容が正確に反映されているかの確認をお願いします。特に「言語指定による言語指定や差分ベースのメッセージ生成」「等価分割・境界値分析」といった具体的な機能が、実際のルールファイルに実装されているかどうかをご確認ください。
- Update link in CHANGELOG.en.md to point to rules-and-workflows.en.md instead of rules-and-workflows.md
Overview
Add commit and PR message rule files, generic workflow commands, and documentation clarifying the separation between rules and workflows.
Changes
Technical details
Tests
Related issues
Note
Adds commit/PR message rule files, generic commit/push/PR workflow commands, documentation on rules vs workflows, changelog entries, and updates .gitignore to track command files.
�.cursor/rules/commit-message-format.mdcand�.cursor/rules/commit-message-format.en.mdc.�.cursor/rules/pr-message-format.mdcand�.cursor/rules/pr-message-format.en.mdc.�.cursor/commands/commit-only(.en).md,�.cursor/commands/commit-push(.en).md,�.cursor/commands/commit-push-pr(.en).mdfor commit/push/PR flows.�doc/rules-and-workflows.mdand�doc/rules-and-workflows.en.md.�README.mdand�README.en.mdto reference rules/workflows.�CHANGELOG.mdand�CHANGELOG.en.mdwith v4.2 highlights.�.gitignoreto allow tracking of�.cursor/commands/.Written by Cursor Bugbot for commit a2909bb. This will update automatically on new commits. Configure here.
Summary by CodeRabbit
リリースノート