agentleFS
Sign inStart free
martincjarvismartincjarvis/development-skills/skills/incremental-deployment/SKILL.md

incremental-deployment

Skill4 starsChanged 10 months agoMITView on GitHub

Use this skill when deploying to ensure only modified and impacted components are deployed, with explicit version/tag inputs and environment traceability preserved.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    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:

    Verification: Verify that only the intended components were deployed and that their versions/tags correctly reflect the source code.

    line 45
  2. Distinctive:

    Documentation: Update the environment traceability records with the new deployment details.

    line 46
  3. Distinctive:

    Must consume incremental-change-impact and release-tagging-plan outputs

    line 85
  4. Distinctive:

    If uncertainty exists, broaden scope via impact justification, not via bypass of tagging/traceability

    line 86

≈ “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

Incremental Deployment Planning

Intent

Deploy only what changed (and what is impacted), while preserving strict traceability via immutable versions and tags.

When to Use

  • Planning deployments in a monorepo with multiple components
  • Preparing environment promotion
  • Reviewing deployment scope for safety and efficiency

Precondition Failure Signal

  • Broad deployments include unrelated components
  • Deployments are triggered from branches without tags
  • Environment state cannot be explained in component version terms
  • Incremental deployments miss required dependent components

Postcondition Success Signal

  • Deployment scope matches impacted components (and required dependencies)
  • Deployments reference explicit component versions/tags
  • Environment state is traceable to deployed component versions/tags
  • Deployment plan is reproducible and reviewable

Process

  1. Source Review: Inspect the impact set produced by incremental-change-impact and the current state of the target environment.
  2. Implementation: Execute the deployment only for the identified impacted components using their specific versions/tags.
  3. Verification: Verify that only the intended components were deployed and that their versions/tags correctly reflect the source code.
  4. Documentation: Update the environment traceability records with the new deployment details.
  5. Review: Release Manager/SRE and Platform Engineer review the deployment plan and execution results.

Example Test / Validation

  • Given a change set, show only impacted components are deployed
  • Validate dependent components are included when dependency changes require it
  • Confirm environment records can list component versions/tags after deployment

Common Red Flags / Guardrail Violations

  • “Just redeploy everything to be safe”
  • Deploying from main or HEAD without a tag
  • Allowing “implicit latest” component selection
  • Changing deployment scope without updating impact assessment

Recommended Review Personas

  • Platform/DevOps Engineer – validates deployment scope and traceability
  • Tech Lead – validates correctness of impacted set and risk discipline
  • Domain Expert – validates runtime dependency assumptions

Skill Priority

P1 – Quality & Correctness
(Escalate to P0 where traceability/immutability constraints are threatened.)

Conflict Resolution Rules

  • Must consume incremental-change-impact and release-tagging-plan outputs
  • If uncertainty exists, broaden scope via impact justification, not via bypass of tagging/traceability
  • Overrides Delivery/Optimisation shortcuts that weaken traceability

Conceptual Dependencies

  • incremental-change-impact
  • release-tagging-plan

Classification

Operational
Governance

Notes

Incremental deployment is only safe when traceability is strict.

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.

Check your setup, free