agentleFS
martincjarvismartincjarvis/development-skills/skills/deployment-provenance/SKILL.md

deployment-provenance

Skill4 starsChanged 10 months agoMITView on GitHub

Use when deploying software to production or staging environments to ensure complete traceability of what was deployed, when, by whom, and from which source. Essential for audit compliance, incident investigation, and rollback decisions.

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every deployment MUST capture:

    line 39

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Deployment Provenance

Overview

P0 Safety & Integrity - Deployment provenance establishes immutable traceability from running artifact back to source commit, build process, and deployment actor. Critical for audit compliance, security incident response, and confident rollback decisions.

REQUIRED: superpowers:verification-before-completion

When to Use

  • Deploying to production or staging environments
  • Setting up CI/CD pipelines for any deployable artifact
  • Investigating production incidents requiring deployment history
  • Establishing audit compliance for regulated environments
  • Enabling confident rollback decisions

Core Workflow

  1. Source Identification: Tag or record exact commit SHA deployed
  2. Build Provenance: Capture build number, pipeline, and build timestamp
  3. Artifact Signing: Sign artifacts cryptographically (optional but recommended)
  4. Deployment Recording: Log deployment timestamp, environment, and actor
  5. Artifact Labelling: Embed provenance metadata in artifact (labels, manifests)
  6. Audit Trail: Persist deployment records to immutable store
  7. Verification: Validate provenance chain before and after deployment

Provenance Record Schema

Every deployment MUST capture:

FieldDescriptionExample
commit_shaFull Git commit SHAa1b2c3d4e5f6...
branchSource branch namemain, release/1.2.0
build_idCI/CD build identifierbuild-12345
build_timestampWhen artifact was built (ISO 8601)2025-01-15T10:30:00Z
deploy_timestampWhen deployment occurred (ISO 8601)2025-01-15T11:00:00Z
environmentTarget environmentproduction, staging
actorWho/what triggered deploymentci-bot, jane.doe@example.com
artifact_digestSHA256 hash of deployed artifactsha256:abc123...
pipeline_urlLink to CI/CD pipeline runhttps://github.com/org/repo/actions/...
signatureCryptographic signature (if signed)sigstore:... or gpg:...

Implementation Patterns

Container Deployments

LABEL org.opencontainers.image.revision="${GIT_SHA}"
LABEL org.opencontainers.image.created="${BUILD_TIMESTAMP}"
LABEL org.opencontainers.image.source="${REPO_URL}"
LABEL com.example.build-id="${BUILD_ID}"
LABEL com.example.pipeline-url="${PIPELINE_URL}"

Kubernetes Deployments

metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
    app.example.com/git-sha: "${GIT_SHA}"
    app.example.com/build-id: "${BUILD_ID}"
    app.example.com/deployed-by: "${ACTOR}"
    app.example.com/deployed-at: "${DEPLOY_TIMESTAMP}"

Application Version Endpoints

Expose /version or /health endpoint returning provenance:

{
  "version": "1.2.3",
  "commit": "a1b2c3d4",
  "build": "12345",
  "built_at": "2025-01-15T10:30:00Z",
  "environment": "production"
}

Audit Trail Storage

Store deployment records in an append-only audit log:

  • Git-based: Deployment log file in ops repository
  • Database: Append-only table with deployment events
  • External: Audit systems (Splunk, CloudTrail, Azure Monitor)

Minimum retention: Follow organisational compliance requirements (typically 1-7 years).

Verification Checklist

Before deployment:

  • Commit SHA matches expected release
  • Build provenance chain intact (commit to artifact)
  • Artifact digest matches build output
  • Signature valid (if signing enabled)
  • Deployment actor authorised for target environment

After deployment:

  • Version endpoint returns expected provenance
  • Deployment event recorded in audit log
  • Rollback target identified (previous deployment record)

Red Flags - STOP

  • "We deploy from local builds" - No reproducibility or audit trail
  • "Version is just a timestamp" - Cannot trace to source code
  • "Anyone can deploy to production" - No actor accountability
  • "We don't track what's deployed" - Incident investigation impossible
  • "Rollback means redeploy latest main" - May not match previous state

All mean: Establish provenance tracking before proceeding with deployment.

Tooling Integration

PlatformProvenance Tool
GitHub ActionsBuilt-in attestations, Sigstore, SLSA
Azure DevOpsPipeline artifacts, deployment gates
GitLab CIRelease evidence, container signing
JenkinsBuild metadata plugin, artifact fingerprints
ArgoCDApplication annotations, sync status
KubernetesOCI labels, admission controllers

Related Practices

  • SLSA Framework: Supply-chain Levels for Software Artifacts
  • Sigstore: Keyless signing and verification
  • SBOM: Software Bill of Materials for dependency provenance
  • GitOps: Git as single source of truth for deployments

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.