markdown-site / rules
Cursor rule628 starsChanged 7 months agoMITView on GitHub
Writing style guide with AI detection avoidance. For tweets, LinkedIn, blogs, READMEs, commits. Activate with @write
1 other project uses a version of this.
Adopted by
Most recently taken up by
- waynesutton/opensyncword for word, first seen Feb 2, 2026
Other versions1 project uses a version of this.
Word for word · 1
- waynesutton/opensync★ 410100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Where files are headingNew Cursor rule files have more rules about planning and tracking tasks, and fewer about code style.
Of the Cursor rule files we read, the 4,183 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository40 other files it gives its agents.
- AGENTS.mdAGENTS.md
- public/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .cursor/rules/convex2.mdcCursor rule
- .cursor/rules/convex-doctor.mdcCursor rule
- .cursor/rules/convex-write-conflicts.mdcCursor rule
- .cursor/rules/dev2.mdcCursor rule
- .cursor/rules/gitruels.mdcCursor rule
- .cursor/rules/help.mdcCursor rule
- .cursor/rules/rulesforconvex.mdcCursor rule
- .cursor/rules/sec-check.mdcCursor rule
- .cursor/rules/task.mdcCursor rule
- .cursor/rules/workflow.mdcCursor rule
- public/llms.txtllms.txt
- convex-create-componentSkill
- convex-migration-helperSkill
- convex-performance-auditSkill
- convex-quickstartSkill
- convex-setup-authSkill
- convexSkill
- impeccableSkill
- convex-quickstartSkill
- convex-setup-authSkill
- devSkill
- function-creatorSkill
- gitrulesSkill
- helpSkill
- migration-helperSkill
- react-effect-decisionSkill
- real-time-backendSkill
- schema-builderSkill
- sec-checkSkill
- workflowSkill
- writeSkill
- convex-doctorSkill
- convex-return-validatorsSkill
- convex-self-hostingSkill
- create-prdSkill
- robel-authSkill
- update-project-docsSkill
The file
Show its rules and text
We split this write.mdc into the rules it gives an agent
23 rules. About 0 are common, 23 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈23
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
Use this rule when writing documentation, README files, comments, commit messages, or any other user facing text.
- Distinctive: line 32
Every piece of content follows this framework:
- Distinctive: line 34
One person: Write to a specific person, not an audience.
- Distinctive: line 42
Before publishing, answer these:
- Distinctive: line 50
If any answer is no, revise before publishing.
- Distinctive: line 92
Do not bury the takeaway
- Distinctive: line 127
No emojis unless requested.
- Distinctive: line 163
No H3s unless absolutely necessary
- Distinctive: line 186
Start with what it does, not what it is
- Distinctive: line 203
No period at the end
- Distinctive: line 272
If you mention a tool, show the exact command or snippet
- Distinctive: line 378
Never use these words: delve, intricate, pivotal, comprehensive, multifaceted, facilitate, encompass, underscore, testament, notably, …
- Distinctive: line 383
Never start sentences with:
- Distinctive: line 388
When it comes to
- Distinctive: line 395
Negative parallelism: Do not say "not just X, but Y." State what it is.
- Distinctive: line 396
Vague attribution: Do not say "experts believe." Name sources or remove.
- Distinctive: line 397
Setup pivot conclusion: Not every paragraph needs "however" and resolution.
- Distinctive: line 398
Symmetrical structures: Do not balance pros and cons evenly by default.
- Distinctive: line 402
No em dashes between words
- Distinctive: line 404
No emojis unless requested
- Distinctive: line 405
No title case in headings
- Distinctive: line 411
Use exact numbers, not ranges.
- Distinctive: line 414
Not every paragraph needs a neat resolution.
≈ “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.
Files
--- description: Writing style guide with AI detection avoidance. For tweets, LinkedIn, blogs, READMEs, commits. Activate with @write globs: alwaysApply: false --- # Writing style rules Use this rule when writing documentation, README files, comments, commit messages, or any other user facing text. ## Triggers | Trigger | Output | |---|---| | `write:tweet` or `write:x` | X or Twitter post | | `write:linkedin` | LinkedIn post | | `write:blog` | Blog post | | `write:readme` | README | | `write:commit` | Git commit message | | `write:docs` | Developer documentation | | `write:feature` | Feature post | | `write:convex` | Convex specific content | | `write:tip` | Quick tip | Example usage: * "write:tweet about real time sync" * "write:blog on authentication patterns" * "write:feature for our new search API" ## Rule of one Every piece of content follows this framework: * **One person**: Write to a specific person, not an audience. * **One problem**: State the single problem they face. * **One cause**: Identify the root cause. * **One difference**: Explain what the solution does differently. * **One action**: End with one clear next step. ### Rule of one checklist Before publishing, answer these: * [ ] Can I name the one person this is for? * [ ] Can the problem fit in one sentence? * [ ] Is the root cause obvious? * [ ] Can I explain the difference in one breath? * [ ] Is there only one action at the end? If any answer is no, revise before publishing. ## When to use this rule Use it for: * X or Twitter posts * LinkedIn content * Blog posts * README files * Git commits * Product announcements * Developer documentation * Feature posts Important: this is for standalone writing. Do not update project files like files.md, changelog.md, or README.md when using this rule. ## Voice styles Pick a voice that fits the output: | Style | Characteristics | Use for | |---|---|---| | Technical educator | Clear, structured, educational | Technical content, tutorials, READMEs | | Conversational dev | Warm, witty, approachable | Social posts, personal takes | | Analytical thinker | Data driven, bold, opinionated | Thought leadership, threads | | Aphorist | Compressed, timeless, pithy | Short posts, one liners | | Founder voice | Experience backed, energetic | Startup content, advice | | Systems thinker | Frameworks, mental models | Long form, technical takes | | Dev culture | Relatable, playful, authentic | Community content, personality | | Data storyteller | Visual, analytical, trend focused | AI trends, market insights | | Enterprise pro | Professional, strategic, precise | Enterprise SaaS, B2B content | | Community builder | Encouraging, personal, supportive | Career growth, DevRel | | Learn in public | Educational, transparent, iterative | Developer career, web dev | | Product thinker | Community first, growth minded | Community building, growth | ## Core principles ### Stand out by being you You do not stand out online by saying the same things as everyone else. Say what you think, feel, and believe. Consensus takes are forgettable. Your take is not. ### Lead with value * First sentence does the work * Do not bury the takeaway * Readers scroll fast ### Be direct, not blunt * Say what you mean * Confidence without arrogance * Contractions are fine ### Technical, not alienating * Define terms when helpful * Complex ideas deserve simple language * Let code speak when it can ### Share what you actually know * Personal experience beats generic advice * Specific examples beat abstract principles * Acknowledge what you do not know ## Formats by content type ### write:tweet (or write:x) ``` [Clear statement or observation] [Supporting point or context] [Optional: question or call to action] ``` Rules: * First 2 lines visible in preview. Make them count. * 280 characters forces compression. Use it. * One idea per post. * No hashtags. * No emojis unless requested. ### write:linkedin ``` [Hook that stops the scroll] [Story or context in short paragraphs] [Insight or lesson] [Call to action or question] ``` Rules: * Short paragraphs for mobile * Professional but not corporate * Personal stories perform well * One clear takeaway ### write:blog ``` # Title (sentence case, max 70 characters) [Opening that states the value immediately] ## Section heading [Max 300 words per section] ## Section heading [Use bullet points or tables where helpful] ``` Rules: * Sentence case for all headings * No H3s unless absolutely necessary * Fact check everything * Lead with why it matters * Max 5 sections ### write:readme ``` # Project name [One sentence: what this does] ## Getting started [Minimal steps to run] ## Usage [Code examples] ## API or configuration [Reference docs] ``` Rules: * Start with what it does, not what it is * Code examples over descriptions * Keep it scannable ### write:commit ``` [type]: [short description] [Optional: longer explanation if needed] ``` Types: feat, fix, docs, style, refactor, test, chore Rules: * Present tense: "add feature" not "added feature" * 50 characters max for subject line * No period at the end ### write:docs ``` # [Task or concept name] [One sentence: what this page helps you do] ## Before you start [Prerequisites, if any] ## Steps 1. [Action] 2. [Action] 3. [Action] ## Example [Code snippet] ## Related [Links to related docs] ``` Rules: * Task oriented, not feature oriented * Show, do not tell * Working code examples required * Keep prerequisites minimal ### write:feature ``` ## [Feature name] **What it is** [One sentence description] **Who it is for** [Specific user or role] **The problem it solves** [One problem, clearly stated] **How it works** [High level explanation, 2 to 3 sentences max] **Try it** [One clear action: link, command, or next step] ``` Rules: * Five sections only * Each section answers one question * Skip the hype. State facts. * End with a single action ### write:tip ``` [One sentence tip] [Concrete example, ideally code] [One line why this works] ``` Rules: * Make it shippable in under a minute * If you mention a tool, show the exact command or snippet * End with one action or takeaway, not a question pile ### write:convex New guide or tutorial: ``` New guide: [topic] [What you will learn or build] [Link] ``` Convex tip: ``` Convex tip: [Pattern in one sentence] [Code snippet showing it] [Why this works] ``` What to avoid: * Generic praise * Comparisons that trash competitors * Overpromising * Screenshots without context * Sharing customer work without permission * Empty engagement bait Content mix for Convex: * 40 percent educational: tutorials, tips, patterns * 30 percent community: spotlights, customer stories * 20 percent product: updates, features, changelog * 10 percent personal: projects, learnings, opinions ## Templates ### Technical educator ``` [Clear headline] Here is what matters: * Point 1 * Point 2 * Optional: one more point [Code snippet or visual] [Resource link] ``` ### Analytical thinker ``` [Counterintuitive opening] [Common belief] [Your argument with evidence] [Implications] ``` ### Data storyteller ``` [Trend observation with a specific data point] [Context: why this matters now] [Visual reference or chart if applicable] [What to watch next] ``` Rules: * Lead with numbers * Connect data to broader movements * End with a forward looking signal ### Learn in public ``` [Thing I just figured out] [How I got there, mistakes included] [Resources or links for others] ``` Rules: * Document the journey * Share rough drafts * Credit sources ## AI detection avoidance ### Banned vocabulary Never use these words: delve, intricate, pivotal, comprehensive, multifaceted, facilitate, encompass, underscore, testament, notably, crucial, underpins, realm, landscape, tapestry, moreover, furthermore, additionally, specifically, importantly, consequently, therefore, thus, myriad, plethora, nuanced, holistic, meticulous, versatile, leverage, synergy, ecosystem, paradigm shift, disruptive, scalable, seamless, empower, innovative, transformative, robust, agile, dynamic, cutting edge, next gen, revolutionary, breakthrough, game changer, supercharge, unlock, groundbreaking, ai powered, ai-powered ### Banned sentence openers Never start sentences with: * Dive into / Delve into * It is important to note * In conclusion / In summary * Based on the information provided * When it comes to * In today’s digital age * Let’s explore ### Banned patterns * **Rule of three**: AI groups items in threes. Vary list lengths. * **Negative parallelism**: Do not say "not just X, but Y." State what it is. * **Vague attribution**: Do not say "experts believe." Name sources or remove. * **Setup pivot conclusion**: Not every paragraph needs "however" and resolution. * **Symmetrical structures**: Do not balance pros and cons evenly by default. Be asymmetric. ### Style markers to avoid * No em dashes between words * No hashtags * No emojis unless requested * No title case in headings * No excessive formatting ### How to write human * Vary sentence structure. Mix short and long. Fragments work. * Use exact numbers, not ranges. * Name specific sources, not "experts say." * Show your thinking: "I tried X, but it did not work because..." * Not every paragraph needs a neat resolution. ## Before publishing checklist Rule of one: * [ ] One person * [ ] One problem * [ ] One cause * [ ] One difference * [ ] One action Quality: * [ ] Clear takeaway in the first line * [ ] No banned vocabulary * [ ] No banned sentence openers * [ ] No vague attributions * [ ] No overbalanced pros and cons * [ ] No excessive formatting ## Core principle AI writes to sound authoritative. Humans write to communicate. AI smooths rough edges. Human writing has texture. AI balances everything. Human writing has opinions. Be clear. Be useful. Have a point of view.
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
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.

