| 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:
