Full stack Vibe Coding (Cursor/Warp)

vibe_coding.md

Bootstrap

CONTEXT: You are building a production-ready todo application using Ruby on Rails. This is a learning project to understand Rails MVC architecture, ActiveRecord ORM, and RESTful conventions. Target: Individual users managing personal tasks locally.

ACTION: Create a complete Rails todo application with SQLite3 that allows users to:

• Add, edit, delete, and mark tasks as complete
• Filter tasks (all/active/completed)
• View task details and statistics
• Persist data with proper validations
• Deploy-ready with tests

FORMAT: Build as a Rails 7+ application with:

• Backend: Rails API + Views (Turbo/Hotwire preferred)
• Database: SQLite3 with ActiveRecord migrations
• Frontend: Rails views with Tailwind CSS OR Stimulus.js
• Testing: RSpec or Minitest
• Architecture: Standard Rails MVC with RESTful routes

EXAMPLES: Task model attributes:

• title (string, required, max 200 chars)
• description (text, optional)
• completed (boolean, default: false)
• due_date (date, optional)
• priority (enum: low/medium/high)
• timestamps (created_at, updated_at)

RESTful routes pattern:

• GET /tasks → tasks#index
• GET /tasks/new → tasks#new
• POST /tasks → tasks#create
• GET /tasks/:id → tasks#show
• GET /tasks/:id/edit → tasks#edit
• PATCH /tasks/:id → tasks#update
• DELETE /tasks/:id → tasks#destroy
• PATCH /tasks/:id/toggle → tasks#toggle_complete

GROUNDING:

• Follow Rails conventions (RESTful routes, MVC, fat models/skinny controllers)
• Use ActiveRecord validations and callbacks
• Implement strong parameters for security
• Use Rails helpers (form_with, link_to, turbo_frame_tag)
• Include database indexes for query optimization
• Write tests for models and controllers
• Use Rails generators appropriately
• Follow Ruby style guide (Rubocop standards)

Cursor Setup

C — Context

You are working on a codebase using Cursor IDE, an AI-powered development environment. The goal is to maximize AI utility, maintain project clarity, and ensure agent-driven workflows are robust and reproducible. Guidance and intent should be encoded so AI has "shared memory" about the product, process, and coding conventions.

A — Artifacts

List of critical documents and rules:

Add anything else you deem neccessary.

Artifact	Purpose / Usage	Example Path
PRD.md	Product Requirements Document — main source of project truth	.cursor/prd/PRD.md
README.md	Developer-facing summary and orientation document	/README.md
.cursor/index.mdc	Global Cursor rules/guidance file affecting all Cursor-driven work	.cursor/index.mdc
.cursor/rules/*.mdc	Contextual rules for specific features/modules (e.g. SEO, database)	.cursor/rules/seo.mdc, .cursor/rules/db.mdc
workflow_state.md	Tracks AI agent progress and execution checkpoints	.cursor/workflow_state.md
context.map.json	Maps directories/components so AI can navigate the repo smartly	.cursor/context.map.json
architecture.md	Documents system/module relationships and design philosophy	/docs/architecture.md
plan.md / feature_plan.md	Short-term plans and tactical checklists for incremental development	.cursor/tasks/plan.md
cursor_rules_global.mdc	User-level global rules, used across many projects	~/Library/Application Support/Cursor/rules/
design_doc.md	UX/UI design guidance linked to PRD	.cursor/prd/design_doc.md
schema.sql / schema.md	Database schema definitions	/database/schema.sql
api_reference.md	Specs for internal/external APIs	/docs/api_reference.md
glossary.yml	Domain terms/abbreviations for business context	.cursor/glossary.yml

F — Flow (Typical Usage Order)

1. Draft PRD.md, add to .cursor/prd/
2. Write initial README.md and architecture.md to describe setup and global design
3. Create global rules in .cursor/index.mdc and add any cross-cutting rules as needed
4. Add feature/module rules as new directories/files in .cursor/rules/
5. As project evolves, update workflow_state.md to document next agentic steps
6. For new components, map their context in context.map.json
7. Use plan.md/feature_plan.md for specific actionable project tasks and daily checkpoints
8. Document designs, schema, APIs, and glossary for all technical/business clarity

E — Example Rule Block

A sample .cursor/rules/general.mdc file:

<cursor_rule>

Code Style

• Use strict typing and explicit parameter definitions
• Prefer functional programming; OOP only where interfaces are required
• Follow DRY, KISS, YAGNI principles

Error Handling

• Always raise descriptive errors

Repository Practice

• Read README.md if rules are missing </cursor_rule>