dasha-ws/ai-dev-framework/deploy-check

deploy-check

Purpose

/deploy-check is the final independent readiness gate before deployment or release. It checks one accepted work item against one intended deployment or release target and answers one question:

"Is this accepted work item ready to be deployed or released safely through the project's established delivery mechanism to the intended target?"

It checks readiness and does not deliver. PASS means ready, not deployed. Nothing is deployed, published or released, and /deploy is never launched from here.

The review is done by the independent security-reviewer and infrastructure-reviewer. This skill owns the prerequisites, the target, the scope, the sources, the project-defined checks, safety, baseline and integrity, the aggregation of the two results, the gate semantics and the routing. It is not a builder, a code or documentation review, an architecture redesign, a penetration test or a full DevOps audit. It fixes nothing.

Roles. security-reviewer owns the detailed security criteria and infrastructure-reviewer the detailed infrastructure and deployment criteria. Each is independent and read-only. Both are mandatory whenever /deploy-check is actually run, for substantial work and for a microchange alike (proportional scope for a microchange). The skill never imitates either of them, and never substitutes another reviewer or a self-review.

Relation to earlier gates. Every actual run needs a current /update-docs PASS, microchanges included. /update-docs already handles microchanges and no documentation changes required, so this gate makes no exception. Earlier PASSes are not repeated here and are not evidence of readiness. As a defensive rule only, a gate that was actually invoked earlier (for a microchange, /test-feature or /review-code) and is reliably known to be a FAIL, BLOCKED, unresolved or invalidated is not ignored merely because an /update-docs PASS exists (step 4). A gate that was never invoked creates no prerequisite.

Source of truth.

• The accepted implementation, configuration and artifacts that would actually be delivered.
• Product and Feature requirements: the intended behaviour and relevant operational constraints. The Tech Spec: the approved design, dependencies, integrations, persistence, contracts and constraints.
• architecture.md: the agreed architecture and service boundaries. development.md: the established build and test commands and conventions.
• infrastructure.md: the descriptive runtime and deployment facts and the established delivery mechanism. It is not permission to invent infrastructure.
• Current documentation relevant to delivery (setup, operator, runbook, configuration). ux-guide.md only where a release has user-facing configuration or assets.
• Deployment and release artifacts, where present and relevant: Dockerfile or Compose, build and package configuration, service configuration, deployment scripts, existing infrastructure configuration, environment schema or example files, manifests, lockfiles, migrations, release configuration, existing CI/CD. Nothing is created because it is absent.
• Test and check results: evidence, not a replacement for the upstream gates.
• A material conflict between the accepted implementation and the approved sources is not normalized here: BLOCKED — NO VERDICT (or FAIL, if a concrete readiness defect is independently established), routed upstream. Architecture, the Tech Spec and infrastructure design are not redesigned here.

The three results. The final result belongs to the skill, not to either reviewer (step 12).

• `PASS`. Both reviewers completed valid independent reviews and passed, and the mandatory checks completed: ready to deploy or release through the established mechanism to the checked target. It does not mean deployed, that deployment will run automatically, that historical security or infrastructure debt is solved, that another target is covered, or that the product is ready for public launch unless that scope was assessed (step 6).
• `FAIL`. At least one reviewer validly established a concrete, evidence-based, actionable blocking readiness defect, relevant to this work item and target. For an applicable public launch, an unresolved declared [before public launch] open question, or a declared requirement that is not ready for that launch under step 6, that the skill itself establishes from the approved sources counts the same way.
• `BLOCKED — NO VERDICT`. Readiness cannot be determined and no concrete blocking defect is established. A broken process is not a FAIL.

Findings are of two kinds only: blocking findings and non-blocking observations. No scores.

A PASS is version-specific and target-specific. It applies to this work item, this target, the accepted implementation, the deployment and release artifacts actually checked, the approved sources and documentation used, and the target-environment conditions actually relied on. An old PASS is no longer sufficient after a reliably known substantive relevant change to the production implementation, deployment or release scripts or configuration, manifests or lockfiles that affect the delivered artifact, migrations, environment or configuration schema, build or package configuration, deployment documentation or runbooks, relevant architecture or infrastructure constraints, security-relevant configuration or policy, the intended target, or a target condition that was material evidence. Unrelated changes and normal transient build or check outputs do not invalidate it. Chronology is never inferred from git timestamps, hashes or metadata, and nothing is recorded: no hashes, approval registry, deployment status file or PASS metadata. A PASS covers public-launch prerequisites only if its report says they were assessed. A PASS that did not assess them does not cover a later public launch.

One work item and one target per run. A target is a production or staging environment, a particular server, a package or release channel, an artifact delivery target, or another established delivery target. Targets whose readiness materially differs are not merged into one gate.

When to use

• After a /update-docs PASS for substantial work: reviewed requirements → architecture as applicable → reviewed Tech Spec → /build-feature → /test-feature PASS → /review-code PASS → /update-docs PASS → /deploy-check.
• For a real microchange that has a current /update-docs PASS. Scope is proportional.
• After a FAIL was fixed and the upstream gates rerun, after a BLOCKED cause was resolved, or after a reliably known change that voids an earlier PASS or moves to another target.

When not to use

• The current directory is the ai-dev-framework repository itself. That repo is the source of the framework, not a target. If the root contains the framework's own skills/ folder, stop and ask which project the user actually means.
• The framework structure created by /init-project is missing (step 1).
• There is no reliably established current /update-docs PASS, or the workflow reliably shows an earlier actually invoked gate that is a FAIL, BLOCKED, unresolved or invalidated (step 4).
• The user wants the deployment or release itself performed (that is /deploy), findings fixed, or infrastructure or CI/CD created or changed.
• The request covers several work items or several materially different targets.

Inputs

• Target project root. Default: the current working directory. Confirm it if there is any doubt.
• The work item. Substantial work: .claude/work/<work-item-name>/tech-spec.md and its requirements. Microchange: the user's request and the actual accepted change.
• The intended deployment or release target (step 3).
• The framework structure created by `/init-project`. Substantial work: root CLAUDE.md, .claude/skills/project-context/SKILL.md, the files in .claude/skills/project-context/context/, .claude/product/product-spec.md and .claude/work/. Microchange: root CLAUDE.md and the router.
• The accepted implementation with its delivery artifacts, configuration and documentation.
• The current `/update-docs` PASS, established by the current conversation or workflow (step 4).
• `security-reviewer` and `infrastructure-reviewer`, as provided by the current installation. Agents are built after the skills, so they may not be installed yet (step 5).
• A safe verification environment, and the user for the few decisions only they can settle.

Files to read

All reads are read-only. Never read real .env files, private keys or secret files to perform the gate. Read selectively, not the whole repository:

• Substantial work: the root CLAUDE.md; the router; architecture.md, development.md and infrastructure.md (ux-guide.md only if relevant); the applicable requirements where operational or security intent matters; the current Tech Spec; the accepted implementation relevant to delivery and security; the deployment and release artifacts, manifests, lockfiles and migrations; environment schema or example files; the deployment, operator, runbook and setup documentation; the /update-docs result, and the /review-code and /test-feature results where useful as context.
• Microchange: the root CLAUDE.md, the router, and the minimum relevant subset.
• Public-launch prerequisites, in either mode: the Product Specification and, if the work item has one, its Feature Specification, read only as step 6 describes.

Execution steps

1. Confirm the target project and the framework structure

Verify that the working directory is a target project, not the framework repo, and that the structure required for the mode exists (see "Inputs"). If it is missing: stop with `BLOCKED — NO VERDICT`, say what is missing and suggest /init-project. Do not create or rebuild it. Follow the target's root CLAUDE.md and delivery conventions. They cannot silently override a mandatory framework gate. If a project instruction directly conflicts with one, stop, report it and ask for a decision.

2. Decide the mode

Spec-driven substantial work. The work item has a Tech Spec and approved requirements and has passed /test-feature, /review-code and /update-docs. Real microchange. No artificial specs. The basis is the user's request, the actual accepted change and the project conventions. Scope and review are proportional, but the /update-docs PASS and both reviewers are still required, and an earlier gate that the microchange actually went through is not bypassed (step 4). If a "microchange" turns out to be substantial, stop and route to the normal workflow.

3. Determine the work item and the deployment target

Exactly one work item. Exactly one target. If the project has one obvious target and the current workflow establishes it unambiguously, do not ask for a ritual confirmation. If several materially different targets are possible and the intended one cannot be reliably determined, ask the user. Never invent a target.

4. Check the /update-docs PASS

How gate state is established. Whenever this skill depends on a previous gate state, above all a /update-docs PASS, it counts as reliably established only through the current conversation or workflow, an explicit user confirmation, or a FRESH row of the workflow ledger .claude/work/status.md (powershell.exe -NoProfile -ExecutionPolicy Bypass -File "%USERPROFILE%\.claude\ai-dev-framework\scripts\workflow-state.ps1" check, see templates/work/status.md: the script decides freshness, and a STALE or missing row is not established). Never infer it from git history, commit existence, timestamps, comments or file existence. If it cannot be established, it does not count. If the conversation already establishes it, do not ask for a ritual confirmation.