opencode-skills-collection 3.1.10 → 3.1.11

package/bundled-skills/frontend-lighthouse/SKILL.md

@@ -0,0 +1,348 @@
+---
+name: frontend-lighthouse
+description: "Add a portable Lighthouse CI gate for production frontend builds with Core Web Vitals budgets, category floors, median runs, and CI artifacts."
+category: frontend
+risk: safe
+source: community
+source_repo: stareezy-1/frontend-architecture-skill
+source_type: community
+date_added: "2026-06-29"
+author: stareezy-1
+tags: [frontend, lighthouse, performance, core-web-vitals, ci]
+tools: [lighthouse, node, github-actions]
+license: "MIT"
+license_source: "https://github.com/stareezy-1/frontend-architecture-skill/blob/main/LICENSE"
+---
+
+# Frontend Lighthouse (portable performance gate)
+
+> Portable skill — readable by Claude Code, OpenCode, Codex, Cursor, Windsurf, and others.
+> This skill describes a **CI performance gate** — a Lighthouse CI config plus a workflow — not a
+> component library or a visual style. It pairs with the **frontend-seo** and
+> **frontend-architecture** skills: SEO writes the metadata, Lighthouse proves it ships fast.
+
+The goal: every pull request is **blocked unless the production build meets explicit Core Web
+Vitals budgets and category score floors**. Budgets live in **one** `lighthouserc.cjs`, runs are
+**median-of-N** so the gate doesn't flake, and the same config runs locally and in CI.
+
+## When to Use This Skill
+
+- Use when adding a Lighthouse CI performance gate to a web app.
+- Use when setting Core Web Vitals budgets for LCP, CLS, and TBT as the lab proxy for INP.
+- Use when configuring category score floors for performance, SEO, accessibility, and best practices.
+- Use when debugging flaky Lighthouse runs or making reports visible as CI artifacts.
+
+---
+
+## 0. The five core ideas
+
+1. **One config, one source of truth.** All budgets and assertions live in a single `lighthouserc.cjs`. Named constants for each budget — no magic numbers buried in assertion objects.
+2. **Gate the production build, never dev.** Lighthouse runs against `build` + `start` (the real, optimized output). Dev-server numbers are meaningless for a budget.
+3. **Median-of-N kills flakiness.** Run 3+ times and assert on the median run, so per-run jitter (cold caches, CI noise) never red-flags a healthy build.
+4. **Budgets encode Google's "good" thresholds.** LCP ≤ 2500 ms, INP ≤ 200 ms (gated via the TBT lab proxy), CLS ≤ 0.1 — the values that earn green scores, not "needs improvement".
+5. **Blocking in CI, visible as artifacts.** A GitHub Action runs the gate on every PR touching the app and uploads the HTML/JSON reports so failures are debuggable.
+
+---
+
+## 1. Files this skill adds
+
+```
+apps/web/                          (or your app root)
+├── lighthouserc.cjs               ← the gate: budgets + assertions + collect settings
+├── package.json                   ← "lhci": "lhci autorun --config=./lighthouserc.cjs"
+└── .github/workflows/lighthouse.yml  ← PR-blocking CI job (build → start → lhci → upload)
+```
+
+Plus a dev dependency: `@lhci/cli`.
+
+```bash
+pnpm add -D @lhci/cli        # or npm i -D / yarn add -D
+```
+
+---
+
+## 2. The config (`lighthouserc.cjs`)
+
+`.cjs` (CommonJS) so it loads without ESM/TS transpilation. Every budget is a **named constant**
+with a comment explaining the threshold — never a bare number inside an assertion.
+
+```js
+/**
+ * Lighthouse CI configuration — Core Web Vitals budgets for the marketing surface.
+ *
+ * Enforces Google's mobile "good" CWV thresholds:
+ *   - Largest Contentful Paint (LCP) ≤ 2500 ms
+ *   - Cumulative Layout Shift (CLS)  ≤ 0.1
+ *   - Interaction to Next Paint (INP) ≤ 200 ms
+ *
+ * INP is a *field* metric with no direct lab audit, so in the lab we gate on
+ * Total Blocking Time (TBT) — Lighthouse's recommended lab proxy — at the same
+ * budget, and assert the experimental INP audit directly as a warning where the
+ * build exposes it.
+ *
+ * Collection runs against the *production* server (build + start) on Lighthouse's
+ * default mobile (Moto G4 / slow 4G) emulation.
+ */
+
+/** The fixed port the production server is started on for the audit. */
+const PORT = 3100;
+const BASE_URL = `http://localhost:${PORT}`;
+
+/** Pages whose budgets are enforced in CI. */
+const MARKETING_URLS = [`${BASE_URL}/`];
+
+/**
+ * Core Web Vitals budgets on mobile — Google's "good" thresholds.
+ * These are the values that earn the best Lighthouse scores.
+ */
+const LCP_BUDGET_MS = 2500; // good
+const INP_BUDGET_MS = 200; // good (TBT lab proxy)
+const CLS_BUDGET = 0.1; // good
+
+module.exports = {
+  ci: {
+    collect: {
+      // Build is run separately in CI; here we only serve the production output.
+      startServerCommand: `pnpm start --port ${PORT}`,
+      startServerReadyPattern: "Ready in", // framework's "server ready" log line
+      startServerReadyTimeout: 120000,
+      url: MARKETING_URLS,
+      // Median of multiple runs keeps the gate stable against per-run jitter.
+      numberOfRuns: 3,
+      settings: {
+        // Default mobile emulation; opt into desktop via env for a second run.
+        preset:
+          process.env.LHCI_FORM_FACTOR === "desktop" ? "desktop" : undefined,
+        // Only gate the categories we care about; skip PWA category noise.
+        onlyCategories: [
+          "performance",
+          "seo",
+          "accessibility",
+          "best-practices",
+        ],
+      },
+    },
+    assert: {
+      // Median across runs is the value compared against each budget.
+      aggregationMethod: "median-run",
+      assertions: {
+        // --- Core Web Vitals budgets (the contract) ---------------------
+        "largest-contentful-paint": [
+          "error",
+          { maxNumericValue: LCP_BUDGET_MS },
+        ],
+        "cumulative-layout-shift": ["error", { maxNumericValue: CLS_BUDGET }],
+        "total-blocking-time": ["error", { maxNumericValue: INP_BUDGET_MS }],
+        // Direct INP audit where the Lighthouse build exposes it (else ignored).
+        "interaction-to-next-paint": [
+          "warn",
+          { maxNumericValue: INP_BUDGET_MS },
+        ],
+
+        // --- Category floors (target top Lighthouse scores) -------------
+        "categories:performance": ["error", { minScore: 0.9 }],
+        "categories:seo": ["error", { minScore: 0.95 }],
+        "categories:accessibility": ["error", { minScore: 0.95 }],
+        "categories:best-practices": ["error", { minScore: 0.9 }],
+      },
+    },
+    upload: {
+      // Keep reports in the CI run's filesystem; no external LHCI server.
+      target: "filesystem",
+      outputDir: "./.lighthouseci",
+    },
+  },
+};
+```
+
+**Hard rules:**
+
+- Every budget is a named constant with a unit in its name (`LCP_BUDGET_MS`) and a comment.
+- `aggregationMethod: "median-run"` is non-negotiable — single-run gates flake constantly.
+- `numberOfRuns` ≥ 3 (odd numbers give a clean median).
+- Assert on TBT for INP in the lab; treat the experimental `interaction-to-next-paint` audit as a `warn`, not an `error` (it isn't present in every Lighthouse build).
+- Keep `onlyCategories` to exactly what you gate — fewer audits, faster, less noise.
+
+---
+
+## 3. Choosing budget severity and thresholds
+
+| Audit / category            | Severity | Threshold | Why                                                   |
+| --------------------------- | -------- | --------- | ----------------------------------------------------- |
+| `largest-contentful-paint`  | `error`  | ≤ 2500 ms | Google "good" LCP                                     |
+| `cumulative-layout-shift`   | `error`  | ≤ 0.1     | Google "good" CLS                                     |
+| `total-blocking-time`       | `error`  | ≤ 200 ms  | INP lab proxy                                         |
+| `interaction-to-next-paint` | `warn`   | ≤ 200 ms  | not in all builds; don't hard-fail on a missing audit |
+| `categories:performance`    | `error`  | ≥ 0.9     | top (green) band                                      |
+| `categories:seo`            | `error`  | ≥ 0.95    | SEO is cheap to keep perfect                          |
+| `categories:accessibility`  | `error`  | ≥ 0.95    | a11y regressions must block                           |
+| `categories:best-practices` | `error`  | ≥ 0.9     | green band                                            |
+
+Use `error` for contracts that must hold and `warn` for audits that are environment-dependent or
+aspirational. **Start strict and only loosen with a recorded reason** — a budget you keep raising
+to make CI pass is a budget that no longer protects anything.
+
+---
+
+## 4. The npm script
+
+```jsonc
+// package.json
+{
+  "scripts": {
+    "lhci": "lhci autorun --config=./lighthouserc.cjs"
+  }
+}
+```
+
+`lhci autorun` runs `collect` → `assert` → `upload` in sequence. Run it locally before pushing to
+reproduce exactly what CI does:
+
+```bash
+pnpm build && pnpm lhci
+# desktop form factor:
+LHCI_FORM_FACTOR=desktop pnpm build && LHCI_FORM_FACTOR=desktop pnpm lhci
+```
+
+---
+
+## 5. The GitHub Actions workflow
+
+Runs on PRs that touch the app or the workflow itself. Builds the production output, runs the
+gate, and **always** uploads the reports (even on failure) so a red check is debuggable.
+
+```yaml
+name: Lighthouse CWV
+
+on:
+  pull_request:
+    branches: [main]
+    paths:
+      - "apps/web/**"
+      - ".github/workflows/lighthouse.yml"
+
+permissions:
+  contents: read
+
+jobs:
+  lighthouse:
+    name: Lighthouse CWV (marketing pages)
+    runs-on: ubuntu-latest
+    defaults:
+      run:
+        working-directory: apps/web
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Setup pnpm
+        uses: pnpm/action-setup@v4 # version comes from root package.json packageManager
+
+      - name: Setup Node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 22
+          cache: pnpm
+
+      - name: Install dependencies
+        working-directory: .
+        run: pnpm install --frozen-lockfile
+
+      - name: Build web app
+        run: pnpm build
+
+      # build + start the production server, run Lighthouse on mobile emulation,
+      # fail the job if any budget in lighthouserc.cjs is exceeded.
+      - name: Run Lighthouse CI
+        run: pnpm lhci
+
+      - name: Upload Lighthouse reports
+        if: always()
+        uses: actions/upload-artifact@v4
+        with:
+          name: lighthouse-reports
+          path: apps/web/.lighthouseci
+          if-no-files-found: ignore
+```
+
+**Hard rules:**
+
+- Trigger on the app path **and** the workflow file so config changes are self-testing.
+- `if: always()` on the upload step — you need the report most when the gate fails.
+- Gate on the **production** build (`pnpm build` then the `start` server in `collect`).
+- Match the CI Node/pnpm versions to the repo's pinned versions to avoid lockfile drift.
+
+---
+
+## 6. Framework adapters
+
+The config is framework-neutral except `startServerCommand` and `startServerReadyPattern`.
+
+| Framework     | `startServerCommand`                                              | `startServerReadyPattern`                   |
+| ------------- | ----------------------------------------------------------------- | ------------------------------------------- |
+| **Next.js**   | `pnpm start --port 3100` (after `next build`)                     | `"Ready in"`                                |
+| **Remix**     | `pnpm start` (serve the built app)                                | server's listening log line                 |
+| **Astro**     | `node ./dist/server/entry.mjs` (SSR) or `npx serve dist` (static) | the adapter's ready line / serve's URL line |
+| **SvelteKit** | `node build` (node adapter)                                       | `"Listening on"`                            |
+| **Vite SPA**  | `npx vite preview --port 3100`                                    | `"Local:"`                                  |
+
+For purely static output you can skip the server and point `collect.staticDistDir` at the build
+folder instead of `startServerCommand` — Lighthouse serves it internally.
+
+---
+
+## 7. Debugging failing or flaky runs
+
+- **Flaky LCP/TBT** → raise `numberOfRuns` (5), confirm `median-run`, and make sure nothing else is competing for CPU on the runner.
+- **`interaction-to-next-paint` errors** → it should be `warn`, not `error`; the audit is missing in some Lighthouse versions.
+- **"server not ready" timeout** → fix `startServerReadyPattern` to match the framework's actual ready log, and raise `startServerReadyTimeout`.
+- **Real regressions** → open the uploaded report artifact, read the failed audit's "Opportunities"/"Diagnostics", fix the cause (oversized image, render-blocking JS, layout shift from unsized media) — don't just bump the budget.
+- **Desktop vs mobile divergence** → run both form factors; mobile is the stricter gate and should be the default.
+
+---
+
+## 8. Conventions checklist (enforce in review)
+
+- [ ] All budgets are named constants with units and comments — no magic numbers in assertions.
+- [ ] Gate runs against the **production** build, never the dev server.
+- [ ] `aggregationMethod: "median-run"` with `numberOfRuns` ≥ 3.
+- [ ] CWV budgets at Google "good" thresholds (LCP ≤ 2500, TBT ≤ 200, CLS ≤ 0.1).
+- [ ] INP gated via TBT (`error`); experimental INP audit is `warn`.
+- [ ] Category floors set as `error` (perf ≥ 0.9, SEO/a11y ≥ 0.95, best-practices ≥ 0.9).
+- [ ] `onlyCategories` lists exactly the gated categories.
+- [ ] CI triggers on the app path **and** the workflow file; reports upload with `if: always()`.
+- [ ] Local `pnpm lhci` reproduces the CI run.
+- [ ] Budgets are tightened over time, loosened only with a recorded reason.
+
+---
+
+## 9. How to apply this skill
+
+**Adding the gate to a project:** install `@lhci/cli`, drop in `lighthouserc.cjs` with your URLs
+and `startServerCommand`, add the `lhci` script, and add the workflow. Run `pnpm build && pnpm lhci`
+locally to confirm it passes before opening a PR.
+
+**Adding a page to the gate:** append its URL to `MARKETING_URLS` (or a second URL array). Each URL
+is audited independently against the same budgets.
+
+**Tuning budgets:** change the named constant, not the assertion. Record why in the comment. Prefer
+fixing the regression over raising the budget.
+
+**Reviewing performance:** run the checklist in §8. The highest-value catches are a gate that runs
+against the dev server (meaningless numbers) and single-run assertions (chronic flakiness).
+
+---
+
+## Publishing / installing this skill
+
+This skill follows the Anthropic `SKILL.md` format and is portable across agents.
+
+1. Keep it under `skills/frontend-lighthouse/SKILL.md` in a public GitHub repo.
+2. Keep the frontmatter `name` and high-signal `description` — discovery indexes match against it.
+3. Install with: `npx skills add <org>/<repo> --skill "frontend-lighthouse"`.
+4. Non-`SKILL.md` agents can be pointed here from `AGENTS.md` / `CLAUDE.md`; Kiro can mirror it as a steering file.
+
+## Limitations
+
+- Lighthouse CI is a lab signal and does not replace field monitoring from real-user metrics.
+- Budgets must be tuned to the actual app route, hosting platform, and device/network assumptions.
+- A passing Lighthouse gate does not prove business-critical flows, visual correctness, or backend availability.

package/bundled-skills/pre-release-review/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: pre-release-review
+description: "Run a read-only pre-release review for deploy readiness, migrations, config, secrets, rollout order, rollback risk, and launch blockers."
+category: operations
+risk: safe
+source: community
+source_repo: chaunsin/agent-skills
+source_type: community
+date_added: "2026-06-29"
+author: chaunsin
+tags: [release, deploy-readiness, ci-cd, rollback, production]
+tools: [git, gh, rg]
+license: "Apache-2.0"
+license_source: "https://github.com/chaunsin/agent-skills/blob/master/LICENSE"
+---
+# Pre-release Review
+
+Use this skill to run a read-only production release readiness review. The goal is to reduce
+release time and coordination failures by finding missing deploy materials, unsafe ordering,
+configuration gaps, data migration gaps, and ambiguous production risks before CI/CD or manual
+release steps begin.
+
+## When to Use This Skill
+
+- Use when the user asks for a release audit, pre-release review, go-live review, or deploy readiness check.
+- Use before publishing a tag, deploying production services, or merging a release branch.
+- Use when a PR or git range may include migrations, environment changes, queues, cache behavior, object storage assets, or service contract changes.
+- Use when the user asks whether a change is safe to ship and needs a read-only risk report.
+
+## Non-negotiable rules
+
+- Do not modify source code, configs, migrations, secrets, deployment files, or generated files.
+- Do not execute migrations, clear or warm caches, upload assets, trigger CI/CD, deploy services,
+  publish tags, rotate secrets, or change remote infrastructure.
+- Produce a concise report that lists only confirmed problems and plausible risks needing
+  confirmation. Do not bury the reader in clean checklist items.
+- Sort findings from highest to lowest priority.
+- Include module, finding, evidence, inferred owner, risk, and recommended action for each item.
+- Never reveal private keys, account passwords, tokens, certificates, cookies, or full secret
+  values. Report only file path, line number, variable name, secret type, and a redacted hint.
+- If evidence is incomplete but the risk could block production, list it as a confirmation item.
+
+## Required references
+
+- Read `references/checklist.md` before analyzing findings so important release domains are not
+  skipped.
+- Read `references/report-template.md` before writing the final report so priorities, owner
+  inference, secret redaction, and output shape stay consistent.
+
+## Project guidance discovery
+
+Before interpreting the release diff, look for project-local guidance files such as `AGENTS.md` and
+`CLAUDE.md` in the repository root and relevant service directories. Read them when present so the
+review respects the user's project-specific conventions, service boundaries, release rules,
+validation expectations, ownership hints, and known operational constraints.
+
+- Treat project guidance as context for how to interpret risks, not as permission to perform
+  mutating release actions.
+- If project guidance conflicts with this skill's non-negotiable safety rules, the read-only,
+  no-secret-disclosure rules in this skill win.
+- If a relevant guidance file cannot be read, note the limitation in "Unable To Verify" only when it
+  affects the release review.
+
+## Scope selection
+
+Determine the review range before judging risk. State the chosen range in the report.
+
+1. If the user provides a pull request URL or PR number, review that PR diff first.
+   - If `gh` is available and authenticated, use read-only commands such as `gh pr view` and
+     `gh pr diff`.
+   - If the PR cannot be fetched due to missing tooling, auth, or network limits, say so and ask
+     for a local branch, patch, or explicit git range. Do not invent the PR contents.
+2. If the user provides an explicit `base..head` range, use it directly.
+3. If the user provides only a head commit, compare the previous usable release tag reachable from
+   that commit to the head commit.
+4. If the user provides no scope, compare the previous usable release tag to `HEAD`.
+5. Choose the previous usable release tag carefully:
+   - Prefer the repository's visible release-tag convention when one is obvious, such as semantic
+     versions, `v*`, or `release-*`. If tag naming is mixed, state the assumption.
+   - If `HEAD` is exactly at one or more tags, treat those as the current release point and compare
+     against the earlier reachable release tag, not `HEAD`'s own tag.
+   - If no usable previous release tag exists, review the latest 5 commits and explicitly warn that
+     this is a fallback: there is no usable previous release tag, so the audit only covers the
+     latest 5 commits; recommend a PR or tag-based range for future reviews.
+
+## Read-only evidence collection
+
+Run only safe inspection commands, adjusted to the repository and current permissions. Useful
+commands include:
+
+```bash
+git status --short
+git rev-parse --show-toplevel
+git rev-parse --abbrev-ref HEAD
+git rev-parse HEAD
+rg --files -g 'AGENTS.md' -g 'CLAUDE.md'
+git tag --merged HEAD --sort=-creatordate
+git tag --points-at HEAD
+git for-each-ref --sort=-creatordate --format="%(refname:short) %(objectname:short)" refs/tags
+git describe --tags --abbrev=0 HEAD
+git diff --name-status <base>..<head>
+git diff --stat <base>..<head>
+git log --oneline --decorate --no-merges <base>..<head>
+git diff -U3 <base>..<head> -- <path>
+git blame -L <start>,<end> -- <path>
+git log --format="%h %an %s" -- <path>
+rg -n "<pattern>" .
+```
+
+For PRs, use `gh pr view` and `gh pr diff` only when they are available and allowed. Do not bypass
+network, auth, sandbox, or approval restrictions. If a command cannot run, record the limitation in
+the report's "Unable to verify" section.
+
+## Review workflow
+
+1. Confirm the git repository root, current branch, dirty state, and selected comparison range.
+2. Collect changed file names, file status, diff stats, commit summaries, and touched services.
+3. Inspect relevant diffs rather than relying on filenames alone.
+4. Use the checklist to map changed code to production requirements:
+   - schema changes to migrations, indexes, seeds, and backfills
+   - config reads to env examples, deploy secrets, flags, and runtime config
+   - cache key or TTL changes to invalidation, prewarm, and compatibility work
+   - queue producers/consumers to topic setup, DLQ, idempotency, and deploy order
+   - asset references to object storage, CDN, templates, certificates, and permissions
+   - service contract changes to deploy sequence, backward compatibility, and rollback risk
+5. Infer owners with `git blame` on changed lines when possible; otherwise use recent `git log`
+   authors for the file or commit. Label them as inferred owners, and do not include email
+   addresses.
+6. Classify each finding as P0, P1, or P2 using `references/report-template.md`.
+7. Write the final report in the user's language when practical. Keep conclusion values exactly as
+   `BLOCKED`, `NEEDS_CONFIRMATION`, or `NO_BLOCKER_FOUND`.
+
+## Dirty worktree handling
+
+By default, review only the selected committed range. Do not silently mix uncommitted or untracked
+changes into the release diff unless the user explicitly asks to include worktree changes.
+
+- Always report whether the worktree is dirty.
+- If dirty or untracked files touch release-relevant areas such as migrations, deployment config,
+  env examples, CI/CD, secrets, cache, queues, assets, or service contracts, add a P2 confirmation
+  item saying those changes are excluded from the committed-range review and must be committed,
+  discarded, or reviewed separately before release.
+- If the user explicitly asks to include dirty worktree changes, inspect them with read-only
+  commands such as `git diff` and `git diff --name-status`, and clearly label them as uncommitted
+  evidence.
+
+## Evidence expectations
+
+Every finding should cite concrete evidence:
+
+- file path and line number when available
+- commit hash or PR reference when line evidence is not enough
+- command limitation when evidence could not be collected
+- diff relationship, such as "schema changed but no migration file changed"
+
+Do not state that something is safe just because no file matched a pattern. Use "not verified" for
+areas that cannot be confirmed from local repository evidence.
+
+## Findings versus verification limits
+
+Separate release confirmation items from neutral tool limits:
+
+- A release confirmation item is a diff-linked production risk, such as a new env var whose
+  production secret cannot be verified, a schema change with unclear migration status, or a new queue
+  whose infrastructure cannot be confirmed. Classify it as P1 or P2 and set the conclusion to
+  `NEEDS_CONFIRMATION` unless a P0 also exists.
+- An "Unable To Verify" entry is a neutral limitation, such as missing remote access or deployment
+  platform credentials when the diff does not introduce a specific release requirement. Neutral
+  limitations do not change the conclusion by themselves.
+- If a limitation blocks confirmation of a release-critical diff change, promote it to a P1/P2
+  finding rather than leaving it only in "Unable To Verify".
+- Use `NO_BLOCKER_FOUND` only when no P0-P2 findings or release confirmation items were found from
+  available evidence. The report may still include neutral verification limits.
+
+## Output rules
+
+- Show P0 and P1 findings first, then P2 confirmation items.
+- Do not list clean checklist categories.
+- Include a service deployment order section only when the diff touches multiple services,
+  asynchronous workers, migrations, queues, cache, or public contracts.
+- If no P0 blocker is found but P1/P2 confirmation items remain, use `NEEDS_CONFIRMATION`.
+- If no P0-P2 findings exist, include the reviewed range and any neutral verification limits.
+- Keep the report short enough for a release manager to act on immediately.
+
+## Limitations
+
+- This skill is read-only and does not deploy, tag, publish, run migrations, rotate secrets, or change infrastructure.
+- It can identify release risks from available evidence, but it cannot prove production state without access to the relevant deployment, secrets, database, queue, cache, or observability systems.
+- It should not replace service-owner signoff for high-risk production changes.
+
+## Test prompts
+
+Use these prompts to validate the skill behavior:
+
+- "Run a pre-release review and tell me if this production deploy has risks."
+- "Review PR #123 before release. Check migrations, configs, and cache work."
+- "This repo has no tags. Use the default strategy and audit release readiness."
+- "Check `v1.2.3..HEAD` for backend go-live blockers."

package/bundled-skills/pre-release-review/references/checklist.md

@@ -0,0 +1,104 @@
+# Pre-release Review Checklist
+
+Use this checklist to find production release risks from a PR or git diff. Report only categories
+with confirmed problems or plausible risks that need confirmation.
+
+## Database and data changes
+
+- Schema or ORM model changes without corresponding migration files.
+- New columns, enums, constraints, indexes, partitions, triggers, functions, or extensions that need
+  deploy-time DDL.
+- Destructive migrations, column renames, type changes, constraint tightening, or data rewrites
+  without backward-compatible rollout or rollback notes.
+- New required data without seed, backfill, admin setup, or one-time SQL.
+- Index changes that may lock large tables or need concurrent/online creation.
+- Query changes that depend on data shape not guaranteed in production.
+- Migration files present but not referenced by the deploy system or migration runner.
+
+## Environment and configuration
+
+- New env var, config key, feature flag, secret name, or runtime option without example/default,
+  deployment platform update, or CI/CD secret update.
+- Config key rename/removal that may break existing production variables.
+- Code that reads production-only values without validation or safe failure behavior.
+- Feature flags without documented default state, owner, rollout plan, or kill switch.
+- Docker, Kubernetes, Helm, Terraform, Railway, Vercel, GitHub Actions, or similar deploy config
+  changes that require manual environment changes.
+
+## Security and sensitive material
+
+- Private keys, tokens, passwords, certificates, cookies, `.pem`, `.key`, `.p12`, `.env`, service
+  account JSON, or cloud credentials added to the diff.
+- Logs, errors, analytics, webhooks, or traces that may expose PII, tokens, session IDs, or payment
+  data.
+- Debug endpoints, admin bypasses, permissive CORS, disabled auth, relaxed TLS, or temporary
+  development flags.
+- IAM, ACL, bucket policy, database role, queue permission, webhook signature, or API key scope
+  changes without release coordination.
+- Dependency or container changes with known security-sensitive behavior, native binaries, or
+  postinstall scripts.
+
+## Cache, CDN, and derived state
+
+- Redis key format, namespace, TTL, serialization, or value shape changes without invalidation or
+  backward compatibility.
+- Code that assumes warmed cache, precomputed data, materialized views, search indexes, or derived
+  tables exist.
+- CDN/static asset paths, cache headers, ETags, versioning, or purge requirements changed.
+- Rollout can serve mixed old/new cache values during a partial deploy.
+- Feature removal leaves stale cache keys that can revive old behavior.
+
+## Queues, events, and schedulers
+
+- New topic, queue, routing key, exchange, subscription, event type, cron job, or scheduled worker.
+- Producer and consumer contract changes without compatible deployment order.
+- Missing DLQ, retry policy, idempotency, dedupe key, or poison-message handling.
+- Worker concurrency, timeout, rate limit, or backpressure changes that may overload dependencies.
+- Event payload shape changes without versioning or old-consumer compatibility.
+
+## External services and assets
+
+- New object storage, CDN, S3, OSS, GCS, or static asset references without upload or permissions
+  confirmation.
+- Email, SMS, push, PDF, image, translation, or notification templates changed without production
+  material update.
+- Webhook URL, callback domain, redirect URI, CORS origin, OAuth app, payment provider, or third
+  party whitelist changes.
+- New cloud resource, bucket, DNS record, certificate, API product, SaaS setting, or quota need.
+- Frontend build assets depend on backend routes or config that are not deployed yet.
+
+## Service dependencies and deployment order
+
+- API contract changes affecting web, mobile, workers, indexers, schedulers, or third parties.
+- Database migration must run before or after specific service versions.
+- Worker should be paused, drained, or deployed after producers.
+- Read/write compatibility risks during rolling deploys.
+- New background jobs, queues, or cache consumers need infrastructure before application deploy.
+- Rollback would be unsafe because schema, data, cache, or queue payloads are not backward
+  compatible.
+
+## CI/CD and release automation
+
+- Workflow, Dockerfile, build script, deploy script, package manager, lockfile, or artifact path
+  changed.
+- Required build-time env var, secret, binary, system package, or runtime version changed.
+- Tag/release workflow depends on files or outputs not updated in the diff.
+- Migration, seed, asset upload, or cache purge step is manual but not documented.
+- Tests, linters, or type checks disabled or narrowed for release-critical code.
+
+## Observability and operations
+
+- New critical path without logs, metrics, traces, health checks, dashboards, or alerts.
+- Error handling changed without actionable logs or rollback signal.
+- Runbook, release checklist, incident response, or support notes missing for operational changes.
+- Kill switch, feature flag, or emergency disable path absent for risky functionality.
+- SLO, rate limit, quota, or capacity implication not addressed.
+
+## Reportable "unable to verify" cases
+
+- Remote PR diff cannot be fetched.
+- Release tag cannot be found and the audit fell back to recent commits.
+- Deployment platform config, production secrets, cloud buckets, queues, or external SaaS settings
+  are not accessible from the local repository.
+- Owner cannot be inferred from blame/log evidence.
+- Diff is too large to inspect fully within the available time or tool limits.