Pre-commit Rollout
Design and stage repository pre-commit checks that preserve partial staging, meet a latency budget, mirror mandatory CI controls, and recover cleanly when setup fails.
dolven
Updated Jul 24, 2026
Review credentials, keys, certificates, and tokens without exposing their values, then build safe rotation, exposure, rollout, and recovery plans.
A secret can sit in a vault and still be unsafe. The same value may live in CI, a vendor portal, an old runner, a log, a backup, and a workload cache. Rotation can make things worse when consumers update in the wrong order or the old credential is the only working recovery path.
This skill reviews the whole control system without asking for secret values. It reconciles issuers, stores, consumers, privileges, persistence surfaces, audit evidence, revocation, and recovery. It separates observed facts from policy, owner reports, assumptions, and unknowns. The result starts with a verdict, then provides a metadata-only inventory, lifecycle matrix, priority findings, rotation or incident plans, eight rollout phases, measurable gates, stop conditions, and closure evidence.
Use it before a planned credential rotation, after suspected exposure, during a CI/CD or cloud-access review, or before retiring an encryption or signing key. It includes a deterministic checker for the canonical JSON record. The checker validates structure and flags common credential-shaped fields and values; it does not claim that the underlying system is secure.
Input
Review a shared deploy token that appeared in three restricted workflow logs and one removed repository file. Audit data also shows unfamiliar successful authentications. The issuer supports two active versions, but a release is running and three of twelve workflow consumers are not inventoried.
Output
An incident-response verdict; preserved evidence and authority gaps; metadata-only privilege and persistence inventory; an overlap replacement sequence; per-consumer verification; old-token invalidation and monitoring; explicit stop and recovery behavior; and no claim that deleting logs or the latest file contains prior possession.
Input
Plan a PostgreSQL password rotation across two clusters, an API, a pooled worker, scheduled jobs, a migration job, and a vendor portal. The login permits one password, External Secrets refreshes hourly, and the maintenance window is 45 minutes.
Provide the decision in scope, credential classes and neutral identifiers, redacted configuration, issuer and store metadata, environment and consumer mappings, privilege and audit exports, rotation and revocation behavior, incident facts, release constraints, owners, monitoring, and recovery evidence. Do not paste credential values. The skill returns an evidence-bound verdict and plan. It does not rotate, revoke, scan, deploy, delete logs, or rewrite history unless you later approve a separate exact action with its target, blast radius, verification, stop condition, and recovery path.
The review mode, requested decision, systems and environments in scope, accountable owner, mutation authority, evidence cutoff, and whether suspected exposure or unexplained access is active.
Neutral credential identifiers, kinds, issuers, stores, environments, consumers, privileges, delivery paths, owners, rotation and expiry metadata, revocation behavior, and recovery paths. Never include a credential value.
Time-bounded policy, configuration references, access bindings, audit events, secret version metadata, deployment mappings, retention records, incident facts, and prior test results with values removed at source.
Maintenance windows, availability and data constraints, consumer restart or refresh behavior, monitoring baselines, stop conditions, backup and break-glass ownership, and rollback or forward-repair options.
SKILL.md; evidence, lifecycle, severity, rotation, and verdict rubric; human report and canonical JSON contract; read-only JSON checker; Agent Skills interface metadata
No reviews yet.
Output
A blocked or evidence-needed verdict on the proposed order; reconciled consumer and privilege gaps; atomic-cutover versus tested dual-login options; dependency sequence; authentication, authorization, job, duplicate-write, and availability checks; last safe point; stop conditions; and recovery prerequisites.
Input
Decide whether to delete a 19-month-old KMS key after automatic rotation was enabled. The key still decrypts billing data, seven-year exports, five-year backups, queue archives, and an appliance that reconnects quarterly. Only a recent staging restore is evidenced.
Output
A blocked deletion verdict; separation of logical key, backing material, grants, data keys, and decrypt dependencies; restore-evidence gaps; automatic rotation versus replacement-and-rewrap options; staged disable and observation gates; deletion-cancellation authority; and closure evidence across retained and offline data.
Creator
Hhorvex