Cursor Rules Template: Building Course Improvement Dashboards from Learner Questions

Overview

\nDirect answer: this Cursor rules configuration provides a Django-based stack template to turn learner questions into course-improvement dashboards. It covers Django, Django REST Framework, PostgreSQL, and a React frontend, with Cursor AI guiding code generation and data modeling.

\nThe configuration is designed so Cursor AI can produce a reusable, paste-ready .cursorrules block that scaffolds models, serializers, endpoints, and UI hooks specific to dashboards built from learner questions.

\n\nWhen to Use These Cursor Rules

\n\n  - When you need a data-backed dashboard distilled from natural language learner questions
\n  - When the stack is Django + DRF with a PostgreSQL database and a React frontend
\n  - When you want repeatable patterns for models, APIs, and UI components
\n  - When you require strict security, testing, and CI/CD guidance for production
\n\n\nCopyable .cursorrules Configuration

\n.cursorrules
framework: python-django
context: You are Cursor AI building a Django backend with DRF and a React frontend to convert learner questions into dashboards. Follow the stack-specific patterns below.
style: pep8, black, isort\ architecture:
  - apps/dashboards
  - apps/questions
  - api/serializers
  - frontend
auth:
  method: jwt
  tokenRefresh: true
database:
  engine: postgresql
  orm: django-orm
security:
  secretManagement: envVARsOnly
  csrfProtection: enabled
dev:
  testing: pytest-django
  lint: flake8, black
  ci: true
antiPatterns:
  - do not use raw SQL in templates
  - do not hardcode credentials
  - do not bypass CSRF protection
architectureRules:
  - keep business logic in apps, not in views
  - use DRF serializers for validation
  - prefer select_related and prefetch_related to avoid N+1 queries
prohibitedActions:
  - avoid direct SQL execution from views or serializers
  - do not bypass authentication on dashboards API
  - do not enable broad CORS in production
notes:
  - ensure migrations are created and applied before API changes
  - document endpoints and data models for QA\n\nRecommended Project Structure

\nmyproject/
├─ manage.py
├─ config/
│  ├─ __init__.py
│  ├─ settings.py
│  ├─ urls.py
│  └─ wsgi.py
├─ apps/
│  ├─ dashboards/
│  │  ├─ __init__.py
│  │  ├─ models.py
│  │  ├─ views.py
│  │  ├─ serializers.py
│  │  └─ templates/
│  └─ questions/
│     ├─ __init__.py
│     ├─ models.py
│     └─ views.py
├─ api/
│  ├─ serializers.py
│  └─ urls.py
├─ frontend/
│  ├─ package.json
│  └─ src/
│     └─ components/
│        └─ Dashboard.jsx
├─ requirements.txt
└─ Dockerfile\n\nCore Engineering Principles

\n\n  - Design for testability first: unit tests for models and serializers, integration tests for APIs
\n  - Keep business logic in Django apps; separate concerns with DRF for API endpoints and React for UI
\n  - Validate all input; use Django validators and DRF serializers with strict field definitions
\n  - Security by default: CSRF, proper authentication, and restricted permissions
\n  - Performance conscious: use select_related, prefetch_related, and caching where appropriate
\n  - Observability: structured logging, metrics, and error reporting in production
\n\n\nCode Construction Rules

\n\n  - Models must include LearnerQuestion, Dashboard, and DashboardMetric with clear relationships
\n  - DRF serializers enforce required fields and validation messages
\n  - API views implement pagination, filtering by tags, and search on learner questions
\n  - Frontend components consume stable JSON shapes; version API responses
\n  - Use environment-driven configuration for database connections and feature flags
\n\n\nSecurity and Production Rules

\n\n  - Store secrets in environment variables; never commit to repo
\n  - Harden DB access; restrict user's permissions to dashboards data only
\n  - Enable CSRF protection for state-changing endpoints
\n  - Use HTTPS in production; configure allowed hosts and CORS properly
\n  - Rotate keys and implement audit logging for administrative actions
\n\n\nTesting Checklist

\n\n  - Unit tests for models and serializers with pytest-django
\n  - API integration tests using DRF test client or APIClient
\n  - End-to-end tests of dashboard rendering with a headless browser
\n  - Static analysis and linting in CI; enforce pre-commit hooks
\n  - Deployment tests for migrations, seed data, and API stability
\n\n\nCommon Mistakes to Avoid

\n\n  - Over-fetching large datasets; fetch only needed fields
\n  - Missing input validation leading to runtime errors
\n  - Ignoring security best practices for API endpoints
\n  - Skipping tests or relying on fragile integration tests
\n  - Coupling frontend too tightly to backend structure
\n\n\nFAQ

\nHow does this Cursor Rules Template help in Django course dashboards?

\nThis template gives you a Django-first pattern for transforming learner questions into dashboard insights. It covers models, serializers, API endpoints, and a React UI contract, all guided by Cursor AI to produce reliable, repeatable results.

\nWhat data models are recommended?

\nRecommended models include LearnerQuestion, Dashboard, DashboardMetric, QuestionTag, and UserDashboardPermission. Relationships should minimize N+1 queries and support efficient aggregation for KPI charts.

\nHow should authentication be handled for API endpoints?

\nUse DRF with JWT tokens or OAuth. Enforce per-endpoint permissions, short-lived access tokens, and token rotation. Do not expose admin endpoints publicly.

\nHow do you test dashboards and APIs?

\nWrite unit tests for models and serializers, integration tests for API endpoints, and end-to-end tests for dashboard UI. Use pytest-django and a CI workflow to run tests on every PR.

\nWhat are common pitfalls to avoid?

\nAvoid unindexed search on questions, avoid N+1 queries by using select_related/pre...\n

\n

Related implementation resources: AI Use Case for Software Agencies Using Github Copilot To Accelerate Boilerplate Code Generation for New Client Mvps and Domain-Specific Skill Files for Production Dashboards: Reusable AI Workflows for Enterprise AI.