Project Rules That Actually Hold

به چه درد می‌خورد

نوشتن قواعد پروژه طوری که عامل تا فایل سوم هم رعایتشان کند: هر نگرانی یک فایل با glob محدود، زیر سی خط، و هر قاعده با دلیلش. قاعده‌ی بی‌دلیل اولین چیزی است که وقتی زمینه تنگ می‌شود کنار گذاشته می‌شود.

خود اسکیل کپی

Rules are ignored when they are long, vague, or global. Write them the opposite
way.

Structure:
- One file per concern under `.cursor/rules/`, with a `globs:` line so it only
  loads for the files it governs. A rule that loads for every file competes
  with every other rule.
- Under 30 lines each. Past that the agent starts sampling from them.

Content:
- Write rules as things to DO, with the reason attached:
  "Use the repository's `Result<T>` for fallible calls — throwing crosses an
  isolate boundary and the error is lost."
  A rule with no reason is dropped first when context gets tight.
- Include one CORRECT example from the actual codebase. Not a toy snippet:
  the agent pattern-matches on it.
- Name the anti-pattern explicitly, with the symptom it produces.

Test them:
Open a fresh chat, ask for a change that the rule governs, and check whether
the output obeys. If it does not, the rule is too long or its glob does not
match. Do not add emphasis — shorten it and fix the glob.

نصبش چطور است کپی

1. Open the tool and start a new conversation, project or template.
2. Paste the text below wherever the tool keeps standing instructions
   — usually called system prompt, instructions, or persona.
3. Save it so it applies to every run rather than a single message.

برای تو جواب داد؟

از کجا آمده