name

pr-readiness

description

Enterprise pre-PR readiness gate for Turbo Asset. Use before opening a pull request, or when the user asks "is this ready to ship / merge", "run the quality gate", or "check the branch before PR". Runs the lint/format/type-check quality gate and the relevant tests, delegates a security pass to the security-reviewer subagent, and returns a go/no-go punch list — done vs. still-needed. Does NOT open the PR or push unless explicitly asked.

PR readiness gate

Drive the change to a confident, reviewable state. Work the steps in order; stop and report early only if something blocks the rest. Context hygiene applies throughout: summarize command results, never paste full logs, and delegate anything noisy to a subagent.

1. Establish scope

git status and git diff --stat against the base branch (run both in one message) to see what actually changed.
Note which areas are touched: backend (src/), a packages/* workspace, frontend/, docs, or config. This decides which checks below are relevant — skip checks whose area is untouched and say so in the report.

2. Quality gate

npm run quality (lint + format:check + type-check). If it's noisy, run the pieces individually and pipe through tail for the failure summary.
If frontend/ changed, also run cd frontend && npm run lint.
Fix mechanical issues (npm run lint:fix, npm run format) rather than reporting them. Never silence errors with any/@ts-ignore; never bypass hooks (--no-verify is blocked by a repo guard anyway).

3. Tests + security — delegate in parallel

Launch both subagents in a single message so they run concurrently in their own context windows:

test-runner: the narrowest suite covering the change (npm test -- <path>); full npm test only for broad/cross-cutting changes. For UI changes, have it note whether Cypress e2e (npm run e2e) is warranted.
security-reviewer: always when the diff touches auth, the data layer, HTTP/GraphQL surfaces, file uploads, or integration connectors; skip (and say so) only for pure docs/config diffs.

Use their summaries verbatim where possible — do not re-run what they already ran.

4. Data-layer & secrets spot-checks

Confirm no secrets are staged (git diff --cached --name-only for .env, keys, tokens — the guard blocks writes, but check for files staged by other means).
Confirm new persistence code is Sequelize, not Prisma (SEQUELIZE_MIGRATION_GUIDE.md, .claude/rules/data-layer.md).

5. Docs

If commands, structure, conventions, or the API surface changed, update the relevant docs or delegate to docs-curator. Keep CLAUDE.md and .claude/rules/ consistent with the change.

6. Report — go / no-go punch list

Return a tight checklist, e.g.:

✅ Quality gate (lint / format / type-check)
✅ Tests: <scope> passing (per test-runner)
⚠️ Security: <finding + fix>, or "clean" (per security-reviewer)
➖ Skipped: — <why it doesn't apply>
❌
📝 Suggested PR title + 1–3 bullet summary

End with a clear verdict: ready to open a PR, or N items remain. Do not push or open the PR unless the user explicitly asks.

PR readiness gate

1. Establish scope

git status and git diff --stat against the base branch (run both in one message) to see what actually changed.

Note which areas are touched: backend (src/), a packages/* workspace, frontend/, docs, or config. This decides which checks below are relevant — skip checks whose area is untouched and say so in the report.

2. Quality gate

npm run quality (lint + format:check + type-check). If it's noisy, run the pieces individually and pipe through tail for the failure summary.

If frontend/ changed, also run cd frontend && npm run lint.

Fix mechanical issues (npm run lint:fix, npm run format) rather than reporting them. Never silence errors with any/@ts-ignore; never bypass hooks (--no-verify is blocked by a repo guard anyway).

3. Tests + security — delegate in parallel

Launch both subagents in a single message so they run concurrently in their own context windows:

test-runner: the narrowest suite covering the change (npm test -- <path>); full npm test only for broad/cross-cutting changes. For UI changes, have it note whether Cypress e2e (npm run e2e) is warranted.

security-reviewer: always when the diff touches auth, the data layer, HTTP/GraphQL surfaces, file uploads, or integration connectors; skip (and say so) only for pure docs/config diffs.

Use their summaries verbatim where possible — do not re-run what they already ran.

4. Data-layer & secrets spot-checks

Confirm no secrets are staged (git diff --cached --name-only for .env, keys, tokens — the guard blocks writes, but check for files staged by other means).

Confirm new persistence code is Sequelize, not Prisma (SEQUELIZE_MIGRATION_GUIDE.md, .claude/rules/data-layer.md).

5. Docs

If commands, structure, conventions, or the API surface changed, update the relevant docs or delegate to docs-curator. Keep CLAUDE.md and .claude/rules/ consistent with the change.

6. Report — go / no-go punch list

Return a tight checklist, e.g.:

✅ Quality gate (lint / format / type-check)

✅ Tests: <scope> passing (per test-runner)

⚠️ Security: <finding + fix>, or "clean" (per security-reviewer)

➖ Skipped: — <why it doesn't apply>

❌

📝 Suggested PR title + 1–3 bullet summary

End with a clear verdict: ready to open a PR, or N items remain. Do not push or open the PR unless the user explicitly asks.