← Back to Electron and React foundation team
See how it helps
Infrastructure pipeline discovery
Maps the real route from repository changes to runtime infrastructure before altering build or deployment behavior.
infra-pipeline-discovery
Team members using this skill
When is it useful?
Use it when CI jobs, container configuration or deployment triggers are unfamiliar and may affect live environments.
What does it help you do?
- Traces commits through checks, artifacts and deployment triggers.
- Separates harmless verification from jobs with live side effects.
- Identifies target accounts, environments and existing operational conventions.
Try asking this
Map which workflow actually deploys production before changing its build steps. Follow the current main commit through its pipeline and deployed revision marker. Identify the exact job whose execution changes production before editing configuration.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
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.
Included files 1
SKILL.md