agentleFS
Sign inStart free
hasansezertasanhasansezertasan/infra-copilot/skills/infra-add/SKILL.md

infra-add

Skill2 starsChanged 27 days agoMITView on GitHub

Provision something new in an already-bootstrapped infra repo: a managed GitHub repo, a resource on an existing provider, or a brand-new provider such as GCP. Ends on a green plan showing the new thing as will be created. Use when the thing does not exist yet — if it already exists at the provider, use infra-skills:infra-import instead.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 1

    1. hasansezertasan/infra-skills★ 2100% same

    Edited · 0

    None found.

    Wrote their own version · 0

    None found.

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository6 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Only for things that do not exist yet.

    line 32
  2. Very specific:

    infra-skills:infra-import: instead. Never fake a HUMAN step: an App-scope change, a token mint or paste, and a provider decision are the …

    line 34
  3. Very specific:

    Write the resource under the right leaf (terraform/cloudflare/ or terraform/github/).

    line 61
  4. Very specific:

    If it needs a permission the current scoped token lacks (e.g.

    line 62
  5. Distinctive:

    Use get-plan → green with the new resource as will be created.

    line 66

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<!-- AI-RULEZ :: GENERATED FILE — DO NOT EDIT Content-Hash: blake3:df478b92402aeb17945b4bb2cc46ecfa410d0d926108fb2627d32da98a374aab Source-Hash: blake3:68a46b64e70180566a5d1ebf9d0d4a9e0e15ab0076377348ec74a1267ef0ecb1 Schema-Version: v1 -->

infra-add

Grow a repo that infra-skills:infra-setup already bootstrapped. Three flavors of "add," in increasing blast radius. This file is a router: the reusable machinery — actor model, handoff, resume, preflight — lives in ../infra/references/protocol.md; the manifest in ../infra/references/steps.yaml; per-provider detail under ../infra/references/.

New vs. existing. add provisions things that don't exist yet — Terraform will create them, and a create in the plan is the expected, correct outcome. If the thing already exists at the provider and you're bringing it under management, that's infra-skills:infra-import (where a create means something went wrong).

Guardrails

infra-skills:infra-setup phases 0–4 are green before this runs. add extends a working repo; it does not bootstrap credentials.

Only for things that do not exist yet. If the resource already exists at the provider, this skill would tell Terraform to create a duplicate — use infra-skills:infra-import instead. Never fake a HUMAN step: an App-scope change, a token mint or paste, and a provider decision are the human's, per the shared protocol.

Pick the flavor

1. Add a managed repo (smallest)

Terraform's github-org leaf manages repos. To add one:

  1. Config — managed_repos is a Template answer in the README Config block, outside the customization markers, so the Skills never edit it. Add the repo through the Template's own update flow (../infra/references/config.md), then re-export $REPO if it's the first entry (the repository used by the execution service).
  2. GitHub App install scope (HUMAN if the App is installed on selected repos) — the App must be able to see the new repo. If install is scoped, a human extends it in the org's App-install settings, then replies done. See ../infra/references/github.md.
  3. Terraform — add the resource/module in terraform/github/, then verify the plan: use the get-plan operation. Green plan showing the new repo as will be created (or imported, if it already exists on GitHub — then hand to infra-skills:infra-import).

2. Add a resource to an existing provider

A new Cloudflare DNS record, page rule, or GitHub repo setting — the provider and its execution and credentials already exist, so this is pure Terraform:

  1. Write the resource under the right leaf (terraform/cloudflare/ or terraform/github/).
  2. If it needs a permission the current scoped token lacks (e.g. a new Cloudflare resource type), the token needs widening — a HUMAN mint/paste. Scope-widening guidance: ../infra/references/cloudflare.md and ../infra/references/docs/secrets.md.
  3. Use get-plan → green with the new resource as will be created. Apply through the approved execution procedure after review.

3. Adopt a brand-new provider (largest — a design decision)

Adding a provider like GCP is a locked-design-decision change, not a routine add. GCP is opt-in: nothing is provisioned until the decision is recorded.

Route a new-provider adoption through Phase 6 of ../infra/references/steps.yaml, using the shared resume protocol. The manifest and protocol own the bootstrap behavior, sequence, and safety rules.

Runbook for the GCP case (keyless WIF auth, adoption hazards): ../infra/references/gcp.md.

Workflow

  1. Read config first (shared protocol, Step 0) — ../infra/references/config.md.
  2. Pick the flavor above; run AGENT steps and stop + hand off on HUMAN steps (App-scope change, token mint/paste, provider decision). Full actor/handoff/resume contract: ../infra/references/protocol.md.
  3. Verify with a plan, then follow the read-run-status operation to confirm the approved apply.

Validation

terraform plan is green, the new thing is shown as will be created, and nothing is unexpectedly destroyed. A resource appearing as will be created that you know already exists live means this was the wrong skill — stop and use infra-skills:infra-import.

Example

Adding one managed repo, after the config edit:

# terraform/github
Plan: 1 to add, 0 to change, 0 to destroy.
  + github_repository.this["new-service"]

One to add, nothing to destroy: that is the shape to expect.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free