Cursor Rules TemplatesCursor Rules Template

Cursor Rules Template: Cassandra/ScyllaDB CQLSH Driver

Cursor Rules Template for Cassandra/ScyllaDB using CQLSH and Python Cassandra driver. A copyable .cursorrules configuration to enable safe AI-assisted development for this stack.

.cursorrules templatecursor rules templatecassandrascylladbcqlshpython drivercursor ai rulesai-assisted developmentsecuritytestinglinting

Target User

Developers building apps on Cassandra/ScyllaDB using Python and CQLSH

Use Cases

  • Generate safe .cursorrules for Cassandra/ScyllaDB apps
  • Enforce parameterized queries and prepared statements
  • Define architecture and directory rules for Python projects accessing Cassandra/ScyllaDB
  • Standardize authentication, encryption, and secret management in Cursor AI workflows

Markdown Template

Cursor Rules Template: Cassandra/ScyllaDB CQLSH Driver

# .cursorrules
frameworkRole: "Cursor AI for Cassandra/ScyllaDB (Python + CQLSH)"
context: "You are an AI assistant that generates safe, executable Cursor rules for a Python-based Cassandra/ScyllaDB project using the CQLSH driver and cassandra-driver."
codeStyle: "PEP8, snake_case, docstrings, no trailing whitespace, explicit type hints where possible"
architectureDirectoryRules: "project_root/cassandra_service/, project_root/cursor_rules/, project_root/tests/; separate modules: client.py, models.py, queries.py; avoid global state in modules"
authenticationSecurity: "Do not embed credentials; read from env vars or secret manager; TLS/SSL enabled connections; rotate credentials regularly"
databaseOrmPatterns: "Use the Python cassandra-driver with prepared statements; model mapping in project models; avoid raw string interpolation in queries; batch usage allowed only for small finite sets"
testingLintingWorkflows: "pytest with pytest-cov; mypy for type-checking; flake8/ruff; run unit and integration tests in CI; linting before PRs"
prohibitedActions: ["Do not interpolate user input into CQL strings directly","Do not execute DDL/DML without validation in application code","Do not bypass prepared statements","Do not enable insecure defaults in cluster config"]
antiPatterns: ["Avoid ad-hoc schema migrations in runtime","Avoid storing secrets in code","Avoid using CQLSH shell for application data operations without proper scripting"]
# End of .cursorrules block

Overview

Cursor Rules Configuration for Cassandra/ScyllaDB stacks using the CQLSH driver and a Python Cassandra client. This Cursor rules template enables safe AI-assisted development by defining roles, style, architecture, authentication, DB patterns, tests, and production guardrails. It is designed for paste-and-adjust workflows in project roots that deploy Python-based Cassandra/ScyllaDB tooling alongside CQLSH usage.

Direct answer: Paste the provided .cursorrules block into your project root. It will constrain the Cursor AI to the Cassandra/ScyllaDB stack (CQLSH driver, Python client), enforce security patterns, and align code generation with your CI, tests, and deployment workflows.

When to Use These Cursor Rules

  • Starting a new Python project that interfaces with Cassandra or ScyllaDB with CQLSH or a Python driver.
  • Onboarding a team to ensure AI-assisted changes follow strict stack boundaries.
  • Preparing a CI/CD pipeline that validates generated code against Cassandra/ScyllaDB schemas and security constraints.
  • Establishing a repeatable project skeleton for similar stacks (CQLSH plus Python driver).
  • Auditing existing Cursor AI outputs for adherence to stack-specific policies.

Copyable .cursorrules Configuration

# .cursorrules
frameworkRole: "Cursor AI for Cassandra/ScyllaDB (Python + CQLSH)"
context: "You are an AI assistant that generates safe, executable Cursor rules for a Python-based Cassandra/ScyllaDB project using the CQLSH driver and cassandra-driver."
codeStyle: "PEP8, snake_case, docstrings, no trailing whitespace, explicit type hints where possible"
architectureDirectoryRules: "project_root/cassandra_service/, project_root/cursor_rules/, project_root/tests/; separate modules: client.py, models.py, queries.py; avoid global state in modules"
authenticationSecurity: "Do not embed credentials; read from env vars or secret manager; TLS/SSL enabled connections; rotate credentials regularly"
databaseOrmPatterns: "Use the Python cassandra-driver with prepared statements; model mapping in project models; avoid raw string interpolation in queries; batch usage allowed only for small finite sets"
testingLintingWorkflows: "pytest with pytest-cov; mypy for type-checking; flake8/ruff; run unit and integration tests in CI; linting before PRs"
prohibitedActions: ["Do not interpolate user input into CQL strings directly","Do not execute DDL/DML without validation in application code","Do not bypass prepared statements","Do not enable insecure defaults in cluster config"]
antiPatterns: ["Avoid ad-hoc schema migrations in runtime","Avoid storing secrets in code","Avoid using CQLSH shell for application data operations without proper scripting"]
# End of .cursorrules block

Recommended Project Structure

my_cassandra_project/
├── cassandra_service/
│   ├── __init__.py
│   ├── cluster_config.py
│   ├── cassandra_client.py
│   ├── models.py
│   └── migrations/
├── cursorrules/
│   └── cassandra_scylladb_cursor_rules.cursorrules
├── tests/
│   ├── unit/
│   └── integration/
├── scripts/
│   └── run_cursor_manager.py
├── requirements.txt
└── README.md

Core Engineering Principles

  • Fail-fast validation of inputs and queries to Cassandra/ScyllaDB.
  • Explicit, testable data access layers with prepared statements.
  • Security-first defaults: encrypted connections, restricted permissions, secret management.
  • Automated testing across unit/integration with CI.
  • Deterministic code generation from Cursor AI with clear boundaries between app logic and AI output.

Code Construction Rules

  • Always use prepared statements for parameterized queries; never concatenate user input into CQL strings.
  • Encapsulate all Cassandra access behind a repository/service layer with well-defined interfaces.
  • Validate schema compatibility on startup and during migrations; log and fail fast on mismatch.
  • Use environment-based configuration for endpoints, keys, and credentials; do not hardcode secrets.
  • Prefer typed Python models for data retrieved from Cassandra and map to domain objects.
  • Follow the project’s Python style guide (PEP8) and type hints; ensure mypy checks pass in CI.
  • Place queries in dedicated modules (e.g., queries.py) and export small, reusable helpers.
  • Do not rely on cqlsh for application runtime data operations; reserve it for admin tasks only.

Security and Production Rules

  • Enable TLS/SSL for all client connections to Cassandra/ScyllaDB.
  • Use least-privilege roles; separate read/write permissions for services and admin tasks.
  • Store credentials in a secret manager or environment variables; rotate keys periodically.
  • Audit query logs and enforce query-timeouts to prevent long-running operations.
  • Implement automatic retries with exponential backoff and idempotent operations where possible.
  • Humane error handling: avoid exposing internal stack traces in production responses.

Testing Checklist

  • Unit tests for data access methods with mock Cassandra sessions.
  • Integration tests against a real or in-memory Cassandra/ScyllaDB cluster with CI-friendly fixtures.
  • End-to-end tests for critical query paths and data migrations.
  • Static type checks (mypy) and linting in CI; enforce 0 errors.
  • Security tests for secret handling, TLS, and access controls.
  • Smoke tests for deployment to staging environments.

Common Mistakes to Avoid

  • Direct string interpolation of CQL queries from user input.
  • Storing secrets in code or repository history.
  • Overusing non-idempotent operations in retry loops.
  • Mixing application logic with CQL shell (cqlsh) workflows in runtime code.
  • Ignoring schema drift and failing migrations in production environments.

FAQ

What is a Cursor Rules Template for Cassandra/ScyllaDB?

A Cursor Rules Template is a pre-defined .cursorrules configuration that constrains Cursor AI to generate safe, stack-specific code and project scaffolding for Cassandra/ScyllaDB apps using CQLSH and Python drivers. It includes architecture, security, testing, and anti-patterns tailored to this stack.

Which stack components does this template cover?

This template targets Cassandra/ScyllaDB, Python-based clients via the cassandra-driver, and optional CQLSH-based admin tasks. It enforces prepared statements, TLS, and environment-based credentials, aligning with modern CI/CD practices.

How do I integrate the .cursorrules into my project?

Place the provided .cursorrules file in the project root or a dedicated cursorrules directory and reference it from your Cursor AI editor workflow. Ensure your repository includes the recommended structure and environment configuration as defined in the template.

Can I adapt this template to other stacks?

Yes. Use this template as a pattern: replace stack-specific drivers, authentication patterns, and query conventions with equivalents for your stack, while preserving the Cursor AI workflow and safety guardrails.

What security considerations should I prioritize?

Prioritize TLS/mTLS, secret management, least-privilege access, and audited queries. Avoid embedding credentials in code, and ensure secrets rotate regularly. Validate query and schema compatibility in tests and migrations.