logicamp/zed
3
0
Fork 0
Code Issues Pull Requests Actions 9 Packages Projects Releases Wiki Activity

logiguard fork v3: full patch set on verified 8c74db0 tree

Browse Source 
Includes prior-session patches (carry forward so the app compiles):
  - crates/gpui/build.rs: cross-compile manifest fix
  - crates/gpui/src/platform.rs: PlatformWindow::activate_with_token trait method
  - crates/gpui/src/window.rs: Window::activate_with_token public API
  - crates/gpui_linux/src/linux/wayland/window.rs: WaylandWindow::activate_with_token + activate() keyboard-serial fix

Plus the focus-serial fix:
  - serial.rs: SerialKind::KeyboardEnter
  - client.rs: store wl_keyboard.enter serial; latest_serial_of()

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Mohamad Khani
2026-07-14 01:52:12 +03:30
commit b9819977a5
3984 changed files with 1487015 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

380
docs/.conventions/CONVENTIONS.md Normal file
View File

@@ -0,0 +1,380 @@
# Zed Documentation Conventions
This document covers structural conventions for Zed documentation: what to document, how to organize it, and when to create new pages.
For voice, tone, and writing style, see the [brand-voice/](./brand-voice/) directory, which contains:
- `SKILL.md` — Core voice principles and workflow
- `rubric.md` — 8-point scoring criteria for quality
- `taboo-phrases.md` — Patterns and phrases to avoid
- `voice-examples.md` — Before/after transformation examples
---
## What Needs Documentation
### Document
- **New user-facing features** — Anything users interact with directly
- **New settings or configuration options** — Include the setting key, type, default value, and example
- **New keybindings or commands** — Use `{#action ...}` and `{#kb ...}` syntax
- **All actions** — Completeness matters; document every action, not just non-obvious ones
- **New AI capabilities** — Agent tools, providers, workflows
- **New providers or integrations** — LLM providers, MCP servers, external agents
- **New tools** — Agent tools, MCP tools, built-in tools
- **New UI panels or views** — Any new panel, sidebar, or view users interact with
- **Public extension APIs** — For extension developers
- **Breaking changes** — Even if the fix is simple, document what changed
- **Version-specific behavior changes** — Include version callouts (e.g., "In Zed v0.224.0 and above...")
### Skip
- **Internal refactors** — No user-visible change, no docs
- **Bug fixes** — Unless the fix reveals that existing docs were wrong
- **Performance improvements** — Unless user-visible (e.g., startup time)
- **Test changes** — Never document tests
- **CI/tooling changes** — Internal infrastructure
---
## Page vs. Section Decisions
### Create a new page when:
- Introducing a **major feature** with multiple sub-features (e.g., Git integration, Vim mode)
- The topic requires **extensive configuration examples**
- Users would search for it **by name** (e.g., "Zed terminal", "Zed snippets")
- It's a **new category** (e.g., a new AI provider type)
### Add to an existing page when:
- Adding a **setting** to a feature that already has a page
- Adding a **keybinding** to an existing feature
- The change is a **minor enhancement** to existing functionality
- It's a **configuration option** for an existing feature
### Examples
| Change | Action |
| ------------------------------------ | -------------------------------------- |
| New "Stash" feature for Git | Add section to `git.md` |
| New "Remote Development" capability | Create `remote-development.md` |
| New setting `git.inline_blame.delay` | Add to existing Git config section |
| New AI provider (e.g., "Ollama") | Add section to `llm-providers.md` |
| New agent tool category | Potentially new page, depends on scope |
---
## Document Structure
### Frontmatter
Every doc page needs YAML frontmatter:
```yaml
---
title: Feature Name - Zed
description: One sentence describing what this page covers. Used in search results.
---
```
- `title`: Feature name, optionally with "- Zed" suffix for SEO
- `description`: Concise summary for search engines and link previews
- Keep frontmatter values as simple single-line `key: value` entries (no
multiline values, no quotes) for compatibility with the docs postprocessor
#### Frontmatter SEO Guidelines
- Choose one primary keyword/intent phrase for each page
- Write unique `title` values that clearly state the page topic and target user
intent; aim for ~50-60 characters
- Write `description` values that summarize what the reader can do on the page;
aim for ~140-160 characters
- Use the primary keyword naturally in the `title` and page body at least once
(usually in the opening paragraph); avoid keyword stuffing
### Section Ordering
1. **Title** (`# Feature Name`) — Clear, scannable
2. **Opening paragraph** — What this is and why you'd use it (1-2 sentences)
3. **Getting Started / Usage** — How to access or enable it
4. **Core functionality** — Main features and workflows
5. **Configuration** — Settings, with JSON examples
6. **Keybindings / Actions** — Reference tables
7. **See Also** — Links to related docs
### Section Depth
- Use `##` for main sections
- Use `###` for subsections
- Avoid `####` unless absolutely necessary — if you need it, consider restructuring
### Anchor IDs
Add explicit anchor IDs to sections users might link to directly:
```markdown
## Getting Started {#getting-started}
### Configuring Models {#configuring-models}
```
Use anchor IDs when:
- The section is a common reference target
- You need a stable link that won't break if the heading text changes
- The heading contains special characters that would create ugly auto-generated anchors
---
## Formatting Conventions
### Code Formatting
Use inline `code` for:
- Setting names: `vim_mode`, `buffer_font_size`
- Keybindings: `cmd-shift-p`, `ctrl-w h`
- Commands: `:w`, `:q`
- File paths: `~/.config/zed/settings.json`
- Action names: `git::Commit`
- Values: `true`, `false`, `"eager"`
### Action and Keybinding References
Use Zed's special syntax for dynamic rendering:
- {#action git::Commit} — Renders the action name
- {#kb git::Commit} — Renders the keybinding for that action
This ensures keybindings stay accurate if defaults change.
### JSON Examples
Always use the `[settings]` or `[keymap]` annotation:
```json [settings]
{
"vim_mode": true
}
```
```json [keymap]
{
"context": "Editor",
"bindings": {
"ctrl-s": "workspace::Save"
}
}
```
### Tables
Use tables for:
- Action/keybinding reference lists
- Setting options with descriptions
- Feature comparisons
Keep tables scannable — avoid long prose in table cells.
### Paragraphs
- Keep paragraphs short (2-3 sentences max)
- One idea per paragraph
- Use bullet lists for multiple related items
### Pronouns
Minimize vague pronouns like "it", "this", and "that". Repeat the noun so readers know exactly what you're referring to.
**Bad:**
> The API creates a token after authentication. It should be stored securely.
**Good:**
> The API creates a token after authentication. The token should be stored securely.
This improves clarity for both human readers and AI systems parsing the documentation.
### Callouts
Use blockquote callouts for tips, notes, and warnings:
```markdown
> **Note:** This feature requires signing in.
> **Tip:** Hold `cmd` when submitting to automatically follow the agent.
> **Warning:** This action cannot be undone.
```
### Version-Specific Notes
When behavior differs by version, be explicit:
```markdown
> **Note:** In Zed v0.224.0 and above, tool approval is controlled by `agent.tool_permissions.default`.
```
Include the version number and what changed. This helps users on older versions understand why their behavior differs.
---
## Cross-Linking
### Internal Links
Link to other docs using relative paths:
- `[Vim mode](./vim.md)`
- `[AI configuration](./ai/configuration.md)`
### External Links
- Link to `zed.dev` pages when appropriate
- Link to upstream documentation (e.g., Tree-sitter, language servers) when explaining integrations
### "See Also" Sections
End pages with related links when helpful:
```markdown
## See also
- [Agent Panel](./agent-panel.md): Agentic editing with file read/write
- [Inline Assistant](./inline-assistant.md): Prompt-driven code transformations
```
### SEO Linking Guidelines
- Ensure each page is reachable from at least one other docs page (no orphan
pages)
- For non-reference pages, include at least 3 internal links to related docs
when possible
- Reference pages (for example, `docs/src/reference/*`) can use fewer links when
extra links would add noise
- Add links to closely related docs where they help users complete the next task
- Use descriptive link text that tells users what they will get on the linked
page
- For main feature pages with a matching marketing page, include a relevant
`zed.dev` marketing link in addition to docs links
---
## Language-Specific Documentation
Language docs in `src/languages/` follow a consistent structure:
1. Language name and brief description
2. Installation/setup (if needed)
3. Language server configuration
4. Formatting configuration
5. Language-specific settings
6. Known limitations (if any)
Keep language docs focused on Zed-specific configuration, not general language tutorials.
---
## Settings Documentation
When documenting settings:
1. **Show the Settings Editor (UI) approach first** — Most settings have UI support
2. **Then show JSON** as "or add to your settings file:"
3. **State the setting key** in code formatting
4. **Describe what it does** in one sentence
5. **Show the type and default** if not obvious
6. **Provide a complete JSON example**
Example:
> Configure inline blame in Settings ({#kb zed::OpenSettings}) by searching for "inline blame", or add to your settings file:
>
> ```json [settings]
> {
> "git": {
> "inline_blame": {
> "enabled": false
> }
> }
> }
> ```
For JSON-only settings (complex types without UI support), note this and link to instructions:
> Add the following to your settings file ([how to edit](./configuring-zed.md#settings-files)):
### Settings File Locations
- **macOS/Linux:** `~/.config/zed/settings.json`
- **Windows:** `%AppData%\Zed\settings.json`
### Keymap File Locations
- **macOS/Linux:** `~/.config/zed/keymap.json`
- **Windows:** `%AppData%\Zed\keymap.json`
---
## Terminology
Use consistent terminology throughout:
| Use | Instead of |
| --------------- | -------------------------------------- |
| folder | directory |
| project | workspace |
| Settings Editor | settings UI |
| command palette | command bar |
| panel | sidebar (be specific: "Project Panel") |
---
## Formatting Requirements
All documentation must pass **Prettier** formatting (80 character line width):
```sh
cd docs && npx prettier --check src/
```
Before any documentation change is considered complete:
1. Run Prettier to format: `cd docs && npx prettier --write src/`
2. Verify it passes: `cd docs && npx prettier --check src/`
---
## Quality Checklist
Before finalizing documentation:
- [ ] Frontmatter includes `title` and `description`
- [ ] Page has a clear primary keyword/intent phrase
- [ ] Primary keyword appears naturally in the page body (no keyword stuffing)
- [ ] Opening paragraph explains what and why
- [ ] Settings show UI first, then JSON examples
- [ ] Actions use `{#action ...}` and `{#kb ...}` syntax
- [ ] All actions are documented (completeness matters)
- [ ] Anchor IDs on sections likely to be linked
- [ ] Version callouts where behavior differs by release
- [ ] No orphan pages (linked from somewhere)
- [ ] Non-reference pages include at least 3 useful internal docs links
- [ ] Main feature pages include a relevant `zed.dev` marketing link
- [ ] Passes Prettier formatting check
- [ ] Passes brand voice rubric (see `brand-voice/rubric.md`)
---
## Gold Standard Examples
See `../.doc-examples/` for curated examples of well-documented features. Use these as templates when writing new documentation.
---
## Reference
For automation-specific rules (safety constraints, change classification, output formats), see `docs/AGENTS.md`.

265
docs/.conventions/brand-voice/SKILL.md Normal file
View File

@@ -0,0 +1,265 @@
---
name: brand-writer
description: Write clear, developer-first copy for Zed — leading with facts, grounded in craft.
allowed-tools: Read, Write, Edit, Glob, Grep, AskUserQuestion, WebFetch
user-invocable: true
---
# Zed Brand Writer
Write in Zed's brand voice: thoughtful, technically grounded, and quietly confident. Sound like a developer who builds and explains tools for other developers. Write like the content on zed.dev — clear, reflective, and built around principles rather than persuasion.
## Invocation
```bash
/brand-writer # Start a writing session
/brand-writer "homepage hero copy" # Specify what you're writing
/brand-writer --review "paste copy" # Review existing copy for brand fit
```
## Core Voice
You articulate Zed's ideas, capabilities, and philosophy through writing that earns trust. Never try to sell. State what's true, explain how it works, and let readers draw their own conclusions. Speak as part of the same community you're writing for.
**Tone:** Fluent, calm, direct. Sentences flow naturally with complete syntax. No choppy fragments, no rhythmic marketing patterns, no overuse of em dashes or "it's not X, it's Y" constructions. Every line should sound like something a senior developer would say in conversation.
---
## Core Messages
**Code as craft**
Built from scratch, made with intention. Every feature is fit for purpose, and everything has its place.
**Made for multiplayer**
Code is collaborative. But today, our conversations happen outside the codebase. In Zed, your team and your AI agents work in the same space, in real time.
**Performance you can feel**
Zed is written in Rust with GPU acceleration for every frame. When you type or move the cursor, pixels respond instantly. That responsiveness keeps you in flow.
**Always shipping**
Zed is built for today and improved weekly. Each release moves the craft forward.
**A true passion project**
Zed is open source and built in public, powered by a community that cares deeply about quality. From the team behind Atom and Tree-sitter.
---
## Writing Principles
1. **Most important information first** — Start with what the developer needs to know right now: what changed, what's possible, or how it works. Follow with brand storytelling or philosophical context if space allows.
2. **Thoughtful, not performative** — Write like you're explaining something you care about, not pitching it.
3. **Explanatory precision** — Share technical detail when it matters. Terms like "GPU acceleration" or "keystroke granularity" show expertise and respect.
4. **Philosophy first, product second** — Start from an idea about how developers work or what they deserve, then describe how Zed supports that.
5. **Natural rhythm** — Vary sentence length. Let ideas breathe. Avoid marketing slogans and forced symmetry.
6. **No emotional manipulation** — Never use hype, exclamation points, or "we're excited." Don't tell the reader how to feel.
---
## Structure
When explaining features or ideas:
1. Lead with the most essential fact or change a developer needs to know.
2. Explain how Zed addresses it.
3. Add brand philosophy or context to deepen understanding.
4. Let the reader infer the benefit — never oversell.
---
## Avoid
- AI/marketing tropes (em dashes, mirrored constructions, "it's not X, it's Y")
- Buzzwords ("revolutionary," "cutting-edge," "game-changing")
- Corporate tone or startup voice
- Fragmented copy and slogans
- Exclamation points
- "We're excited to announce..."
---
## Litmus Test
Before finalizing copy, verify:
- Would a senior developer respect this?
- Does it sound like something from zed.dev?
- Does it read clearly and naturally aloud?
- Does it explain more than it sells?
If not, rewrite.
---
## Workflow
### Phase 1: Understand the Ask
Ask clarifying questions:
- What is this for? (homepage, release notes, docs, social, product page)
- Who's the audience? (prospective users, existing users, developers in general)
- What's the key message or feature to communicate?
- Any specific constraints? (character limits, format requirements)
### Phase 2: Gather Context
1. **Load reference files** (auto-loaded from skill folder):
- `rubric.md` — 8 scoring criteria for validation
- `taboo-phrases.md` — patterns to eliminate
- `voice-examples.md` — transformation patterns and fact preservation rules
2. **Search for relevant context** (if needed):
- Existing copy on zed.dev for tone reference
- Technical details about the feature from docs or code
- Related announcements or prior messaging
### Phase 3: Draft (Two-Pass System)
**Pass 1: First Draft with Fact Markers**
Write initial copy. Mark all factual claims with `[FACT]` tags:
- Technical specifications
- Proper nouns and product names
- Version numbers and dates
- Keyboard shortcuts and URLs
- Attribution and quotes
Example:
> Zed is [FACT: written in Rust] with [FACT: GPU-accelerated rendering at 120fps]. Built by [FACT: the team behind Atom and Tree-sitter].
**Pass 2: Diagnosis**
Score the draft against all 8 rubric criteria:
| Criterion | Score | Issues |
| -------------------- | ----- | ------ |
| Technical Grounding | /5 | |
| Natural Syntax | /5 | |
| Quiet Confidence | /5 | |
| Developer Respect | /5 | |
| Information Priority | /5 | |
| Specificity | /5 | |
| Voice Consistency | /5 | |
| Earned Claims | /5 | |
Scan for taboo phrases. Flag each with line reference.
**Pass 3: Reconstruction**
For any criterion scoring <4 or any taboo phrase found:
1. Identify the specific problem
2. Rewrite the flagged section
3. Verify `[FACT]` markers survived
4. Re-score the rewritten section
Repeat until all criteria score 4+.
### Phase 4: Validation
Present final copy with scorecard:
```
## Final Copy
[The copy here]
## Scorecard
| Criterion | Score |
|---------------------|-------|
| Technical Grounding | 5 |
| Natural Syntax | 4 |
| Quiet Confidence | 5 |
| Developer Respect | 5 |
| Information Priority| 4 |
| Specificity | 5 |
| Voice Consistency | 4 |
| Earned Claims | 5 |
| **TOTAL** | 37/40 |
✅ All criteria 4+
✅ Zero taboo phrases
✅ All facts preserved
## Facts Verified
- [FACT: Rust] ✓
- [FACT: GPU-accelerated] ✓
- [FACT: 120fps] ✓
```
**Output formats by context:**
| Context | Format |
| ------------- | ---------------------------------------------------- |
| Homepage | H1 + H2 + supporting paragraph |
| Product page | Section headers with explanatory copy |
| Release notes | What changed, how it works, why it matters |
| Docs intro | Clear explanation of what this is and when to use it |
| Social | Concise, no hashtags, link to learn more |
---
## Review Mode
When invoked with `--review`:
1. **Load reference files** (rubric, taboo phrases, voice examples)
2. **Score the provided copy** against all 8 rubric criteria
3. **Scan for taboo phrases** — list each with line number:
```
Line 2: "revolutionary" (hype word)
Line 5: "—" used 3 times (em dash overuse)
Line 7: "We're excited" (empty enthusiasm)
```
4. **Present diagnosis:**
```
## Review: [Copy Title]
| Criterion | Score | Issues |
|---------------------|-------|--------|
| Technical Grounding | 3 | Vague claims about "performance" |
| Natural Syntax | 2 | Triple em dash chain in P2 |
| ... | | |
### Taboo Phrases Found
- Line 2: "revolutionary"
- Line 5: "seamless experience"
### Verdict
❌ Does not pass (3 criteria below threshold)
```
5. **Offer rewrite** if any criterion scores <4:
- Apply transformation patterns from voice-examples.md
- Preserve all facts from original
- Present rewritten version with new scores
---
## Examples
### Good
> Zed is written in Rust with GPU acceleration for every frame. When you type or move the cursor, pixels respond instantly. That responsiveness keeps you in flow.
### Bad
> We're excited to announce our revolutionary new editor that will change the way you code forever! Say goodbye to slow, clunky IDEs — Zed is here to transform your workflow.
### Fixed
> Zed is a new kind of editor, built from scratch for speed. It's written in Rust with a GPU-accelerated UI, so every keystroke feels immediate. We designed it for developers who notice when their tools get in the way.

178
docs/.conventions/brand-voice/rubric.md Normal file
View File

@@ -0,0 +1,178 @@
# Brand Voice Rubric
Score each criterion 1-5. Copy must score **4+ on ALL criteria** to pass.
---
## 1. Technical Grounding (1-5)
Does the copy make specific, verifiable technical claims?
| Score | Description |
| ----- | ----------------------------------------------------------------------------------------- |
| 5 | Precise technical details that can be verified (specs, architecture, measurable outcomes) |
| 4 | Concrete technical claims with clear meaning |
| 3 | Mix of specific and vague technical references |
| 2 | Mostly abstract with occasional technical terms |
| 1 | No technical substance; pure marketing language |
**Examples:**
- ✅ "Written in Rust with GPU-accelerated rendering at 120fps"
- ❌ "Blazingly fast performance that will transform your workflow"
---
## 2. Natural Syntax (1-5)
Does the writing flow like natural speech from a thoughtful developer?
| Score | Description |
| ----- | --------------------------------------------------------------- |
| 5 | Varied sentence structure, natural rhythm, reads aloud smoothly |
| 4 | Mostly natural with minor rhythm issues |
| 3 | Some AI patterns visible but not dominant |
| 2 | Obvious structural patterns (parallel triplets, em dash chains) |
| 1 | Robotic cadence, formulaic construction throughout |
**Red flags:** Em dash overuse, "It's not X, it's Y" constructions, triple parallel lists, sentences all same length.
---
## 3. Quiet Confidence (1-5)
Does the copy state facts without hype or emotional manipulation?
| Score | Description |
| ----- | -------------------------------------------------------- |
| 5 | Facts speak for themselves; reader draws own conclusions |
| 4 | Confident statements with minimal flourish |
| 3 | Some restraint but occasional hype creeps in |
| 2 | Frequent superlatives or emotional appeals |
| 1 | Aggressive marketing tone, telling reader how to feel |
**Examples:**
- ✅ "Zed renders every frame on the GPU. You'll notice the difference when you scroll."
- ❌ "Experience the revolutionary speed that will absolutely transform how you code!"
---
## 4. Developer Respect (1-5)
Does the copy treat the reader as a peer, not a prospect?
| Score | Description |
| ----- | ------------------------------------------------------- |
| 5 | Peer-to-peer conversation; assumes technical competence |
| 4 | Respectful with appropriate technical depth |
| 3 | Slightly patronizing or oversimplified |
| 2 | Condescending explanations or forced enthusiasm |
| 1 | Treats reader as uninformed consumer to be persuaded |
**Examples:**
- ✅ "Tree-sitter provides incremental parsing, so syntax highlighting updates as you type."
- ❌ "Don't worry about the technical details — just know it's fast!"
---
## 5. Information Priority (1-5)
Is the most important information first?
| Score | Description |
| ----- | --------------------------------------------------- |
| 5 | Key fact or change leads; context follows naturally |
| 4 | Important info near top with minor preamble |
| 3 | Buried lede but recoverable |
| 2 | Significant buildup before substance |
| 1 | Key information buried or missing entirely |
**Examples:**
- ✅ "Inline completions now stream token-by-token. Previously, you waited for the full response."
- ❌ "We've been thinking a lot about the developer experience, and after months of work, we're thrilled to share that..."
---
## 6. Specificity (1-5)
Are claims concrete and measurable?
| Score | Description |
| ----- | -------------------------------------- |
| 5 | Every claim is specific and verifiable |
| 4 | Mostly specific with rare abstractions |
| 3 | Mix of concrete and vague claims |
| 2 | Mostly abstract benefits |
| 1 | All claims are vague or unverifiable |
**Examples:**
- ✅ "Startup time under 100ms on M1 Macs"
- ❌ "Lightning-fast startup that respects your time"
---
## 7. Voice Consistency (1-5)
Does the tone remain unified throughout?
| Score | Description |
| ----- | ------------------------------------------ |
| 5 | Single coherent voice from start to finish |
| 4 | Minor tonal shifts that don't distract |
| 3 | Noticeable drift between sections |
| 2 | Multiple competing voices |
| 1 | Jarring tonal inconsistency |
**Check for:** Shifts between casual/formal, technical/marketing, confident/hedging.
---
## 8. Earned Claims (1-5)
Are assertions supported or supportable?
| Score | Description |
| ----- | ------------------------------------------- |
| 5 | Every claim can be demonstrated or verified |
| 4 | Claims are reasonable and mostly verifiable |
| 3 | Some unsupported assertions |
| 2 | Multiple unverifiable superlatives |
| 1 | Bold claims with no backing |
**Examples:**
- ✅ "Built by the team behind Atom and Tree-sitter"
- ❌ "The most advanced editor ever created"
---
## Quick Scoring Template
```
| Criterion | Score | Notes |
|---------------------|-------|-------|
| Technical Grounding | /5 | |
| Natural Syntax | /5 | |
| Quiet Confidence | /5 | |
| Developer Respect | /5 | |
| Information Priority| /5 | |
| Specificity | /5 | |
| Voice Consistency | /5 | |
| Earned Claims | /5 | |
| **TOTAL** | /40 | |
Pass threshold: 32/40 (all criteria 4+)
```
---
## Decision Rules
- **All 4+:** Copy passes. Minor polish optional.
- **Any 3:** Rewrite flagged sections, re-score.
- **Any 2 or below:** Full reconstruction required.
- **Multiple failures:** Start fresh with new approach.

195
docs/.conventions/brand-voice/taboo-phrases.md Normal file
View File

@@ -0,0 +1,195 @@
# Taboo Phrases
These patterns signal AI-generated or marketing-heavy copy. Eliminate all instances.
---
## Hype Words
Never use these unless quoting someone else:
| Word/Phrase | Why It Fails |
| ---------------- | ---------------------------------- |
| revolutionary | Unearned superlative |
| game-changing | Unearned superlative |
| cutting-edge | Vague tech buzzword |
| next-generation | Meaningless without context |
| blazingly fast | Cliché, unquantified |
| lightning-fast | Cliché, unquantified |
| powerful | Vague; what does it do? |
| robust | Vague; how is it robust? |
| seamless | Almost never true |
| frictionless | Almost never true |
| effortless | Dismisses real complexity |
| leverage | Corporate jargon |
| unlock | Marketing manipulation |
| supercharge | Marketing manipulation |
| turbocharge | Marketing manipulation |
| best-in-class | Unverifiable claim |
| world-class | Unverifiable claim |
| state-of-the-art | Vague tech buzzword |
| groundbreaking | Unearned superlative |
| innovative | Show, don't tell |
| intuitive | Often means "we didn't explain it" |
| elegant | Self-congratulatory |
---
## AI Structural Patterns
These constructions reveal AI authorship:
### Em Dash Chains
```
❌ "Zed is fast — really fast — and it shows in every interaction."
✅ "Zed is fast. You'll feel it in every interaction."
```
### "It's not X, it's Y"
```
❌ "It's not just an editor — it's a complete development environment."
✅ "Zed combines editing, collaboration, and AI assistance in one workspace."
```
### Triple Parallel Lists
```
❌ "Fast. Focused. Collaborative."
❌ "Write code. Ship faster. Stay in flow."
✅ "Zed is built for speed and collaboration."
```
### Colon-Introduced Lists in Prose
```
❌ "Three things make Zed different: speed, collaboration, and AI."
✅ "Zed prioritizes speed, real-time collaboration, and AI integration."
```
### Rhetorical Questions as Openers
```
❌ "What if your editor could keep up with your thinking?"
✅ "Zed renders every keystroke instantly."
```
---
## Empty Enthusiasm
Remove all emotional manipulation:
| Pattern | Problem |
| --------------------------------- | -------------------------------- |
| "We're excited to announce..." | Nobody cares about your emotions |
| "We're thrilled to share..." | Same |
| "We can't wait for you to try..." | Presumptuous |
| "You'll love..." | Telling reader how to feel |
| "Get ready to..." | Marketing hype |
| "Say goodbye to..." | Cliché setup |
| "Say hello to..." | Cliché followup |
| "Finally, an editor that..." | Implies all others failed |
| "The wait is over" | Presumes anticipation |
| "Introducing..." (as standalone) | Weak opener |
---
## Vague Benefits
Replace with specific outcomes:
| Vague | Ask Instead |
| ----------------------- | ------------------------------ |
| "enhanced productivity" | How much faster? At what task? |
| "improved workflow" | What specific improvement? |
| "better experience" | Better how? Measurable? |
| "streamlined process" | What steps were removed? |
| "optimized performance" | What metric improved? |
| "increased efficiency" | What takes less time/effort? |
| "modern development" | What specific capability? |
| "next-level coding" | Meaningless |
| "superior quality" | By what measure? |
---
## Forbidden Punctuation
| Pattern | Rule |
| ----------- | ---------------------------------- |
| `!` | Never. Zero exclamation points. |
| `...` | No dramatic ellipses |
| ALL CAPS | No shouting for emphasis |
| `?` as hook | No rhetorical questions as openers |
| `—` overuse | Max one em dash per paragraph |
---
## Corporate Euphemisms
| Phrase | Problem |
| ------------------- | ----------------------------- |
| move the needle | Jargon |
| synergy | Meme-tier corporate |
| ecosystem | Often meaningless |
| paradigm shift | Dated buzzword |
| holistic approach | Vague |
| scalable solution | What scales? How? |
| actionable insights | Corporate speak |
| value proposition | Never in customer-facing copy |
| leverage (verb) | Use "use" instead |
| utilize | Use "use" instead |
| facilitate | Use clearer verb |
| empower | Patronizing |
| enable | Often vague; be specific |
---
## Filler Phrases
Delete without replacement:
- "In today's fast-paced world..."
- "As developers, we know..."
- "Let's face it..."
- "The truth is..."
- "At the end of the day..."
- "When it comes to..."
- "In order to..."
- "It goes without saying..."
- "Needless to say..."
- "As you may know..."
---
## Detection Checklist
Before finalizing, scan for:
1. **Superlatives:** best, most, fastest, only, first, ultimate
2. **Absolutes:** always, never, every, all, completely, totally
3. **Hedging:** might, could, potentially, possibly, may help
4. **Intensifiers:** very, really, extremely, incredibly, absolutely
5. **Vague quantifiers:** many, numerous, significant, substantial
**Rule:** If you can't prove it or measure it, rewrite it.
---
## Quick Reference
**Instant red flags (auto-fail if present):**
- Any exclamation point
- "We're excited/thrilled"
- "Revolutionary" or "game-changing"
- Em dash used 2+ times in one paragraph
- "It's not X, it's Y" construction
**Yellow flags (review carefully):**
- Any word from Hype Words list
- Sentences starting with "And" or "But"
- Questions in headlines
- Lists of exactly three items

267
docs/.conventions/brand-voice/voice-examples.md Normal file
View File

@@ -0,0 +1,267 @@
# Voice Transformation Examples
Ten before/after transformations demonstrating Zed's brand voice. Use these as calibration for diagnosis and reconstruction.
---
## 1. Hype to Specifics
**Before (Score: 2/5 Technical Grounding)**
> Zed delivers blazingly fast performance that will revolutionize your coding experience. Our cutting-edge technology ensures you never wait again.
**After (Score: 5/5)**
> Zed is written in Rust with GPU-accelerated rendering. Keystrokes register in under 8ms. Scrolling stays at 120fps even in large files.
**Transformation notes:**
- "blazingly fast" → specific latency numbers
- "revolutionize" → removed entirely
- "cutting-edge technology" → actual tech stack
- "never wait again" → measurable claim
---
## 2. Marketing to Technical
**Before (Score: 2/5 Developer Respect)**
> Don't worry about the complicated stuff — Zed handles it all for you! Just focus on what you do best: writing amazing code.
**After (Score: 5/5)**
> Zed runs language servers in separate processes with automatic crash recovery. If a language server fails, you keep editing while it restarts.
**Transformation notes:**
- Removed patronizing tone ("don't worry")
- Removed enthusiasm ("amazing")
- Added technical mechanism
- Treats reader as capable of understanding
---
## 3. Abstract to Concrete
**Before (Score: 2/5 Specificity)**
> Zed provides a seamless collaborative experience that brings your team together in powerful new ways.
**After (Score: 5/5)**
> Share your workspace with `cmd+shift+c`. Collaborators see your cursor, selections, and edits in real time. Voice chat is built in — no separate call needed.
**Transformation notes:**
- "seamless" → actual UX flow
- "powerful new ways" → specific features
- Added keyboard shortcut (concrete entry point)
- Described what collaboration actually looks like
---
## 4. Em Dash Chains to Natural Flow
**Before (Score: 2/5 Natural Syntax)**
> Zed is fast — really fast — and built for the way developers actually work — not how tools think they should work.
**After (Score: 5/5)**
> Zed is built for speed. We optimized for the workflows developers actually use: jumping between files, searching across projects, editing multiple cursors at once.
**Transformation notes:**
- Removed all em dashes
- Split into two clear sentences
- Abstract claim → specific examples
- "really fast" → removed (show, don't tell)
---
## 5. Enthusiasm to Confidence
**Before (Score: 1/5 Quiet Confidence)**
> We're thrilled to announce Zed 1.0! After years of hard work, we can't wait for you to experience what we've built. You're going to love it!
**After (Score: 5/5)**
> Zed 1.0 is available today. This release includes GPU text rendering, multi-buffer editing, and native collaboration. Download it at zed.dev.
**Transformation notes:**
- Removed all emotional language
- "thrilled" → deleted
- "can't wait" → deleted
- "You're going to love it" → deleted
- Added substance instead of feelings
---
## 6. "It's Not X, It's Y" Fix
**Before (Score: 2/5 Natural Syntax)**
> Zed isn't just an editor — it's a complete development environment. It's not about features — it's about flow. And it's not slow — it's instant.
**After (Score: 5/5)**
> Zed combines editing, debugging, collaboration, and AI assistance in one application. Everything runs in the same process, so switching between tasks has no context-switch overhead.
**Transformation notes:**
- Eliminated all "it's not X, it's Y" patterns
- Replaced negation with positive statements
- Added technical reasoning
- One clear sentence instead of three choppy ones
---
## 7. Vague Benefits to Specific Outcomes
**Before (Score: 2/5 Specificity)**
> Zed's AI integration enhances your productivity and streamlines your workflow, helping you code smarter and ship faster.
**After (Score: 5/5)**
> Zed runs AI completions inline as you type. Suggestions appear in 200ms. Accept with Tab, reject by continuing to type. The model runs locally or connects to your preferred API.
**Transformation notes:**
- "enhances productivity" → specific UX
- "streamlines workflow" → actual interaction model
- "code smarter" → deleted (meaningless)
- Added technical options (local vs API)
---
## 8. Social Media Cleanup
**Before (Score: 1/5 across multiple criteria)**
> 🚀 Big news! Zed just dropped MASSIVE updates! Multi-file editing, insane AI features, and SO much more. This is a game-changer, folks! Try it now! 🔥
**After (Score: 4/5)**
> Zed 0.150: Multi-buffer editing is here. Edit across files in a single view. AI completions now stream inline. Full changelog at zed.dev/releases.
**Transformation notes:**
- Removed all emoji
- Removed exclamation points
- "MASSIVE" → specific features
- "game-changer" → deleted
- "SO much more" → link to changelog
- Added version number for precision
---
## 9. Feature Announcement
**Before (Score: 2/5 Information Priority)**
> We've been listening to your feedback, and after months of development, our incredible team has built something truly special. Today, we're excited to finally share our new terminal integration!
**After (Score: 5/5)**
> Zed now includes a built-in terminal. Open it with `ctrl+\``. Terminals run in splits alongside your editor panes and share the same working directory as your project.
**Transformation notes:**
- Lead with the feature, not the backstory
- Removed emotional buildup
- Added keyboard shortcut
- Described actual behavior
---
## 10. Philosophy Statement
**Before (Score: 3/5 Quiet Confidence)**
> At Zed, we believe that developers deserve better tools. We're passionate about creating the best possible coding experience because we know how frustrating slow, bloated editors can be.
**After (Score: 5/5)**
> Developer tools should be fast, understandable, and collaborative. We built Zed to meet that standard. It's open source so you can verify our work and extend it.
**Transformation notes:**
- "We believe" → direct statement
- "passionate about" → deleted
- "best possible" → specific standard
- "frustrating, slow, bloated" → removed comparison
- Added concrete proof point (open source)
---
## Fact Preservation Rules
When transforming copy, certain elements must survive unchanged:
### Mark During Diagnosis
Tag factual claims with `[FACT]` during diagnosis phase:
```
Zed is written in [FACT: Rust] with [FACT: GPU-accelerated rendering].
It was built by [FACT: the team behind Atom and Tree-sitter].
```
### Never Change
| Category | Examples |
| ------------------ | ------------------------------------------ |
| Technical specs | "120fps", "8ms latency", "Rust" |
| Proper nouns | "Tree-sitter", "Anthropic", "Claude" |
| Version numbers | "Zed 1.0", "v0.150" |
| Keyboard shortcuts | "cmd+shift+c", "ctrl+\`" |
| URLs | "zed.dev/releases" |
| Attribution | "built by the team behind Atom" |
| Dates | "available today", "released January 2024" |
| Quotes | Any attributed quotation |
### Verification Step
After reconstruction, diff against original `[FACT]` markers:
1. List all facts from original
2. Confirm each appears in final copy
3. If a fact was removed, justify why (e.g., not relevant to new scope)
4. If a fact was changed, flag as error
### Example Verification
**Original with markers:**
> Zed is [FACT: written in Rust] with [FACT: GPU-accelerated rendering at 120fps]. Built by [FACT: the team behind Atom and Tree-sitter].
**Reconstruction:**
> Zed renders every frame on the GPU at 120fps. The Rust codebase prioritizes memory safety without garbage collection pauses. The same engineers who built Atom and Tree-sitter lead development.
**Verification:**
- ✅ "Rust" preserved
- ✅ "GPU-accelerated" preserved
- ✅ "120fps" preserved
- ✅ "team behind Atom and Tree-sitter" preserved
- **Pass**
---
## Transformation Patterns Summary
| Problem | Solution |
| -------------------- | ---------------------------- |
| Hype words | Replace with measurements |
| Em dash chains | Split into sentences |
| "It's not X, it's Y" | State positively what it is |
| Enthusiasm | Delete; add substance |
| Vague benefits | Name specific features |
| Buried lede | Lead with the news |
| Rhetorical questions | Make declarative statements |
| Abstract claims | Add mechanism or measurement |