Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
hieutrtr avatar

Pre Merge Checklist

  • 45 installs
  • 8 repo stars
  • Updated February 6, 2026
  • hieutrtr/ai1-skills

A systematic pre-merge validation checklist for Python/React PRs covering linting, type checking, coverage, migrations, and API compatibility.

About

Provides a comprehensive checklist run before approving or merging a PR, covering code quality, test coverage, docs, migration safety, API compatibility, accessibility, and bundle size. A developer uses it to ensure nothing is missed before merge.

  • Covers ruff/mypy/pytest checks, coverage, and migration safety
  • Includes API contract compatibility, accessibility, and bundle-size checks

Pre Merge Checklist by the numbers

  • 45 all-time installs (skills.sh)
  • Ranked #604 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
  • Data as of Aug 2, 2026 (Skillselion catalog sync)
npx skills add https://github.com/hieutrtr/ai1-skills --skill pre-merge-checklist

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs45
repo stars8
Last updatedFebruary 6, 2026
Repositoryhieutrtr/ai1-skills

What it does

A systematic pre-merge validation checklist for Python/React PRs covering linting, type checking, coverage, migrations, and API compatibility.

Files

SKILL.mdMarkdownGitHub ↗

Pre-Merge Checklist

When to Use

Activate this skill when:

  • Reviewing a pull request before approving
  • Preparing your own PR for merge
  • Verifying that all automated checks pass before merging
  • Auditing a PR that has been approved but not yet merged
  • Running a final validation pass after addressing review feedback

Output: Write results to pre-merge-report.md with pass/fail status for each check and blocking issues.

Do NOT use this skill for:

  • In-depth security review (use code-review-security)
  • Writing implementation code (use python-backend-expert or react-frontend-expert)
  • Architecture decisions (use system-architecture)
  • E2E test creation (use e2e-testing)

Instructions

Automated Checks (Ordered)

Run automated checks in this order. Each check must pass before proceeding to the next. Use scripts/run-all-checks.sh to execute all checks at once.

1. Linting and Formatting

Python (ruff):

# Check linting
ruff check app/ tests/

# Check formatting
ruff format --check app/ tests/

# Auto-fix (if needed before commit)
ruff check --fix app/ tests/
ruff format app/ tests/

TypeScript/React (eslint + prettier):

# Check linting
npx eslint 'src/**/*.{ts,tsx}' --max-warnings 0

# Check formatting
npx prettier --check 'src/**/*.{ts,tsx}'

# Auto-fix (if needed)
npx eslint 'src/**/*.{ts,tsx}' --fix
npx prettier --write 'src/**/*.{ts,tsx}'

Pass criteria:

  • Zero lint errors (warnings are tolerated only with justification)
  • All files formatted consistently
  • No # noqa or eslint-disable without a comment explaining why
2. Type Checking

Python (mypy):

mypy app/ --strict --no-error-summary

TypeScript:

npx tsc --noEmit

Use scripts/type-check.sh to run both in sequence with report output.

Pass criteria:

  • Zero type errors in changed files
  • No new type: ignore or @ts-ignore without justification
  • Generic types used correctly (no Any leaks)
3. Tests

Python:

pytest tests/ -q --tb=short

React:

npm test -- --run --reporter=verbose

Pass criteria:

  • All tests pass (zero failures)
  • No skipped tests without a linked issue/ticket
  • New code has corresponding tests
4. Coverage

Python:

pytest --cov=app --cov-report=term-missing --cov-fail-under=80

React:

npx vitest run --coverage --coverage.thresholds.lines=80

Pass criteria:

  • Overall coverage >= 80%
  • New code coverage >= 90%
  • No critical paths left uncovered (auth, payment, data mutation)
5. Security Scan
# Python dependencies
pip-audit --requirement requirements.txt

# npm dependencies
npm audit --audit-level=high

# Custom code scan (if code-review-security skill is available)
python scripts/security-scan.py --path app/ --output-dir ./security-results

Pass criteria:

  • No critical or high severity vulnerability in dependencies
  • No critical findings in code scan
  • All new endpoints have authentication checks

---

Manual Review Checklist

After automated checks pass, review the PR manually against these categories.

Code Quality
  • [ ] Naming: Variables, functions, and classes have clear, descriptive names
  • [ ] Functions: Each function does one thing; no function exceeds 50 lines
  • [ ] DRY: No duplicated logic that should be extracted into a shared function
  • [ ] Comments: Complex logic is documented; no commented-out code left in
  • [ ] Imports: No unused imports; imports are organized (stdlib, third-party, local)
  • [ ] Constants: No magic numbers or strings; use named constants or enums
  • [ ] Logging: New features have appropriate log statements at correct levels
Testing
  • [ ] Coverage: New code has tests (unit and/or integration as appropriate)
  • [ ] Edge cases: Tests cover happy path, error paths, and boundary conditions
  • [ ] Test names: Test names describe the scenario and expected outcome
  • [ ] Test isolation: Tests do not depend on each other or on execution order
  • [ ] No flakiness: Tests do not use hardcoded delays or environment-specific paths
  • [ ] Factories: Test data uses factories, not hardcoded fixtures
Type Safety
  • [ ] No `Any`: Return types and parameters are properly typed (no escape hatches)
  • [ ] Null safety: Optional values are handled (null checks, default values)
  • [ ] Schema validation: API inputs use Pydantic schemas (Python) or Zod (React)
  • [ ] Generic types: Collections use proper generics (list[User], not list)
Error Handling
  • [ ] Graceful errors: All error paths return meaningful messages
  • [ ] HTTP status codes: Correct codes used (404 for not found, 409 for conflict, etc.)
  • [ ] Error boundaries: React components have error boundaries for async failures
  • [ ] Retry logic: External service calls have retry with backoff (where appropriate)
  • [ ] No silent failures: Caught exceptions are logged, not silently swallowed
Backwards Compatibility
  • [ ] API contracts: No breaking changes to existing API response shapes
  • [ ] Database migrations: Migrations are reversible and non-destructive
  • [ ] Feature flags: Breaking changes are behind feature flags
  • [ ] Deprecation: Removed features have deprecation warnings in prior release
  • [ ] Configuration: No new required environment variables without documentation
Documentation
  • [ ] API docs: New endpoints are documented (OpenAPI/Swagger via FastAPI)
  • [ ] README: Setup instructions updated if new dependencies or steps added
  • [ ] Migration notes: Database migration has a description comment
  • [ ] ADR: Significant architectural decisions documented (if applicable)
Performance
  • [ ] N+1 queries: No N+1 database query patterns (use eager loading)
  • [ ] Pagination: List endpoints use cursor-based pagination
  • [ ] Indexes: New query patterns have supporting database indexes
  • [ ] Bundle size: No unnecessary large dependencies added to frontend
Accessibility
  • [ ] Semantic HTML: Correct HTML elements used (button, nav, main, etc.)
  • [ ] ARIA labels: Interactive elements have accessible labels
  • [ ] Keyboard navigation: New UI elements are keyboard-accessible
  • [ ] Color contrast: Text meets WCAG 2.1 AA contrast requirements

Use scripts/accessibility-check.sh to run automated accessibility checks.

---

Failure Protocol

When a check fails, follow this escalation path:

Automated check failure: 1. Fix the issue in the PR 2. Push the fix and re-run checks 3. Do not merge until all automated checks pass

Manual review finding: 1. Add a review comment with the finding 2. Request changes on the PR 3. Re-review after the author addresses feedback

Severity-based response:

Finding TypeActionCan Override?
Lint/format errorFix before mergeNo
Type errorFix before mergeNo
Test failureFix before mergeNo
Coverage below thresholdAdd tests or justifyYes, with tech lead approval
Security finding (critical/high)Fix before mergeNo
Security finding (medium/low)Fix or create follow-up ticketYes, with ticket reference
Accessibility violationFix or create follow-up ticketYes, with justification
Performance concernDiscuss in PR, may deferYes, with tech lead approval

Override Process

If a check must be overridden:

1. Document the reason in a PR comment explaining why the override is acceptable 2. Get explicit approval from a tech lead or senior engineer 3. Create a follow-up ticket to resolve the underlying issue 4. Add a code comment at the override point referencing the ticket

# OVERRIDE: Coverage below 80% for this module. See TICKET-1234.
# Approved by @tech-lead on 2024-01-15.
# Reason: Legacy code migration in progress; full coverage planned for Sprint 12.

Overrides are never acceptable for:

  • Critical security vulnerabilities
  • Broken tests
  • Type errors that mask bugs

Examples

Running All Checks

# Run the full check suite
./scripts/run-all-checks.sh --output-dir ./check-results

# Run only type checks
./scripts/type-check.sh --output-dir ./check-results

# Run accessibility checks
./scripts/accessibility-check.sh --output-dir ./check-results

Quick PR Review Workflow

1. Pull the branch locally 2. Run ./scripts/run-all-checks.sh --output-dir ./pr-review 3. Review the automated results file 4. Walk through the manual checklist above 5. Leave review comments or approve

Output File

Write results to pre-merge-report.md:

# Pre-Merge Report: [PR Title]

## Status: READY TO MERGE | BLOCKING ISSUES

## Automated Checks

| Check | Status | Details |
|-------|--------|---------|
| Linting (ruff) | PASS | No issues |
| Type check (mypy) | PASS | No errors |
| Tests (pytest) | PASS | 142 passed, 0 failed |
| Coverage | PASS | 85% (threshold: 80%) |
| Frontend lint | PASS | No issues |
| Frontend types | PASS | No errors |

## Manual Checks

- [x] Code follows project patterns
- [x] Tests cover new functionality
- [x] No breaking API changes
- [ ] Documentation updated (BLOCKING)

## Blocking Issues

1. README needs update for new CLI flag

## Recommendation
Address documentation before merge.

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.