2lines-brand-voice

star 0

2Lines Software brand voice and style guide. Extends brand-voice-common with company-specific guidelines for all 2Lines content including proposals, documentation, marketing materials, and client communications.

johncarpenter By johncarpenter schedule Updated 2/12/2026

name: 2lines-brand-voice description: 2Lines Software brand voice and style guide. Extends brand-voice-common with company-specific guidelines for all 2Lines content including proposals, documentation, marketing materials, and client communications. extends: brand-voice-common

2Lines Software Brand Voice

Brand voice and style guidelines for 2Lines Software. Use this skill when creating any content representing 2Lines — proposals, documentation, blog posts, client communications, and marketing materials.

Note: This skill extends brand-voice-common. See that skill for general frameworks on tone adaptation, style enforcement, and terminology management.


Company Name Usage

Use This Not This Notes
2Lines Software 2 Lines Software No space between "2" and "Lines"
2Lines Two Lines, 2-Lines Shorthand form, no space or hyphen
the 2Lines team the 2Lines Software team Use shorthand when "team" follows

Capitalization: Always capitalize the "L" in "2Lines" — never "2lines" or "2LINES".

First mention: Use "2Lines Software" on first mention in formal documents, then "2Lines" thereafter.


Brand Personality

If 2Lines Software were a person, they would be:

A seasoned technical partner who genuinely cares about your success. They've seen what works and what doesn't across many projects. They explain complex things clearly without being condescending, ask the right questions before diving in, and deliver what they promise. They're confident but never arrogant — the kind of expert who makes you feel smarter after every conversation.


Voice Attributes

1. Expert but Approachable

  • We are: Knowledgeable, experienced, and willing to share what we know in accessible language
  • We are not: Academic, jargon-heavy, or condescending
  • This sounds like: "We've built systems like this before — here's what typically works well and where teams run into trouble."
  • This does NOT sound like: "As per industry-standard best practices, one must implement a microservices architecture utilizing containerization paradigms."

2. Direct and Clear

  • We are: Honest, concise, and straightforward — we get to the point
  • We are not: Blunt to the point of rudeness, or vague to avoid difficult conversations
  • This sounds like: "This timeline is tight. Here's what's realistic and what would need to change to hit the original date."
  • This does NOT sound like: "While there are various factors that could potentially impact the delivery schedule, we remain cautiously optimistic about meeting stakeholder expectations."

3. Collaborative

  • We are: Partners who work alongside your team, not vendors who disappear until delivery
  • We are not: Order-takers or know-it-alls who dismiss client input
  • This sounds like: "Let's work through this together. What constraints are you working with on your end?"
  • This does NOT sound like: "Leave it with us — we'll tell you when it's done."

4. Reliable

  • We are: Consistent, accountable, and follow through on commitments
  • We are not: Overpromising or making guarantees we can't keep
  • This sounds like: "We'll have the first iteration ready by Thursday. If anything changes, you'll hear from us before that."
  • This does NOT sound like: "Don't worry, it'll definitely be done on time!" (without qualifying assumptions)

5. Pragmatic

  • We are: Focused on outcomes and practical solutions, not technology for its own sake
  • We are not: Cynical, dismissive of innovation, or stuck in old ways
  • This sounds like: "The simpler approach will get you 80% of the value in half the time. We can revisit the advanced features once the foundation is solid."
  • This does NOT sound like: "Why would you want to do that? Just use [our preferred tool]."

Audience Awareness

Primary Audiences

Audience What They Care About How to Address Them
CTOs / Technical Leaders Architecture decisions, team capability, risk mitigation Peer-to-peer, technical depth available but not assumed
Project Managers Timelines, communication, deliverables, budget Clear milestones, proactive updates, no surprises
Business Stakeholders ROI, business outcomes, competitive advantage Outcomes over outputs, business language

Secondary Audiences

Audience What They Care About How to Address Them
Development Teams Code quality, knowledge transfer, working alongside Respectful collaboration, not "coming in to fix things"
Procurement / Legal Risk, compliance, terms Professional, thorough, patient with process

Core Messaging Pillars

1. Partnership Over Vendor Relationship

We embed with your team, not just deliver and disappear. Your success is our success.

2. Pragmatic Technical Excellence

We build things that work, not things that are impressive for their own sake. Right-sized solutions.

3. Clarity and Transparency

You'll always know where things stand. No surprises, no jargon walls, no hidden agendas.

4. Proven Experience

We've done this before. We know what works and what doesn't, and we share that knowledge freely.


Tone Spectrum

The 2Lines voice adapts while staying recognizable:

Context Dial Up Dial Down
Proposal / Sales Confidence, expertise Informality
Technical Documentation Clarity, precision Warmth
Client Slack / Email Collaboration, approachability Formality
Incident / Problem Transparency, accountability Confidence (acknowledge uncertainty)
Blog / Thought Leadership Pragmatism, expertise Sales language
Internal Communications Directness, informality Polish

Style Rules (2Lines-Specific)

Grammar and Mechanics

Rule 2Lines Standard
Oxford comma Yes
Contractions Use them — we're conversational
Headings Sentence case
Numbers Spell out one through nine, numerals for 10+
Dates Month DD, YYYY (January 15, 2025)
Time 12-hour with AM/PM, include timezone when relevant
Percent Use % symbol
Lists No periods for fragments, periods for full sentences

Formatting Conventions

  • Headings: Use H2 for major sections, H3 for subsections. Don't skip levels.
  • Bold: Use for emphasis on key terms or actions
  • Italic: Use for introducing new terms or titles
  • Links: Always descriptive text, never "click here"
  • Code: Use backticks for inline code, fenced blocks for multi-line

Things to Avoid

  • Exclamation marks (use sparingly — max one per document section)
  • ALL CAPS for emphasis (use bold instead)
  • Buzzwords without substance ("leverage synergies", "move the needle")
  • Passive voice when active is clearer
  • Weasel words ("some", "many", "arguably")

Terminology

Preferred Terms

Use This Not This Notes
2Lines Software 2 Lines, Two Lines Company name
the team resources People, not resources
client customer We partner with clients
build develop, engineer Plain language preferred
timeline ETA, delivery window Clear and direct
trade-offs pros and cons More precise
scope requirements (when informal) Context-dependent

Technical Terms (Audience-Dependent)

Define or explain on first use when writing for non-technical audiences:

  • API, CI/CD, containerization, microservices, cloud-native
  • Any acronym not universally known

For technical audiences, use terms directly without over-explaining.

Phrases We Use

  • "Let's work through this together"
  • "Here's what we'd recommend and why"
  • "Based on what we've seen in similar projects"
  • "The trade-off here is..."
  • "We'll keep you posted"

Phrases We Avoid

  • "Per our last conversation" (just reference the topic)
  • "Please advise" (ask the actual question)
  • "ASAP" (give actual timelines)
  • "It depends" (without then explaining what it depends on)
  • "Best practices" (without specifying which ones and why)

Product and Service Naming

Product/Service Full Name Shorthand Notes
[placeholder] [Full Product Name] [Short form] [Usage notes]

Document-Specific Guidelines

Proposals

  • Lead with the client's problem, not our capabilities
  • Include clear scope, timeline, and investment sections
  • Use "investment" not "cost" or "price"
  • Always include assumptions and what's out of scope

Technical Documentation

  • Start with the "why" before the "how"
  • Include practical examples
  • Keep paragraphs short
  • Use diagrams when they clarify

Client Emails

  • Get to the point in the first sentence
  • Use bullet points for multiple items
  • End with clear next steps or asks
  • Keep it scannable

Inclusive Language

Following the guidelines in brand-voice-common:

  • Use gender-neutral language (they/them for unknown individuals)
  • Avoid ableist language
  • Use "straightforward" instead of "easy"
  • Avoid culturally-specific idioms

Review Checklist

When reviewing content for 2Lines brand voice:

  • Company name is correct (2Lines Software / 2Lines)
  • Tone matches the context (see Tone Spectrum)
  • Voice attributes are present (expert, direct, collaborative, reliable, pragmatic)
  • No jargon without purpose
  • Active voice where possible
  • Clear next steps or calls to action
  • Oxford comma used consistently
  • Contractions used naturally
Install via CLI
npx skills add https://github.com/johncarpenter/knowledge-base --skill 2lines-brand-voice
Repository Details
star Stars 0
call_split Forks 0
navigation Branch main
article Path SKILL.md
More from Creator
johncarpenter
johncarpenter Explore all skills →