← Zurück zu Mobile App-Starter · Projektplanungspaket
Entdecke, wie der Skill hilft
Infrastruktur-Pipelines erkunden
Kartiert den tatsächlichen Weg von Repositoryänderungen zur laufenden Infrastruktur vor Änderungen an Build oder Deployment.
infra-pipeline-discovery
Agenten mit diesem Skill
Wann ist der Skill hilfreich?
Nutze ihn bei unbekannten CI-Jobs, Containerkonfigurationen oder Auslösern mit möglichen Live-Auswirkungen.
Wobei hilft er dir?
- Verfolgt Commits durch Prüfungen, Artefakte und Deployment-Auslöser.
- Trennt reine Prüfung von Jobs mit produktiven Auswirkungen.
- Identifiziert Zielkonten, Umgebungen und vorhandene Betriebskonventionen.
Das könntest du fragen
Ermittle den tatsächlichen Produktionsworkflow vor Änderung seiner Build-Schritte. Verfolge den Main-Commit durch Pipeline und aktive Revisionsmarkierung. Identifiziere vor Konfigurationsänderungen genau den Auftrag, der Produktion verändert.
Ausführliche Dokumentation
Hier findest du die ursprüngliche Anleitung, Beispiele und Prüfschritte des Skills in ihrer Originalsprache.
Weniger anzeigen
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.
Enthaltene Dateien 1
SKILL.md