Cursor Rules Template: Go chi sqlx migrate with Cursor AI

Overview

The Cursor rules configuration presented here is tailored for a Go API stack that uses the chi router, sqlx for database access, and golang-migrate for schema migrations. It provides Cursor AI with precise role context and stack constraints to generate safe, idiomatic Go code and automated tests.

When to Use These Cursor Rules

• Starting a new Go API project with chi router and sqlx
• Enforcing a migration-first workflow with golang-migrate
• Standardizing repository layout, error handling, and HTTP response patterns
• Ensuring security best practices for authentication and TLS in production
• Integrating Cursor AI into CI/CD for consistent code generation

Copyable .cursorrules Configuration

framework: go
stack: go-chi-sqlx-golang-migrate
role: Go API Developer using chi, sqlx, and migrate
context: You are Cursor AI configured to produce production-grade Go API code with clear architecture, strong typing, and safe database access.
codeStyle: gofmt; golangci-lint
architecture:
  - cmd/server/main.go
  - internal/server/
  - internal/db/
  - migrations/
security:
  authentication: JWT with RS256 or HS256; sessionless endpoints where possible
  encryption: TLS 1.3 in transit; at-rest encryption managed by the DB
  secrets: read from environment or secret manager; never commit credentials
database:
  orm: sqlx
  migrations: golang-migrate
testing:
  unit: go test ./...
  integration: docker-compose up test-db && go test ./... -tags=integration
linting: golangci-lint run
prohibited:
  - do not use GORM or other heavy ORMs
  - do not hard-code credentials or secrets
  - do not bypass explicit migrations or database seeding

Recommended Project Structure

myapp/
├── cmd/
│   └── server/
│       └── main.go
├── internal/
│   ├── server/
│   │   ├── handlers/
│   │   └── router/
│   ├── db/
│   │   ├── migrations/
│   │   └── sqlx.go
│   └── config/
├── migrations/
├── go.mod

Core Engineering Principles

• Type-safe Go across service boundaries; strict input validation
• Explicit dependencies and a clean layering of cmd, internal, and pkg
• Migration-driven development with golang-migrate
• Security by default: TLS, JWT, CSRF protection where applicable

Code Construction Rules

• Own all DB access through a dedicated repository layer backed by sqlx
• Use prepared statements and context-aware queries; avoid string concatenation for SQL
• Return typed models and consistent error wrappers
• Handle migrations as part of startup; ensure rollback not silently ignored
• Write tests that cover HTTP handlers, repositories, and migrations

Security and Production Rules

• Validate all inputs server-side; reject malformed payloads early
• Enforce authorization with JWT and least-privilege DB access
• Use TLS in production; rotate credentials and enforce strong crypto
• Do not log secrets; redact sensitive fields and use structured logging

Testing Checklist

• Unit tests for repositories and handlers
• Integration tests that exercise the DB with a dedicated test schema
• CI pipeline runs go vet, go fmt, and golangci-lint
• Migration verification by applying migrations to a test database

Common Mistakes to Avoid

• Using global variables for DB connections; prefer dependency injection
• Relying on a heavyweight ORM instead of sqlx for typed SQL
• Skipping migrations in CI; deploys drift if migrations are forgotten

FAQ

What is this Go Cursor Rules Template for Cursor AI?

This template defines a Go API stack using chi for routing, sqlx for database access, and golang-migrate for migrations. It provides a ready-to-use Cursor Rules block that guides Cursor AI to generate idiomatic Go code, secure endpoints, and tests aligned with production practices.

How do I apply the .cursorrules block in my repository?

Copy the code block from Copyable section and place it at project root as .cursorrules. Cursor AI will read it to tailor code generation and validation for this stack.

Can I customize the project structure in the template?

Yes. The template outlines a practical layout (cmd, internal, migrations) and can be adjusted to your conventions. Ensure your server startup path and migrations align with how you initialize your database and run the API.

Which security practices are enforced by this template?

The template emphasizes TLS in transit, JWT-based authentication, environment-based secrets management, and avoiding hard-coded credentials. It recommends input validation and careful logging to prevent sensitive data exposure.

What tests should accompany this stack?

Unit tests for repositories and handlers, integration tests against a test database with migrations, and CI checks for formatting and linting are recommended. Use docker-compose for end-to-end scenarios when feasible.