Feature request for product/service
Chat
Describe the request
Feature request: Configurable communication style (override built-in “technical blog post” default)
Summary
Add first-class Communication Style settings so users can control how the agent writes — in chat, drafts, PRs, and other outputs — and can reliably override Cursor’s built-in default to “write like an excellent technical blog post.”
The problem is not just that the default exists. The problem is that user-configured overrides do not reliably win. Users who explicitly tell the agent to ignore the blog-post rule still get long, polished, overly technical replies. A settings-level solution with clear precedence is needed; more user rules are not enough.
Problem
Built-in default
Cursor ships a default user rule that instructs the agent to “write like an excellent technical blog post” — precise, well-structured, complete sentences, high prose quality. That works for some users. It does not work for everyone, and it does not work for every context.
Workarounds exist — and they fail in practice
Users who want a different voice today must engineer around the default:
- Custom user rules that explicitly say to ignore the blog-post instruction
- Global rules with the same override, loaded on every session
- Session hooks that inject voice reminders at thread start
- External context files (e.g. a personal communication-style doc) required reading every session
- Per-project rules repeating the same preferences
These workarounds are insufficient. Even with a custom rule and a global rule both stating that communication-style preferences override the blog-post rule at all times, the agent still defaults to blog-post behavior: too many words, too much structure, too technical a register for simple chat.
That suggests the built-in rule sits higher in the instruction stack than user-authored overrides, or that its influence is strong enough that competing rules do not consistently displace it. Either way, the user experience is broken: you configure preferences, you state them clearly, and the agent still writes like a technical blog post.
Secondary pain (still real)
- No context switching — One global tone for chat, commits, PRs, Slack drafts, and stakeholder email is usually wrong.
- High setup cost — Reproducing personal voice across machines, projects, and team members is manual and fragile.
- False confidence — Users believe they have fixed the problem with rules; they have not.
- Discoverability — New users do not know the default exists or that their overrides may be ignored.
Proposed solution
Add a Communication Style section in Cursor Settings (user-level, with optional project overrides).
1. Style profiles by context
Separate defaults for distinct output modes:
| Context | Example use |
|---|---|
| Chat | Day-to-day agent conversation |
| Code comments / docstrings | In-editor generation |
| Commit messages | Git workflow |
| PR descriptions | Review handoff |
| External writing | Email, Slack, Confluence, stakeholder updates |
Each context gets its own profile instead of one global “how to talk to me” rule.
2. Preset styles + custom description
For each context, let users either:
A. Choose a preset:
- Technical blog post (current default)
- Simple / to-the-point — minimal words, lead with the answer, no preamble or recap
- Conversational — warm, direct, informal where appropriate
- Executive summary — non-technical, outcome-focused, scannable
- Formal / documentation — structured, neutral, suitable for specs and runbooks
B. Write a custom style description — free text the agent follows for that context.
Presets should ship as editable starting points, not locked templates.
3. Explicit override with guaranteed precedence
When a user sets a Communication Style profile, it must replace (not supplement) the integrated blog-post rule for that context.
Suggested precedence (highest wins):
- Explicit instruction in the current message (“write this as an executive summary”)
- Project-level communication style (if set)
- User-level communication style for that context
- Cursor built-in default (blog post)
Critical requirement: User-level Communication Style settings must win over the built-in blog-post rule. Today, custom and global user rules that say “ignore the blog-post rule” do not reliably achieve that. This feature should make override behavior deterministic and testable.
Users should see in Settings which layer is active and whether the built-in default is overridden.
4. Separate “talk to me” vs “draft for me”
Many users want different behavior for:
- Agent → user (chat): How the agent replies in the thread
- User → audience (drafts): How the agent writes as the user for others
Splitting these avoids optimizing chat for brevity while still producing polished outbound copy when needed.
User stories
- As a senior engineer, I set chat to “simple / to-the-point” and actually get short replies — not blog-post intros I configured rules to forbid.
- As a tech lead, I want PR descriptions in structured technical style while chat stays conversational.
- As a manager, I want stakeholder updates in executive-summary tone without re-prompting every time.
- As a power user, I stop maintaining redundant override rules that the agent ignores anyway.
- As a new Cursor user, I discover and change the default writing style without learning the rules system.
UX sketch
Settings → Agent → Communication Style
Chat replies: [ Simple / to-the-point ▼ ] [ Edit custom... ]
Drafts for others: [ Conversational ▼ ] [ Edit custom... ]
PR / commit text: [ Technical blog post ▼ ] [ Edit custom... ]
Code comments: [ Simple / to-the-point ▼ ] [ Edit custom... ]
☑ Override built-in "technical blog post" rule for configured contexts
☐ Use project override when .cursor/communication-style.json exists
Custom style editor — textarea with guidance (“Describe tone, length, structure, and what to avoid”) and a live preview.
Implementation notes
- Instruction stack — Treat Communication Style as a first-class layer with documented, enforced precedence. Do not rely on users adding more user rules to fight the default.
- Verify override works — Regression tests or evals that confirm a user with “simple / to-the-point” chat style gets measurably shorter, less formal replies than the blog-post default, even when other rules are present.
- Context detection — Map contexts to workflows (chat vs. commit vs. PR vs. comment generation) where possible.
- Export / portability — JSON or markdown export for dotfiles and cross-machine sync.
- Team sharing — Optional
.cursor/communication-style.jsonfor repo-level defaults. - Migration — Detect existing user rules that override writing style; offer to consolidate into Communication Style and deprecate redundant rules.
Concrete example
A user configures:
- Chat: “2 AM mode” — simple language, minimal word count, lead with the point, no recap conclusions, warm and conversational
- PRs: Structured technical summary with test plan
- Email to PM: Executive summary, no engineering jargon unless asked
They also add custom and global rules stating that chat style overrides the blog-post rule.
Today: The agent still writes long, structured, technical blog-post prose in chat.
With this feature: Settings explicitly override the built-in rule per context; the user can remove fragile duplicate rules and get predictable behavior.
Success criteria
- Users can disable or replace the blog-post tone without custom rule hacks.
- Configured style reliably beats the built-in default in practice, not only in documentation.
- Style can differ by context without copy-pasting rules into every project.
- Precedence is predictable, visible, and documented.
- Setup takes minutes; users are not forced into an arms race of override rules.
Optional follow-ups
- Per-agent or per-automation style overrides
- Style preview in onboarding (“how would the agent reply to this prompt?”)
- Team / role templates (IC, EM, PM-facing engineer)
