# Pre Pr Review > Unified pre-PR quality gate. Orchestrates commit-check + convention-check + Flutter verification and saves a Markdown report. Trigger on "pre-pr-review", "/pre-pr-review", "review trước PR", "chạy pre-pr-review", "PR前チェック", "PR前レビュー". - Skill: `tungnh-expand/pre-pr-review` (Agent Skill) - Install (CLI): `npx skillmds@latest add tungnh-expand/pre-pr-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/tungnh-expand/pre-pr-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: tungnh-expand (https://skillmd.com/u/tungnh-expand) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/tungnh-expand/pre-pr-review --- # Pre-PR Review (Flutter / mobile ttp) **MANDATORY: Before doing anything, read these three files in full:** 1. `.claude/skills/commit-check/SKILL.md` — commit message rules 2. `.claude/skills/convention-check/SKILL.md` — Dart code convention rules (Rules 1–6) 3. This file — orchestration workflow and report template **Never generate the report from memory.** **IMPORTANT — no AI attribution:** The review report MUST NOT mention AI, Claude, an LLM, or automated generation in any form. Do NOT add lines such as "Generated with Claude", co-authored-by trailers, or any tool credit. The report MUST read as if written by a human reviewer. --- ## Step 1 — Determine the base branch ### 1a — Validate the current branch name ```bash git rev-parse --abbrev-ref HEAD ``` **Flag as 要修正** if the branch name starts with `feat/` — the correct prefix is `feature/`. Example: `feat/TTP_VN-1417` → must be renamed to `feature/TTP_VN-1417`. Other prefixes (`fix/`, `hotfix/`, `bugfix/`, `refactor/`, `chore/`, `docs/`, `test/`, `release/`) are acceptable. ### 1b — Get the base branch If the user did not specify a target branch, ask: > "このブランチの派生元ブランチは何ですか？（例: develop）" Then get the commit list: ```bash git log $(git merge-base HEAD )..HEAD --oneline ``` Show the commit list to the user before proceeding. **If a PR number is given instead:** ```bash git log --merges --all | grep "" git diff ^1 ``` --- ## Step 2 — Get the full diff ```bash git diff $(git merge-base HEAD ) ``` Only flag lines starting with `+` (additions/modifications). Context lines and `-` removals are out of scope. Get the file list too: ```bash git diff $(git merge-base HEAD ) --name-only ``` --- ## Step 3 — Run convention checks Apply the **commit-check rules** from `.claude/skills/commit-check/SKILL.md` to all commits. Apply the **convention-check rules** (Rules 1–6) from `.claude/skills/convention-check/SKILL.md` to all changed files. Skip generated files as defined in that skill. Check all rules simultaneously against the diff. For each violation record: - File path and line number - The offending snippet (one line) - A concrete fix suggestion (not "rename this" — say exactly what to change) **Only flag lines the diff adds or modifies.** If a nearby unchanged line is egregious and the author could reasonably fix it in the same PR, mention it in 検討. --- ## Step 4 — Flutter verification Run each command and record the result: ```bash flutter analyze flutter test flutter build ios --simulator --no-codesign ``` If `flutter test` has prerequisites or takes too long, note it and skip — document in the report. --- ## Step 5 — Produce the report Output the report in **two sections: Japanese first, then Vietnamese**. See the report format below. --- ## Step 6 — Save the result Get the current branch name and sanitize it for use as a filename (replace `/` with `-`): ```bash git rev-parse --abbrev-ref HEAD # e.g. feature/TTP_VN-1417 → feature-TTP_VN-1417 ``` Filename: `PR__pre-pr-review_.md` Example: `PR_feature-TTP_VN-1417_pre-pr-review_20260527.md` Save the full report (both JP and VN sections) to `.claude/output/`: ```bash mkdir -p .claude/output ``` --- ## Priority levels - **要修正 / Cần sửa** — clear, unambiguous violations: wrong casing, prohibited abbreviation, dead code, WHAT comment, malformed commit message, missing required documentation - **検討 / Xem xét** — judgment calls: borderline abbreviations (`auth`, `config`), names that may be valid given domain knowledge, optional documentation candidates When in doubt, prefer 検討 over 要修正. The author knows the codebase. --- ## Report format ### Japanese version ```markdown # コードレビュー結果 **ブランチ:** `` → `` **対象:** commits, files **判定:** 要修正 件 / 検討 件 | 優先度 | 件数 | | ------ | ---- | | 要修正 | N | | 検討 | N | ## 要修正 - [ ] **`:`** — [<カテゴリ>] - <説明と修正方法> - [ ] **`commit `** — [コミット] - <説明と修正提案> ## 検討 - [ ] **`:`** — [<カテゴリ>] - <説明> ## 問題なし - <ルール名>: OK ## 検証 - [ ] flutter analyze → OK / NG / 未実行 - [ ] flutter test → OK / NG / 未実行 (<理由>) - [ ] flutter build ios --simulator → OK / NG / 未実行 ``` カテゴリ: `命名` `コメント` `略語` `識別子` `コミット` `テスト` `ドキュメント` `ブランチ名` `改行` --- ### Vietnamese version ```markdown # Kết quả review code **Nhánh:** `` → `` **Phạm vi:** commits, files **Kết luận:** Cần sửa mục / Xem xét mục | Ưu tiên | Số mục | | ------- | ------ | | Cần sửa | N | | Xem xét | N | ## Cần sửa - [ ] **`:`** — [] - - [ ] **`commit `** — [Commit] - ## Xem xét - [ ] **`:`** — [] - ## Không có vấn đề - : OK ## Kiểm tra - [ ] flutter analyze → OK / NG / Chưa chạy - [ ] flutter test → OK / NG / Chưa chạy () - [ ] flutter build ios --simulator → OK / NG / Chưa chạy ``` Category labels: `Đặt tên` `Comment` `Viết tắt` `Định danh` `Commit` `Tài liệu` `Tên nhánh` `Cuối file` --- ## What to avoid - **Don't nitpick unchanged code.** Only review what the diff adds or modifies. - **Don't add unlisted rules.** No line-length, import-order, or style preferences beyond the defined rules. - **Don't be dogmatic on judgment calls.** Use 検討 for borderline cases. - **Don't restate the rule list.** Focus on findings — a short category label is enough. - **Don't mention AI, Claude, or automation** anywhere in the report output. --- ## Gate rule Do not create a PR if any of the following are true: - Any `要修正` item is unchecked - `flutter analyze` fails - `flutter build ios --simulator` fails