brand-writer
- Repo stars 84,404
- Author updated Live
- Author repo zed
- Domain
- Design
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @zed-industries · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: brand-writer
description: Write clear, developer-first copy for Zed — leading with facts, grounded in craft. Write in Zed'…
category: design
runtime: no special runtime
---
# brand-writer output preview
## PART A: Task fit
- Use case: Write clear, developer-first copy for Zed — leading with facts, grounded in craft. 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. runs en….
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Invocation / Core Voice / Core Messages” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Write clear, developer-first copy for Zed — leading with facts, grounded in craft. 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. runs en…”.
- **02** When the source has headings, the agent prioritizes “Invocation / Core Voice / Core Messages” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/brand-writer`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Invocation / Core Voice / Core Messages”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: brand-writer
description: Write clear, developer-first copy for Zed — leading with facts, grounded in craft. Write in Zed'…
category: design
source: zed-industries/zed
---
# brand-writer
## When to use
- Write clear, developer-first copy for Zed — leading with facts, grounded in craft. Write in Zed's brand voice: thought…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Invocation / Core Voice / Core Messages” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "brand-writer" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Invocation / Core Voice / Core Messages
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} 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
/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
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.
Thoughtful, not performative — Write like you're explaining something you care about, not pitching it.
Explanatory precision — Share technical detail when it matters. Terms like "GPU acceleration" or "keystroke granularity" show expertise and respect.
Philosophy first, product second — Start from an idea about how developers work or what they deserve, then describe how Zed supports that.
Natural rhythm — Vary sentence length. Let ideas breathe. Avoid marketing slogans and forced symmetry.
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:
- Lead with the most essential fact or change a developer needs to know.
- Explain how Zed addresses it.
- Add brand philosophy or context to deepen understanding.
- 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
Load reference files (auto-loaded from skill folder):
rubric.md— 8 scoring criteria for validationtaboo-phrases.md— patterns to eliminatevoice-examples.md— transformation patterns and fact preservation rules
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:
- Identify the specific problem
- Rewrite the flagged section
- Verify
[FACT]markers survived - 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:
Load reference files (rubric, taboo phrases, voice examples)
Score the provided copy against all 8 rubric criteria
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)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)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.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review