Deployment verification

Deployment Verification

Use this skill when the code appears correct locally, but the real risk is that deployment, packaging, or environment differences may break it.

Goal

Increase success rate for shipped changes by checking that the result survives outside the local development context.

Focus on:

1. environment assumptions
2. config and secret requirements
3. file, asset, and path expectations
4. startup/runtime behavior in target-like conditions
5. differences between local and deployed execution
6. clear verification evidence

Core Rules

1. Do not assume local success means deployment success

A passing local run may hide:

• missing environment variables
• missing assets
• different working directories
• different ports/hosts/base URLs
• packaging omissions
• stale local state that production will not have

Always ask what changes when the code leaves the current machine or shell context.

2. Define the deployment target clearly

Before verifying, restate the target:

• local packaged tool
• static site build
• deployed web app
• server process
• script run in another environment
• handoff to another user/machine

If the target is unclear, the verification will also be weak.

3. Compare assumptions explicitly

Check whether the code assumes:

• local-only paths
• specific working directories
• certain environment variables already exist
• writable filesystem locations
• cached/generated files that may not exist elsewhere
• services or ports that differ by environment
• browser behavior that changes across origin/base-path settings

4. Verify assets, config, and startup paths

Deployment failures often come from non-code gaps.

Check for:

• missing static assets
• incorrect relative/absolute paths
• config files not included or not documented
• startup commands that only work in dev
• environment variables not named or documented clearly
• build outputs that were never actually tested

5. Test the closest realistic path available

Use the most deployment-like verification available in the current environment.

Examples:

• run the built artifact, not just source mode
• open the built/static output, not only the dev page
• verify the startup command actually works cleanly
• check routes, assets, and base paths through the served output

6. End with a deployment judgment, not vague confidence

Conclude with:

• verified for the stated target
• verified with caveats
• not yet verified for deployment

Minis-Specific Workflow

Shell-first verification

Use shell commands to:

• inspect startup scripts and package metadata
• verify build output exists where expected
• inspect config/env requirements
• check relative vs absolute path assumptions
• run target-like startup or packaged commands
• verify expected files are present after build or packaging

Browser-assisted verification

For web apps, verify:

• the served or built route actually loads
• assets resolve correctly
• navigation works under the deployed/base-path assumption
• visible behavior matches the release intent

Handoff awareness

On Minis, many deployment-like situations are actually handoff situations:

• another directory
• another machine
• another shell context
• another user with a different environment setup

Treat missing setup instructions or hidden assumptions as deployment risks.

Verification Sequence

Use this order:

1. Restate the deployment target.
2. List environment and startup assumptions.
3. Check config, secrets, assets, and paths.
4. Run the closest deployment-like path available.
5. Verify visible/runtime behavior.
6. Identify remaining environment-specific caveats.
7. Make a verified / caveat / not-yet-verified judgment.

Common Deployment Failure Modes

Watch for:

• code only works from one working directory
• environment variables are assumed but undocumented
• dev server behavior differs from built/static output
• missing build artifact or generated file
• asset paths break after moving to another base path
• local cache/state hides setup problems
• startup instructions are incomplete or wrong
• packaged output was never actually launched

Integration with Other Skills

• Use release-readiness before or alongside this skill when deciding whether the change is ready to ship.
• Use webapp-testing to verify built or served browser-visible behavior.
• Use finishing-a-development-branch before deployment verification if the branch is still messy.
• Use agent-security-guard if deployment checks involve secrets, external systems, or risky production actions.

Completion Checklist

Before calling deployment verification done, check:

• Is the deployment target clearly stated?
• Were environment assumptions made explicit?
• Were config, assets, and paths checked?
• Was the closest realistic deployment path tested?
• Were remaining caveats documented honestly?
• Is there a clear deployment judgment?

Response Template

• Deployment target:
• Key assumptions:
• Config/assets/path checks:
• Verification performed:
• Remaining caveats:
• Deployment judgment:
• Suggested next step:

Example Triggers

• "This works locally — verify it will also work after deployment."
• "Check whether this built output is actually ready to serve."
• "Verify that this app still works outside the dev environment."
• "Find deployment-only risks before I ship this."
• "Does this tool depend on local assumptions that will break on another machine?"