AGENTS.md Generator

Generator / Templates / Infrastructure as code

AGENTS.md for Infrastructure as code

Terraform, Kubernetes, Helm and GitHub Actions. This AGENTS.md template combines 91 rules from 10 packs and runs to 122 lines.

Open this template in the AGENTS.md generator

What is inside

The generated AGENTS.md

This is the file the generator produces for the Infrastructure as code preset, before you add your project name and commands.

# AGENTS.md

## Agent behavior

- For changes touching more than three files, outline the plan and wait for confirmation before editing.
- Ask a clarifying question when requirements are ambiguous instead of guessing.
- Keep diffs small and focused on the request; do not refactor unrelated code.
- Run the relevant tests, linter and type checker before reporting a task as done, and report failures honestly.
- Never delete, skip or loosen a failing test to make it pass; fix the cause.
- Do not add new dependencies without explicit approval; prefer the standard library and existing packages.
- Do not edit generated or vendored files; change the source and regenerate.
- Never read, print or commit secrets, .env files or credentials.
- Read the relevant code and tests before proposing a change; do not edit files you have not read.
- Fix the root cause rather than suppressing the symptom with a workaround or silenced warning.
- Do not add lint or type suppressions to get a clean run; fix the underlying issue.
- Report failing tests, skipped steps and unverified claims plainly; never claim success without evidence.
- Verify library APIs in the installed version or its docs before using them; do not invent functions.
- Do not change public behavior, file formats or APIs unless the task asks for it.
- Never hardcode values or special-case inputs to satisfy a test.
- If an approach fails twice, stop and ask instead of trying increasingly invasive workarounds.
- Before editing a directory, read the nearest AGENTS.md and follow it over the root file where they differ.
- Preserve unrelated working tree changes. Never revert or rewrite edits you did not make.

## Git and pull requests

- Write commit messages in Conventional Commits format (feat:, fix:, docs:, refactor:, test:, chore:) and mark breaking changes with ! or a BREAKING CHANGE footer.
- Keep pull requests small and focused on one change.
- Write commit subjects in the imperative mood, 72 characters or fewer.
- Never force-push to shared branches and never rewrite published history.
- Run lint, type check and tests before committing.
- Never commit secrets, build output or large binaries.
- Describe motivation, approach and testing in the pull request description.
- Make each commit one logical change that builds and passes tests.
- Do not amend or rebase commits that are already pushed to a shared branch.
- Add build output, local env files and editor files to .gitignore instead of committing them.
- Open pull requests only when CI is green and the diff is self-reviewed.
- Never bypass commit hooks or signing with --no-verify unless explicitly instructed.

## Security

- Load secrets from environment variables or a secret manager; never hardcode them.
- Use parameterized queries and safe APIs; never build SQL, shell commands or HTML by string concatenation with user input.
- Enforce authentication and authorization on the server for every protected operation.
- Pin dependency versions, commit lockfiles and review new packages before adding them.
- Grant the minimum permissions needed for tokens, service accounts and containers.
- Use well-reviewed cryptographic libraries; never invent your own algorithms or store plain passwords.
- Encode output for its context and avoid injecting raw HTML; sanitize rich text with a vetted library.
- Protect state-changing browser requests with CSRF tokens or SameSite cookies.
- Configure CORS with explicit origins; never reflect arbitrary origins with credentials.
- Use HttpOnly, Secure, SameSite cookies and rotate session identifiers on login.
- Validate and allow-list URLs before fetching user-supplied addresses to prevent SSRF.
- Hash passwords with Argon2id, or scrypt or bcrypt where it is unavailable, with a unique salt; never use fast hashes such as SHA-256.
- Run secret scanning in CI and rotate any credential that has been exposed.
- Validate untrusted input against a schema. Never run eval, exec or unpickling on it.

## Workflow and tooling

- Run tools through the project scripts (npm run, make, task) instead of invoking underlying binaries directly, so flags and environments match CI.
- Run the single aggregate check command (for example pre-commit or a lint script) before finishing; fix every failure and re-run until it passes.
- Run the specific test files related to your change first, and run the full suite only before handing off.
- Before editing a directory, read the README and any nested AGENTS.md that applies to it.
- Put throwaway scripts and experiment output in a gitignored scratch directory and delete them when done.
- After switching branches or pulling dependency changes, reinstall and rebuild before running tests.
- When CI fails, find the exact failing job and command, reproduce it locally, then fix the cause instead of re-running blindly.
- Stop any dev servers or watchers you started once you are done.
- Ask before running destructive or irreversible commands such as dropping databases, deleting branches, rm -rf or force operations.
- Prefer existing scripts, generators and templates in the repo over writing new ad hoc tooling.
- When the repository documents skills or runbooks for a task (migrations, releases, dependency bumps), follow them instead of improvising.
- Never start long-running dev servers or watchers in the foreground. Use targeted one-shot commands.

## Docker conventions

- Use multi-stage builds and slim base images with pinned versions.
- Run containers as a non-root user.
- Order Dockerfile instructions for layer caching: dependencies before source.
- Maintain a .dockerignore to keep secrets and build context small.
- Pin base images to a version or digest and rebuild regularly for patches.
- Never bake secrets into images or build args; use build secrets or runtime injection.
- Run one main process per container.
- Use the exec form for ENTRYPOINT and CMD so signals reach the process.

## Kubernetes conventions

- Set resource requests and limits on every container.
- Define readiness and liveness probes, and a startup probe for slow-starting containers.
- Keep configuration in ConfigMaps and Secrets, not in images.
- Pin images by version or digest, never :latest.
- Run as non-root with allowPrivilegeEscalation false, a read-only root filesystem, all capabilities dropped and the RuntimeDefault seccomp profile.
- Isolate workloads with namespaces and minimal RBAC.
- Change cluster state through manifests in git, not kubectl edit.

## Helm conventions

- Document every value in values.yaml and keep sensible defaults.
- Run helm lint and helm template in CI.
- Never commit secrets in values files; use an external secrets operator.

## Terraform conventions

- Run terraform fmt and terraform validate before committing.
- Never apply without reviewing a plan; do not run apply against production from an agent.
- Use modules and typed variables with descriptions; avoid hardcoded values.
- Use remote state with locking and never commit state files or secrets.
- Pin provider versions in required_providers and commit the .terraform.lock.hcl lock file.
- Separate environments with distinct state and variable files.
- Reference resources and data sources rather than hardcoding IDs and ARNs.
- Mark sensitive variables and outputs as sensitive.

## GitHub Actions conventions

- Pin third-party actions to a full-length commit SHA and verify it belongs to the action repository, not a fork.
- Set explicit minimal permissions on the GITHUB_TOKEN per workflow.
- Never echo secrets and avoid pull_request_target with untrusted code.
- Set timeout-minutes on every job.
- Authenticate to clouds with OIDC instead of stored long-lived keys.

## AWS conventions

- Grant least-privilege IAM policies scoped to specific resources and actions.
- Use IAM roles and short-lived credentials; never create long-lived access keys for workloads.
- Enable encryption at rest and block public access on S3 buckets.
- Create and change resources through infrastructure as code, not the console.

How to use it

Related guides

More AGENTS.md templates