Deployment selection

Skill ahtishamshahzad/agent_dev_flow/.ai/skills/devops/deployment-selection

Use to choose deployment targets per application — managed PaaS, container platform, serverless, static/edge hosting, mobile stores — based on app type, ops capacity, scaling, and cost. Evaluates rather than defaulting; a stack decision requiring approval. Does not provision infrastructure.From its SKILL.md

Install

npx -y skills add ahtishamshahzad/agent_dev_flow --skill deployment-selection

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.1 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it

Deployment Selection

Purpose

Choose where each application runs in production, matched to the app type and the team's real operational capacity — the most managed option that meets requirements — as a recorded, approval-gated decision. Provisioning and rollout mechanics are ../../backend/backend-deployment.

When to Use

After applications and stack are chosen, before building the deploy pipeline.
When re-evaluating an existing app's hosting.
Not for the rollout procedure (../../backend/backend-deployment) or provisioning infra (out of scope — no scaffolding).

Inputs

Selected applications and their runtimes (backend API, web/SSR, static site, mobile).
Ops capacity, scaling/latency needs, budget, existing infrastructure.

Discovery Questions

Per app: what is it (long-running backend, SSR web, static frontend, mobile) and what does it need (persistent processes, edge, workers)?
What is the team's ops capacity — can they run containers/orchestration, or is managed strongly preferred?
Scaling profile and budget? Existing cloud/platform commitments?

Responsibilities

Match each application to candidate targets:
- Backend API / workers → managed PaaS, container platform, or serverless — factoring persistent connections, background workers/queues (../../backend/queues), and cold-start tolerance.
- Web / SSR → SSR-capable host / edge platform; static frontends → static/CDN/edge hosting.
- Mobile → app stores via the mobile pipeline (../../mobile/mobile-release) — not a server host.
- Database → managed database service (pairs with ../../database/backup-recovery), not self-hosted unless justified.
Prefer the most managed option that meets requirements — ops burden is a permanent cost; justify any move toward self-managed.
Record decisions with trade-offs (cost, scale, lock-in, ops) for approval (Gate 2); note what would flip each.
Feed targets to ci-cd/github-actions (deploy jobs), docker-foundation (if containerized), staging-environment, and production-readiness.

Required Workflow

Classify each app by type + runtime needs.
Shortlist targets per app; weigh ops capacity + scale + cost.
Recommend the most-managed sufficient option per app with trade-offs.
Record for approval; note flip conditions.
Hand off to pipeline + readiness skills.

Decision Rules

Most managed that meets the need — reach for containers/orchestration only when requirements demand the control.
Serverless suits spiky/stateless workloads but weighs cold starts and persistent-connection limits (realtime, long jobs) — check against the app's needs.
Static frontends don't belong on always-on servers; backends with workers don't fit pure static/edge.
Target changes are stack decisions — approval required; no lock-in without acknowledging it.

Rules

Recommend, don't pre-provision; user approves at Gate 2.
No infrastructure scaffolding here.
Each app's target justified against its type + ops reality.

Anti-Patterns

One target forced onto every app regardless of type.
Self-managed Kubernetes for a team without ops capacity.
Serverless for a persistent-connection/long-job workload without weighing limits.
Static site on an always-on VM; backend workers on a static host.
Choosing a target before knowing ops capacity.

Validation Checklist

Each app classified by type + runtime needs.
Targets shortlisted; ops/scale/cost weighed.
Most-managed sufficient option recommended per app with trade-offs.
Recorded for Gate 2; flip conditions noted.
Handed to pipeline + readiness skills.

Definition of Done

A recorded per-application deployment-target recommendation — most-managed option that meets each app's needs, with trade-offs and flip conditions — pending approval and feeding the pipeline and readiness skills.

Related Skills

../../backend/backend-deployment, ../../mobile/mobile-release, docker-foundation, ci-cd, github-actions, staging-environment, production-readiness, ../../database/backup-recovery, ../../stack-recommendation.

Related Knowledge

../../../knowledge/ (ops capacity, budget, existing infra).

Related References

../../../references/devops/ (target comparison notes, when populated).

Context Loading Guidance

Requires: app types/runtimes, ops capacity, scale/cost constraints.
Does not require: provisioning detail, app feature code.
May load: ../../backend/backend-deployment, staging-environment.
Stop when: per-app targets are recommended and recorded for approval.

Token Efficiency Guidance

The app × (target, ops cost, trade-offs) table is the artifact; decide per app against managed-first.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most ship operate skills give in ~1.0k tokens

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07

Document a rollback plan before deploymentin 41 of 779, across 22 files
Update the changelogin 21 of 779, across 19 files
Run the test suitein 20 of 779
Create an annotated git tagin 20 of 779
Clean up feature flags after full rolloutin 18 of 779, across 10 files
Verify deployment health after launchin 18 of 779, across 10 files
Test both feature flag statesin 17 of 779, across 9 files
Verify the working tree is cleanin 17 of 779
Make database migrations backward-compatiblein 16 of 779, across 8 files
Set up error monitoring before launchin 15 of 779, across 7 files
Monitor metrics at each rollout stagein 14 of 779, across 5 files
Create a GitHub releasein 14 of 779

Said here and by no other author read

classify each app by type and runtime needs
shortlist targets weighing ops capacity scale and cost
recommend the most-managed sufficient option per app
record decisions with trade-offs and flip conditions
note conditions that would flip each decision
hand targets off to pipeline and readiness skills

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.