csh/playbook
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

📦 deps(thirdparty): update snapshots

Browse Source
This commit is contained in:
ci[bot]
2026-06-29 16:09:10 +00:00
parent 90c6c04c3f
commit f7f50d9fea
314 changed files with 31913 additions and 351 deletions
Download Patch File Download Diff File Expand all files Collapse all files
antigravity-awesome-skills/skills/pre-release-review/SKILL.md
+198
View File
@@ -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."
antigravity-awesome-skills/skills/pre-release-review/references/checklist.md
+104
View File
@@ -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.
antigravity-awesome-skills/skills/pre-release-review/references/report-template.md
+91
View File
@@ -0,0 +1,91 @@
# Pre-release Review Report Template
Use this template for the final report. Translate headings to the user's language if useful, but
keep the same sections, priority labels, conclusion values, and finding fields.
## Priority definitions
- `P0` - Block release. A production deploy is likely to fail, corrupt data, expose secrets, break
compatibility, or require a missing manual action.
- `P1` - High risk, must confirm before release. Evidence suggests a production dependency,
migration, config, cache, queue, asset, or service-order risk.
- `P2` - Medium risk or ambiguous gap. Not clearly blocking, but should be checked before release
because the diff introduces uncertainty.
- `P3` - Low-risk note. Do not include P3 in the main report unless the user asks for a complete
audit log.
## Conclusion values
- `BLOCKED` - At least one P0 finding exists.
- `NEEDS_CONFIRMATION` - No P0 was found, but one or more P1/P2 items need confirmation.
- `NO_BLOCKER_FOUND` - No P0-P2 finding or release confirmation item was found from available
evidence. Neutral verification limits may still be listed separately.
## Findings versus Unable To Verify
- Put diff-linked production risks in `Findings`. Examples: a new env var whose production value
cannot be verified, a schema change with unclear migration execution, or a new queue whose
infrastructure is not confirmed.
- Any P1 or P2 finding means the conclusion is `NEEDS_CONFIRMATION` unless a P0 makes it `BLOCKED`.
- Put only neutral tool or access limits in `Unable To Verify`. Examples: remote PR access is
unavailable, deployment platform access is unavailable, or owner inference failed without a
specific release-critical change.
- If an access/tool limitation prevents confirmation of a release-critical diff change, promote it
to a P1/P2 finding instead of leaving it only in `Unable To Verify`.
## Owner inference
- Prefer `git blame` on changed lines for the file and line that caused the finding.
- If blame is unavailable or misleading, use `git log --format="%h %an %s" -- <path>`.
- If several commits contributed to the same release risk, list all relevant author names.
- Mark owners as "inferred" and do not expose email addresses.
- If no owner can be inferred, write `Unknown (not inferable from local git evidence)`.
## Secret redaction
- Never print secret values, even partially, unless the value is already a harmless placeholder such
as `example`, `changeme`, or `REDACTED`.
- Report secrets as: path, line, variable/key name, type, and redacted hint.
- Example: `config/prod.env:12` - `PAYMENT_API_KEY`, suspected API key, value redacted.
- Do not paste PEM blocks, JWTs, cookies, session IDs, private keys, passwords, certificates, or
cloud credentials into the report.
## Final report shape
```markdown
# Production Release Readiness Review
## Scope
- Range: <base>..<head> | PR <number> | latest 5 commits fallback
- Current branch: <branch>
- Head commit: <hash>
- Compared from: <tag/hash/pr-base>
- Commit count: <count>
- Dirty worktree: <yes/no and short note>
- Commands used: <short list of read-only commands>
## Conclusion
`BLOCKED` | `NEEDS_CONFIRMATION` | `NO_BLOCKER_FOUND`
## Findings
| Priority | Module | Finding | Evidence | Inferred owner | Risk | Recommended action |
| --- | --- | --- | --- | --- | --- | --- |
| P0/P1/P2 | <area/service> | <short issue> | <file:line or commit/range> | <name(s) or unknown> | <why it matters> | <release action> |
## Deployment Order / Release Actions
- <Only include when relevant. State service order, migrations, queue/cache/resource actions, and compatibility constraints.>
## Unable To Verify
- <Tooling, auth, remote, production-config, or repository limits that prevent confirmation.>
```
## Finding writing rules
- Keep each finding actionable and short.
- Include only P0-P2 or explicit confirmation risks.
- Do not include clean categories like "database OK" or "security OK".
- Use evidence-driven wording: "schema changed but no migration file changed" is better than
"maybe migration missing".
- If risk is ambiguous, say exactly what must be confirmed before release.
- If no findings exist, omit the `Findings` table and write:
`No P0-P2 release blockers or confirmation items were found from the available repository evidence.`