Cursor Rules Template: Repair Shop Diagnostic Assistants from Customer Issue Descriptions

Overview

This Cursor Rules Template provides a copyable .cursorrules configuration for building a repair shop diagnostic assistant. It targets a Python FastAPI stack with PostgreSQL and SQLAlchemy. The rules guide Cursor AI in transforming customer issue descriptions into actionable diagnostics, repair steps, and service workflows while enforcing safe AI practices and maintainable architecture.

Direct answer: paste the .cursorrules block into your project root to configure Cursor AI for end-to-end repair diagnostics from customer descriptions.

When to Use These Cursor Rules

• When building a diagnostic assistant that interprets customer issue narratives for repair shops.
• When mapping descriptive symptoms to probable faults, service codes, parts, and labor estimates.
• When enforcing a consistent data model and secure access in a Python FastAPI application.
• When validating AI outputs with tests, linting, and CI/CD so production readiness is ensured.

Copyable .cursorrules Configuration

Framework Role & Context:
  You are a Cursor AI agent integrated with a Python FastAPI + PostgreSQL application
  that triages customer issue descriptions into diagnostic steps, repair actions,
  and service workflows for a repair shop.

Code Style and Style Guides:
  - Follow PEP8, use type hints, docstrings, and mypy for type checks
  - Use Black for formatting and isort for import order
  - Write clear, explicit prompts and document decisions in code comments

Architecture & Directory Rules:
  - Project root contains app/, migrations/, tests/, config/
  - Organize as app.api, app.services, app.models, app.core, and app.db modules
  - Keep business logic in services; keep API layer thin

Authentication & Security Rules:
  - Implement JWT-based authentication with access and refresh tokens
  - Protect private endpoints with FastAPI dependencies
  - Never log secrets or raw tokens; use environment-based config

Database and ORM patterns:
  - Use PostgreSQL with SQLAlchemy ORM (declarative models)
  - Define migrations with Alembic; keep migrations under migrations/
  - Use dependency injection for db sessions and repository patterns

Testing & Linting Workflows:
  - Unit tests with PyTest; async tests for API endpoints
  - Integration tests cover end-to-end diagnostic flows
  - Pre-commit hooks and CI (pytest, mypy, flake8) on push

Prohibited Actions and Anti-patterns:
  - Do not execute arbitrary shell commands from prompts
  - Do not access external networks from the AI runtime
  - Do not bypass authentication or leak credentials
  - Do not hard-code secrets or database credentials in code

Recommended Project Structure

repo/
├── app/
│   ├── api/
│   │   └── endpoints/
│   │       └── diagnostics.py
│   ├── core/
│   │   ├── config.py
│   │   └── security.py
│   ├── models/
│   │   ├── customer_issue.py
│   │   ├── diagnostic_result.py
│   │   └── __init__.py
│   ├── services/
│   │   ├── diagnostic_engine.py
│   │   └── __init__.py
│   ├── db/
│   │   └── base.py
│   └── main.py
├── migrations/
├── tests/
└── alembic.ini

Core Engineering Principles

• Single source of truth for diagnostics data and prompts
• Explicit interfaces and clear data contracts between layers
• Deterministic prompts with guardrails and fail-safes
• Type safety, testability, and measurable quality gates
• Data privacy and secure handling of customer information

Code Construction Rules

• Use a clean, modular architecture with a distinct service layer for the diagnostic engine
• Model customer issues with a consistent schema and normalize input data
• Prompts and rules must be versioned and auditable
• All API inputs must be validated with pydantic models
• Include deterministic prompts and fallback behaviors for ambiguous inputs
• Avoid tight coupling between AI rules and business logic

Security and Production Rules

• Store secrets in environment variables; use a config module to load them securely
• Use HTTPS in production; enable TLS termination at the load balancer
• Enforce strict input validation and output logging with redaction
• Limit AI prompt exposure by sandboxing external calls
• Implement rate limiting and monitoring for API endpoints

Testing Checklist

• Unit tests for data models and utility functions
• Integration tests for API endpoints and DB interactions
• End-to-end tests for the diagnostic flow from customer issue to recommended repairs
• Linting and type checks in CI
• Security tests for input validation and token authentication

Common Mistakes to Avoid

• Overfitting AI prompts to rare edge cases; ignore generalization
• Hard-coding rules or secrets; avoid config drift
• Skipping tests for diagnostic paths; assume prompt will always be correct
• Confusing technical debt with rapid iterations; prioritize maintainability

Related implementation resources: AI Agent Use Case for Repair Shops Using Customer Issue Descriptions to Suggest Diagnostic Steps.

FAQ

What stack is this Cursor Rules Template designed for?

The template targets a Python FastAPI application backed by PostgreSQL using SQLAlchemy. It provides Cursor AI rules to transform customer issue descriptions into repair diagnostics while enforcing clean architecture and secure practices.

How do I paste the .cursorrules block into my project?

Copy the block under Copyable .cursorrules Configuration and place it in a Cursor rules file at the project root as .cursorrules. Cursor AI will read and enforce the defined roles, constraints, and architecture during compilation and runtime checks.

Can I adapt this for other repair shop domains?

Yes. The rules emphasize modular prompts, data contracts, and a service layer. Replace domain nouns (diagnostics, procedures) with your own repair domain while reusing the architecture and security patterns.

What ensures safe AI behavior in production?

The template enforces strict authentication, input validation, and controlled prompt outputs. Prohibited actions block dangerous commands, and defensive prompts steer the AI toward verifiable, auditable results.

How do I test the diagnostic flow?

Use unit tests for data models, integration tests for API and database interactions, and end-to-end tests that simulate customer descriptions through the full diagnostic pipeline.