| name | pr-ready |
| description | Run pre-commit checks, review PR checklist, and draft a commit message for Relay changes |
| tags | ["git","pr","lint","relay"] |
PR Ready
Get changes ready to submit as a PR. Runs lint checks, reviews the PR checklist, and drafts a commit message.
Step 1: Run pre-commit checks
cd frontend && npx --no-install lint-staged --cwd ..
This runs stylelint, prettier, eslint, black, mypy, and ruff on staged files. Fix any errors before continuing.
If any .ftl files in privaterelay/pending_locales/ were changed, also run the Fluent linter:
moz-fluent-lint privaterelay/pending_locales --config privaterelay/locales/.github/linter_config.yml
Common fix: the linter requires right single quotation marks (') instead of straight apostrophes (') in English strings.
Step 2: Review PR checklist
Inspect git diff --cached (or git diff HEAD if nothing staged) and answer each item:
- l10n: Do changes touch any user-visible strings? If yes, have they been submitted to the l10n repo?
- Tests: Does the change fix a bug? If yes, is there a unit test to prevent regression?
- Docs: Do changes affect architecture, APIs, or workflows? If yes, is
docs/ updated?
- UI: Do any UI changes follow the coding standards?
- Protocol/Nebula colors used (see
/frontend/src/styles/colors.scss)
- CSS classes use
mzp- prefix for Protocol, no prefix for custom styles
- Simple selectors, minimal nesting,
// comments in Sass
- ESLint and stylelint rules satisfied
Report the checklist status. Flag any items that need attention before the PR is submitted.
Step 3: Draft a conventional commit message
Review the staged changes and write a commit message. Do NOT run git commit.
Format:
<type>[optional scope]: <description>
[optional body]
Types: feat, fix, refactor, perf, docs, test, build, ci, chore
Style:
- Short, declarative first line
- Active verbs, concrete nouns, no adverbs
- Body explains WHY, not what
- Breaking changes: use
feat!: or feat(scope)!: + BREAKING CHANGE: footer
Present the message. Do not commit.
Step 4: Draft "How to test:" section
Write a brief testing guide for the PR reviewer. Base it on the staged changes.
Format:
How to test:
1. <setup step, if needed>
2. <action to take>
3. <what to verify>
Guidelines:
- Start with any required setup (flag, env var, account state)
- Describe the specific action a reviewer must take
- State the expected outcome — what they should see or not see
- Cover the happy path first, then edge cases if the change warrants it
Present the section. Do not open a PR.
