voice

# Outfitter Voice Outfitter writes like it means it. We're unapologetically opinionated — not because we think we're always right, but because wishy-washy tools make for wishy-washy software. If we've made a choice, we'll tell you why and stand behind it. ## Quick Reference | Principle | In Practice | |-----------|-------------| | **Opinionated** | State choices clearly. Explain why. Don't hedge. | | **Agent-first** | Structure for machines. Runnable examples. Typed errors. | | **Goal-serving** | Match voice to container. Quick starts are quick. | | **Clear > clever** | Personality that reinforces understanding, not obscures it. | | **Plain language** | Save generics for code. Use words people say. | | **Earned confidence** | Claims backed by examples, benchmarks, tests. | | **Ownership stance** | First-person "we". Possessive when it fits. | ## Agents at Every Step We build with agents at every step of the way, and we're explicit about it. Agents aren't an afterthought or a marketing angle — they're first-class consumers of everything we make. When we write, we're writing for Claude as much as we're writing for you. This shapes everything: - Documentation is structured for machine readability, not just human skimming - Rules aren't just stated — they're codified, tested, and enforced - Errors are typed and explicit, because agents need to handle them too - Examples are copy-paste runnable, because that's how agents learn ## Serve the Goal Voice is how we say things, not permission to say more. If someone needs a code example, give them the code example. If they need a quick answer, give them the quick answer. Don't make people scroll past your life story to get the recipe. The goal of the content determines its shape: - **Quick Start** — Get to code fast. Context comes after, if at all. - **Philosophy section** — Room to breathe. Explain the why. - **API reference** — Precision over personality. Just the facts. - **Blog post** — Full voice. Narrative, personality, earned enthusiasm. Match the container. A README Quick Start and a blog post have different jobs. ## Clear Beats Clever — But Personality Matters Default to clarity. When established conventions exist, follow them. But clever *can* be clear when it reinforces the mental model: - A breadcrumb tool called "crumbs" → `crumb drop` has personality without sacrificing meaning. `crumb new` is functional, but forgettable. - Ranger, Firewatch, Waymark — names that evoke what they do. - "Done. You're building type-safe infrastructure." — confident, memorable. Clever fails when it requires translation: - Cold/Warm/Hot for stability tiers → "Cold means... frozen means... stable?" Just say Stable. - Jargon that sounds smart but means nothing to newcomers. The test: *Does the cleverness help you understand, or make you pause to decode?* Reinforce the vibe. Don't invent vocabulary. ## Plain Language Over Jargon "Typed errors instead of throwing" lands better than `Result<T, E>` in prose. Save the generics for code blocks. When explaining concepts, use words people actually say. Technical precision matters in code; human clarity matters in explanation. This doesn't mean dumbing down. It means choosing the right level of abstraction for the medium. ## Vibes Matter, But So Does Verification We care about how things feel, but we don't trust feelings alone. If a rule matters, it's codified, tested, and enforced. Opinions without teeth are just suggestions. We don't say "prefer X" — we lint for it, test for it, fail builds over it. This applies to voice too. If we claim something is simple, there's a working example. If we claim something is fast, there's a benchmark. Earned confidence, not asserted confidence. ## The Ownership Stance Outfitter takes ownership. First-person "we" when speaking as the project. Possessive when it fits: "Outfitter's shared infrastructure" not "shared infrastructure for Outfitter." We're unapologetically opinionated about: - **Correctness over convenience** — Explicit errors, strict types, tests first - **Agents as consumers** — Not an afterthought, a design constraint - **Intentional craft** — Built deliberately, not accumulated accidentally We're not hedging. We're not "just a simple tool." We're building something with purpose. ## What This Isn't This skill is the philosophical foundation — the *why* and *how we think*. It's not: - Sentence-level style guidance (load the `internal:styleguide` skill) - Documentation structure templates (load the `internal:docs-write` skill) - Code style or formatting rules Load this skill to ground your writing in Outfitter's values. Load `internal:styleguide` for craft, `internal:docs-write` for structure. ## Review Checklist When reviewing content against Outfitter voice: - [ ] **Opinionated**: Does it state choices clearly, not hedge? - [ ] **Agent-aware**: Is it structured for machine consumption? - [ ] **Goal-serving**: Does the voice match the content type? - [ ] **Clear**: Would cleverness cause someone to pause and decode? - [ ] **Plain language**: Are concepts explained in human terms? - [ ] **Verified**: Are claims backed by evidence (examples, benchmarks)? - [ ] **Ownership**: Does it speak as Outfitter, not about Outfitter?