Cursor Rules for DevOps: Environments, Reviews, and Changes

Cursor rules for DevOps work tell the assistant which environments exist, which changes require a human review before being applied, which tools and CLI commands are approved, and what the process looks like for safe infrastructure changes. Without these rules, the assistant applies the same confidence to a change in a staging Terraform file as it does to a production one. fenbs is where teams record the human-approved operational decisions — the rules that an assistant must read and follow — alongside the history of who decided them and why.

DevOps rules are different from coding convention rules in one important way: the consequences of a mistake are often immediate and sometimes irreversible. A wrong application code change fails a test. A wrong infrastructure change can take down a service or modify production data. Rules for DevOps work should focus on the boundaries that matter most: which environments require approval, which commands must never be run automatically, and which changes need a second pair of eyes.

Environment boundaries

The most important DevOps rule is a clear statement of what each environment is and what level of caution applies to changes there. An assistant that does not know the difference between a staging and a production configuration file has no way to apply appropriate caution when editing one versus the other.

Environments:
- development: local only, no shared infrastructure
- staging: shared, reflects production configuration
- production: live, customer-facing

Staging and production infrastructure files live in infra/staging/ and infra/production/.
Do not apply changes to staging or production directly.
All staging and production changes require a pull request and a human review.

Infrastructure change rules

If your team uses Terraform, Pulumi, Ansible, or another infrastructure-as-code tool, a rule that names the tool, the state backend, and the required change procedure prevents the assistant from suggesting an ad hoc change when the correct approach is a reviewed plan.

Infrastructure as code: Terraform
State: remote backend in S3 (do not use local state for staging or production)

Change process:
1. Edit Terraform files under infra/
2. Run: terraform plan to review changes
3. Commit to a branch and open a pull request
4. A human reviews the plan output before applying
5. Apply only after approval: terraform apply

Do not run terraform apply without a reviewed plan.
Do not destroy resources without explicit approval.

CI/CD and pipeline rules

CI/CD pipelines are a common area where an assistant can make a change that looks straightforward but has broad consequences. A rule about which pipeline steps require review, which environment the pipeline deploys to, and which changes to pipeline configuration need a human in the loop prevents the most common problems.

CI/CD: GitHub Actions
Workflow files are in .github/workflows/

Pipeline rules:
- Changes to workflow files require review by a senior engineer
- Do not add steps that run scripts from external URLs
- Secrets are stored in GitHub Actions secrets — do not hardcode in workflow files
- The production deploy workflow requires a manual approval step
- Do not disable or bypass the required status checks

Approved tools and command rules

A rule that names the approved tools for infrastructure work and which tools or commands are off-limits prevents the assistant from suggesting a solution that uses an unapproved tool or runs a privileged command that should not be used in an automated context.

Approved tools for infrastructure work:
- Terraform for cloud resources
- Docker and docker-compose for local and staging containers
- kubectl for Kubernetes — read-only commands only without explicit approval

Do not use:
- cloud provider CLI (aws, gcloud, az) to modify production resources directly
- kubectl delete or kubectl exec on production without explicit human approval
- Any tool not listed here without team agreement

Monitoring and alerting rules

Changes that affect monitoring configuration can silence alerts or create false positives at the worst time. A rule that names your monitoring setup and what changes require extra care prevents the assistant from editing alert thresholds or disabling a check as part of a broader infrastructure change.

Monitoring: Datadog (dashboards and alerts in monitoring/)

Alert changes:
- Do not modify or disable existing alerts without team approval
- New alerts must be reviewed by a team member before being enabled in production
- Threshold changes require a documented reason in the pull request

Do not silence a triggered alert as a way to fix it — investigate the cause.

How to do this with fenbs

1. Create a free account and add a project for your infrastructure or DevOps workspace.
2. Record each operational rule in Decisions and rules with the person who approved it and the reason it exists. Rules about production access and review requirements should note who decided them and when.
3. Add skills or prompts for the specific procedures — the Terraform change workflow, the incident response checklist — that the assistant might need to follow in a session.
4. When a new tool is approved or a new review requirement is added, update fenbs immediately. An assistant working from an outdated rule may skip a required step.
5. Connect your AI tools from Integrations so they read the current operational decisions before starting any infrastructure work.

What to check before every infrastructure session

Before using an AI assistant on infrastructure work, confirm that the rules in your project are current. Have any environments changed? Has a new tool been approved or banned? Has a deployment process been updated? Outdated rules in a DevOps context are more dangerous than in application code, because the assistant cannot run a test suite to catch mistakes — the check is often the live infrastructure itself.

fenbs is not a deployment tool and does not connect to your cloud provider. It keeps the decisions and procedures your team has approved. For the broader context of AI tools in DevOps work, the devops tools article covers the current landscape.

Infrastructure rules need reviewing when the team adopts a new tool or changes cloud providers. A rule that assumes AWS-specific CLI commands is wrong for a GCP project. When the toolchain changes, update the approved tools rule immediately — an assistant working from an outdated list may suggest the old tool as an acceptable option when the team has already moved away from it.

Disaster recovery procedures and incident runbooks are better captured as commands or procedures in fenbs than as standing rules. A standing rule that describes what to do during an incident loads in every session, whether or not an incident is occurring. Keep incident response in a procedure you invoke when needed, and keep the standing rules focused on the constraints that apply all the time. Review and test runbook procedures at least once per quarter so they remain accurate when they are actually needed.