← Belső rendszer fejlesztők adatlapja
Nézd meg, miben segít
Infrastruktúra-folyamat feltárása
Feltérképezi a kódváltozástól a futó infrastruktúráig vezető valódi utat build- vagy telepítésmódosítás előtt.
infra-pipeline-discovery
Ezt a skillt használó csapattagok
Mikor hasznos?
Akkor használd, ha ismeretlen CI-feladat, konténerbeállítás vagy telepítési indító élő környezetre is hathat.
Miben segít neked?
- Végigköveti a commitot az ellenőrzésen, csomagon és telepítési indítón.
- Elkülöníti a mellékhatásmentes ellenőrzést az élő hatású feladattól.
- Azonosítja a célfiókot, környezetet és működési konvenciókat.
Például ezt kérheted
Térképezd fel az éles telepítést végző folyamatot buildlépéseinek módosítása előtt. Kövesd a main commitját a pipeline-on át az éles verziójelölőig. Beállításmódosítás előtt azonosítsd pontosan az éles környezetet változtató feladatot.
Részletes dokumentáció
Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.
Összecsukás
Infrastructure & Pipeline Discovery
Never modify a workflow, Dockerfile, deployment script, or environment setting before mapping what triggers automatically on push, pull_request, merge, tag, or scheduled cron events. A careless commit to a branch or workflow file can trigger an unintended production deployment or break artifact publishing.
Step 1: Map the Commit-to-Production Path
Inspect the repository systematically before proposing or applying changes:
| Surface | Files & Locations to Inspect | Questions to Answer |
|---|---|---|
| CI/CD Workflows | .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile, bitbucket-pipelines.yml, .circleci/config.yml, cloudbuild.yaml |
Which branches/tags trigger builds vs. deployments? Are workflows gated by environment approvals or concurrency groups? |
| Build & Package Scripts | package.json (scripts, engines, packageManager), composer.json, Makefile, Dockerfile, docker-compose*.yml, goreleaser.yml, eas.json, electron-builder.* |
What exact commands produce the production artifact? Are lockfiles (package-lock.json, pnpm-lock.yaml, composer.lock, Cargo.lock) committed and enforced? |
| Infrastructure & Hosting | terraform/, infra/, cdk.json, fly.toml, render.yaml, vercel.json, railway.toml, k8s/, helm/, Procfile, systemd/ |
How is the artifact hosted and configured across local, preview/staging, and production? |
| Database & Workers | Migration scripts, release hooks (release_command, preDeploy), queue worker entrypoints, cron schedules |
When do schema migrations run relative to app rollout, and what background processes share the codebase? |
Step 2: Identify Blast Radius & Trigger Boundaries
- Distinguish code-only checks from side-effecting jobs:
- Separate read-only verification steps (
lint,typecheck,test, dry-run build) from jobs that mutate external state (pushing container images, publishing packages, running database migrations, notifying channels, or deploying to live environments).
- Separate read-only verification steps (
- Verify target environment & account identity before live operations:
- Before running any CLI command that touches cloud resources, registries, or clusters (
gcloud,aws,kubectl,terraform,flyctl,gh release), inspect the active context/profile (kubectl config current-context,aws sts get-caller-identity,gcloud config list) to confirm you are not targeting production when intending to inspect dev/staging.
- Before running any CLI command that touches cloud resources, registries, or clusters (
- Fit the solution to the team and existing stack:
- Never introduce Kubernetes, service meshes, multi-cloud abstractions, or a second CI system into a project that runs cleanly on a simpler platform unless concrete scale or compliance requirements demand it.
- Document the discovered pipeline topology, automatic triggers, and manual approval gates clearly before altering release behavior.
Csomagban lévő fájlok 1
SKILL.md