--- description: VS14 voice and content principles for community-facing copy, admin docs, rules, MOTD, brand content, Discord onboarding, website text, and any player- or admin-readable artifact. Embodies the casual-hangout server identity and the AI-is-invisible-plumbing posture. Load whenever authoring, editing, drafting, or critiquing VS14 server content — rules, sanctions, training, incident docs, positioning, MOTD, about pages, launch announcements, brand copy, web pages, Discord rules and onboarding text. --- # VS14 voice Voice and content principles for VS14 community-facing copy, admin docs, rules, MOTD, brand content, and any Discord or website text. This skill is the cultural core of the server expressed as writing guidance — load it whenever you're authoring or revising anything players or admins read. ## Server identity (the one-paragraph anchor) Vacation Station 14 is a casual Space Station 14 server. We aim for relaxed rounds with light roleplay, focused less on violence and more on collaboration and creativity. The community we're building values supporting each other as much as winning the round. SFW server, 16+ players welcome, hub-listed via the Wizards' Den. That paragraph is the lens. Every piece of copy inherits from it — the tone is welcoming, the vibe is casual-but-thoughtful, the differentiator is the chosen-family-style mutual support without the saccharine. ## AI is invisible plumbing VS14 is **not** an AI-first server. AI tooling helps the maintainer run the server (drafting docs, dispatching agent work, reviewing code) the same way `git`, `nginx`, and an IDE do — it's infrastructure, not a flavor. Players see a thoughtful human-run server. Recruits see a singular maintainer making considered calls. In writing: - **Never name AI** in player-facing or admin-facing docs (no "AI assistant," no "Claude," no "agent," no "we use AI to..." framing). - **Don't credit AI as co-author** of MOTD, rules, brand assets, Discord onboarding copy, or anywhere a player or recruit could read it. - **Commit-trailer co-authorship is fine** — git history isn't the player surface. - **There is one maintainer. Refer to them as "the maintainer" in player-facing copy — singular role, no name.** Don't hide behind "the team" plural when the team is one. The maintainer's actual name belongs in git history, GitHub repo metadata, and contributor-facing docs (CONTRIBUTING.md, LEGAL.md), not in rules, about pages, MOTD, or Discord onboarding. ## The 12 anti-patterns Things that almost always kill VS14 voice. If you find yourself writing one, stop: ### 1. Premature multi-admin process Shifts, rank tables (Trial / Junior / Senior / Maintainer) for a team of one, roster files that don't exist, "the second admin reviews" gates when there is no second admin. Write for the team that exists today and forward-look honestly when it'll grow. ### 2. Rules without enforcement infrastructure Response-time targets when there's no ahelp-tracking. Chain-of- command when there's no chain. Recusal-on-honor-system when there's no transparency mechanism. If we can't enforce a rule, it's performance, not policy. ### 3. Governance ceremony `Status: DRAFT — not yet ratified.` `Draft v0.1.` *Maintained by the VS14 maintainer team.* Three-step ratification checklists. None of this fits a solo-operator project. Real version-control, real edits, no theater. ### 4. Phantom infrastructure `#admin-meta`, `#admin-onboarding`, `roster.md`, `private incident archive`, `the shared password-manager vault for any admin-only secrets` — channels and files we'd hypothetically have. Reference real artifacts; admit what doesn't exist yet. ### 5. Moralizing closers *"When in doubt: escalate."* *"This is the rule we care about most."* *"Recusal is not a confession of bias — it's routine hygiene."* Sentences that lecture rather than inform. The body of the rule is the lesson; don't tack on a sermon. ### 6. Quantified time commitments `First month`, `every 6 months`, `≥ 5 hours total playtime`, `first solo week`, `30-minute cool-down`. We're a casual server with no shifts and no minimums. Don't impose structure that doesn't apply. ### 7. Policing opinions "No taking sides in upstream community drama in public." We don't police what admins say in their own spaces or what positions they take. Public conduct standards are about being civil; everything else is the admin's business. ### 8. Listicle duplication across docs Every doc with a parallel "Related" section. Footer attribution on every file. Acceptance-criteria mirrored in `--description` and `--acceptance-criteria`. Lists that exist in two places will go stale in one. ### 9. Telling the reader how to use the doc "Admins should keep this open in a tab during shifts." "Read this in order." "Don't skim the first four." Trust adult readers to figure out their own workflow. ### 10. AI-shape texture Even without naming AI: 1100+ lines of policy framework for a 1-admin pre-launch server reads as AI-generated. So do parallel- structured bullets across N docs, em-dashes used for profundity ("... — full stop."), "Treat X like medical records" overstretched analogies, and exhaustive Phase 1 → Phase 6 programs. Compression, specificity, and uneven rhythm are the antidotes. ### 11. Corporate document tone *This document specifies the rules that need to be followed.* *These rules apply at all times, including between rounds.* *By connecting to this server, you agree to...* Replace with how the maintainer would actually phrase it. ### 12. Pre-codifying speculative process Writing offboarding-checklist.md when we have one admin. Writing appeals tone guidelines when there's no appeals queue. Some of this is fine (forward-looking), but acknowledge it explicitly: "Most of this doesn't apply yet (one admin), but lives here so we have a procedure when the team grows." ## Calibration heuristics How to make decisions when the anti-patterns don't directly apply: ### Server identity drives rule calibration Casual hangout server → light B1 (stay in character, but the bar is "make some effort," not "pristine RP"). Less violence than most stations → sharper B3 (no griefing — it kills creativity). Match the rule's force to its importance for *this* server. ### Hub-compliance is the floor; differentiation is above the floor Wizden hub rules section 1 (harassment, doxxing, age, ban- evasion) is mandatory — A-tier in our tier structure. Above that, every choice (NSFW posture, RP intensity, antag conduct, command expectations) is yours to make. Differentiate where it matters; standard where it doesn't. ### Trust the reader; trust the spirit Document what you can enforce, then say: "These rules try to capture our intent, but they can't anticipate every situation. Don't try to rules-lawyer the gaps." Underspecified is better than exhaustive when the audience is a small community. ### Maintainer as singular, unnamed trust-anchor Where workflows funnel through one person today and a future-team tomorrow, refer to "the maintainer" — singular role, no name. *"The maintainer keeps the canonical copy."* *"The maintainer publishes redacted versions."* This is honest about today and forward-looking about tomorrow. The maintainer's actual name stays in git history, GitHub repo metadata, and contributor- facing docs — not in player-facing copy. ## When to break voice The principles above apply to player-facing and admin-team- internal docs. Some surfaces need different registers: - **`/tos`, `/privacy`, `/dmca`** — formal legal language, jurisdictional references, structured boilerplate. Voice should be neutral, not conversational. - **Hub-mod correspondence** — neutral, factual, evidentiary. Reads like a small-claims filing, not a Discord post. - **Incident docs (formal writeups)** — neutral, third-person, verbatim quotes. Voice deliberately drained because emotion corrupts the record. In each case, the voice change is intentional and audience-driven, not register drift. Mark the boundary clearly when it happens. ## Worked examples The docs revised in the 2026-05-02 review pass are the canonical examples of this voice applied: - `docs/community/rules.md` — preamble + tier A/B/C/S + admin- discretion close. Every line carries the casual-hangout posture. - `docs/community/admin/expectations.md` — what an admin IS, with multi-admin ceremony cut to the bone. - `docs/community/admin/sanctions.md` — reference doc; less voice- driven, but matrix labels and ban-category framing are calibrated to the rule tiers. - `docs/community/admin/training.md` — three-section "tools / start / ongoing" with the no-shifts-no-minimums framing. - `docs/community/admin/{on,off}boarding-checklist.md` — checklist- shape with the maintainer named as trust-anchor. - `docs/community/admin/incident-template.md` — formal voice within the template body (neutrality for the record), conversational voice in the framing. When in doubt about a new piece, scan one of these for calibration. ## See also - `docs/community/rules.md` — server rules - `docs/community/admin/` — admin operations docs - `vs-kku` — second-pass critique bead on the 2026-05-02 docs - `vs-3e3` — open writing bead (positioning, MOTD, about, Discord onboarding, launch announcement) - `vs-7ns` — open brand identity bead (logo, palette, fonts, brand guide) - `/zig-voice` — Andrew's personal writing voice (social posts, blog, professional content). Don't conflate: VS14 voice is for the SERVER; Zig voice is for ANDREW. Different audience, different register.