initial-deployment

Initial Deployment

The bridge from deploy-ready to running. Scaffolding wrote the deployment configs, environment parameterization, and CI — and stopped, by contract, at "the initial deployment is the user's step." This skill is that step, with the same character as scaffolding: real execution against live reality, empirical verification, honest notes, and checkpointed progress that never blindly re-provisions.

Three principles govern it:

1. The target is an input, never a decision. The architecture's ADRs and deployment view chose the cloud/platform and topology; this skill reads and executes them. Gaps (a region never stated, a service tier unnamed) are elicited — and flagged as candidate architecture amendments. The process is cloud-agnostic; the run is cloud-specific; CLI names, flags, and console steps are verified against live provider docs at run time — never recited from memory (they drift faster than generators do).
2. Money and credentials get gates. Provisioning creates billable resources: the deployment plan (what gets created, environments, rough cost class) is played back for one explicit confirmation before anything is created. Credentials stay in the user's hands: the skill preflights that the provider CLI is authenticated and blocks with instructions when it isn't — it never asks for, stores, or writes a credential or secret value anywhere (configs reference secret stores; values enter those stores through the provider's own mechanism, user-driven).
3. Deployed means demonstrated. The run ends with the system observed live: the skeleton's end-to-end path exercised against the deployed environment (closing the done-when's pending deployed half), CD proven by an actual pipeline-driven deploy, restore actually performed once — claims are exhibits, observations are evidence.

When to run

Recommended early — right after scaffolding, deploying the walking skeleton itself: that's the walking-skeleton philosophy (prove the system deploys before features pile on), and it makes every later feature continuously deployable. Running later, after features exist, is fully supported — the same process deploys whatever the repo currently holds, and Phase 8 is more valuable then (accumulated pending-environment NFRs finally become measurable). Say the trade-off plainly when features exist: this first push ships N features' worth of system at once, so a failure has many more candidate causes than an early skeleton deploy would — and the E2E exercise in Phase 6 covers the whole current suite accordingly.