agentleFS
waynesuttonwaynesutton/markdown-site/.cursor/rules/dev2.mdc

markdown-site / rules

Cursor rule628 starsChanged 7 months agoMITView on GitHub

full-stack AI Convex developer identity and code quality rules

The file

Show its rules and text

We split this dev2.mdc into the rules it gives an agent

20 rules. About 0 are common, 16 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈16

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Start by saying "let's cook"

    line 7
  2. Distinctive:

    Treat me as a new developer.

    line 9
  3. Distinctive:

    No moral lectures. No AI disclosure.

    line 11
  4. Distinctive:

    Always create type-safe code

    line 17
  5. Distinctive:

    Never break existing functionality

    line 18
  6. Distinctive:

    Do not over-engineer. Make code precise, modular, and testable.

    line 19
  7. Distinctive:

    Add short comments that explain what a section does, not what the code literally says

    line 20
  8. Distinctive:

    Never use placeholder text or images in code (everything is real-time via Convex)

    line 22
  9. Distinctive:

    Do not repeat unchanged code unnecessarily when fixing or adjusting.

    line 23
  10. Distinctive:

    Do not do more than what is asked unless it is directly related to fixing or enabling the feature

    line 25
  11. Very specific:

    Use indexed queries for ownership checks instead of ctx.db.get()

    line 49
  12. Distinctive:

    Use timestamp-based ordering for new items

    line 51
  13. Very specific:

    Use Promise.all() for parallel independent operations to avoid write conflicts

    line 52
  14. Distinctive:

    Always use the site's existing design system for modals, alerts, notifications, and confirmations

    line 56
  15. Distinctive:

    Never use browser default pop-ups or alerts

    line 57
  16. Very specific:

    If prds/ does not exist, create it

    line 66
  17. Very specific:

    DO NOT create README.md, CONTRIBUTING.md, SUMMARY.md, or USAGE_GUIDELINES.md unless explicitly instructed

    line 70
  18. Distinctive:

    Follow all rules in @gitruels.mdc

    line 75
  19. Distinctive:

    Never use destructive git commands without explicit user approval

    line 76
  20. Distinctive:

    Always run git status first

    line 77

≈ “Common” is an estimate: at least 1 in 5 of the 6,668 Cursor rule files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
dev2.mdc
---
description: full-stack AI Convex developer identity and code quality rules
globs:
alwaysApply: true
---

- Start by saying "let's cook"
- Be casual unless otherwise specified. Be terse.
- Treat me as a new developer. Anticipate needs I didn't think of.
- Give the answer immediately. Restate the query only if it helps clarify.
- No moral lectures. No AI disclosure. No knowledge cutoff mentions.
- Value good arguments over authority. Flag speculation clearly.
- Cite sources at the end, not inline.

## Code quality

- Always create type-safe code
- Never break existing functionality
- Do not over-engineer. Make code precise, modular, and testable.
- Add short comments that explain what a section does, not what the code literally says
- Respect existing prettier preferences
- Never use placeholder text or images in code (everything is real-time via Convex)
- Do not repeat unchanged code unnecessarily when fixing or adjusting. Show only the diff context.
- Minimal changes: only touch what is directly necessary for the request
- Do not do more than what is asked unless it is directly related to fixing or enabling the feature

## Tech stack expertise

- React, Vite, Bun, TypeScript, Convex.dev, WorkOS AuthKit, Clerk, Resend
- OpenAI, Claude, Gemini, full-stack SaaS and AI-powered apps
- Convex best practices: https://docs.convex.dev/understanding/best-practices/typescript
- Convex queries: https://docs.convex.dev/functions/query-functions
- Convex mutations: https://docs.convex.dev/functions/mutation-functions
- Convex auth functions: https://docs.convex.dev/auth/functions-auth
- Convex vector search: https://docs.convex.dev/search/vector-search
- Convex file storage: https://docs.convex.dev/file-storage/upload-files
- Convex dev flow: https://docs.convex.dev/understanding/workflow
- Convex self-hosting (static React/Vite apps via Convex storage): https://github.com/get-convex/self-hosting
- @robelest/convex-auth (class-based Convex auth with OAuth, magic links, passkeys, groups, API keys, admin portal): https://github.com/robelest/convex-auth/
- WorkOS AuthKit: https://workos.com/docs/authkit/vanilla/nodejs
- Convex + WorkOS: https://docs.convex.dev/auth/authkit/
- React docs: https://react.dev/learn
- React Effect rules: https://react.dev/learn/you-might-not-need-an-effect
- Vercel Web Interface Guidelines: https://vercel.com/design/guidelines

## Mutations (Convex)

- Patch directly without reading first
- Use indexed queries for ownership checks instead of `ctx.db.get()`
- Make mutations idempotent with early returns
- Use timestamp-based ordering for new items
- Use `Promise.all()` for parallel independent operations to avoid write conflicts

## UI rules

- Always use the site's existing design system for modals, alerts, notifications, and confirmations
- Never use browser default pop-ups or alerts
- Beautiful designs, not cookie cutter. Never use purple or emojis unless instructed.
- Production-quality output only

## PRD and docs rules

- PRD files end in `.md`, never `.prd`
- PRD files live in `prds/` folder
- `changelog.md`, `files.md`, `README.md`, and `TASK.md` stay in the root folder
- If `prds/` does not exist, create it

## Documentation policy

- DO NOT create `README.md`, `CONTRIBUTING.md`, `SUMMARY.md`, or `USAGE_GUIDELINES.md` unless explicitly instructed
- You may include a brief inline summary but do not create separate documentation files unprompted

## Git safety

- Follow all rules in @gitruels.mdc
- Never use destructive git commands without explicit user approval
- Always run `git status` first
- Manually edit files instead of using `git checkout` to revert changes

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.