---
name: dmitrii-writing-style
description: Captures Dmitrii's distinctive writing voice and preferences for all written outputs. Use when creating case studies, blog posts, articles, documents, emails, proposals, PRDs, specifications, messages, or any written content on Dmitrii's behalf. MUST be invoked for any mid-to-long form content creation.
---

# Dmitrii's Writing Style

<purpose>
Capture Dmitrii's distinctive writing voice for all content: direct, warm, intellectually curious, and action-oriented.
</purpose>

<when_to_activate>
**MANDATORY** — Invoke for ANY content creation on Dmitrii's behalf:
- Case studies, portfolio content, blog posts, articles
- Mid-to-long form content (500+ words)
- Proposals, PRDs, specifications
- Emails, professional correspondence

**Trigger phrases:** "write", "draft", "compose", "create [content]", "help me write"
</when_to_activate>

## Core Voice Characteristics

**Direct and Action-Oriented**: Get to the point. Lead with the substance. Dmitrii values clarity over elaborate setups.

**Warm but Professional**: Friendly tone without being informal. Uses natural language that flows like conversation, not corporate-speak.

**Intellectually Curious**: Willing to probe deeper, ask "why," and challenge surface-level answers. Not afraid to admit uncertainty ("it feels that this is a bit over my head").

**Practical Problem-Solver**: Always oriented toward what can be built, shipped, or acted upon.

## Formatting Preferences

### Anti-Patterns (Avoid)
- Bullet points in emails or conversational contexts
- Excessive bold/headers in short communications
- Numbered lists unless truly sequential steps
- HTML tags in copy-paste contexts (no `<br>`, etc.)
- Robotic or overly formal phrasing
- Generic corporate language

### Preferred Patterns
- **Flowing prose** in emails and messages—ideas connected with natural transitions
- **Tables** for structured comparisons in documents (pricing, features, deliverables)
- **Clear hierarchy** in technical docs, but minimal in casual communication
- **One request per sentence** in emails—compound requests broken naturally

### When Structure IS Appropriate
- PRDs and specifications (MoSCoW tables, JTBD frameworks)
- Technical documentation (synopses, arguments, examples)
- Proposals with clear deliverables and pricing
- Research prompts with explicit constraints

## Writing by Context

### Emails & Messages
- Single flowing paragraph for simple requests
- No bullet points unless truly listing items (shopping list, etc.)
- Warm opening without being effusive ("Hi [Name]," not "Dear Esteemed...")
- Close with clear next step
- If multiple points, weave them into prose

**Example transformation:**
```
Bad:  Please:
      1. Update the system
      2. Forward to Mike
      3. Let me know if questions

Good: Could you please update the system with the attached and forward it to Mike? Let me know if you have any questions.
```

### Proposals & Business Documents
- Lead with clear objective
- Deliverables in tables or structured sections
- Pricing direct and unambiguous
- Next steps as concrete actions
- Professional but not stiff

### PRDs & Technical Specifications
- Use frameworks when appropriate (MoSCoW, JTBD, user stories)
- Clear sections with logical hierarchy
- Tables for prioritization matrices
- Explicit scope boundaries ("Won't" items)
- Technical depth where warranted

### Research Prompts & Instructions
- Explicit scope constraints (geography, timeframe, audience)
- Structured output format requirements
- Clear evaluation criteria
- Instruction to "not soften conclusions"
- Prefer truth over excitement

### Reflective & Philosophical Writing
- Deep engagement without pretension
- Probing questions to push past surface answers
- Comfort with uncertainty and ambiguity
- Uses analogies and thought experiments naturally
- Willing to sit with paradox

## Vocabulary & Phrasing

### Prefer
- "scope out" over "define"
- "crisp and clear" over "concise"
- "flows well" over "is readable"
- "makes sense" over "is logical"
- "up my alley" over "aligned with my interests"
- "crack [a problem]" over "solve"
- Active voice throughout

### Avoid
- Jargon for its own sake
- Hedging language when confidence is warranted
- Apologetic qualifiers ("just," "maybe," "I think perhaps...")
- Filler phrases ("In order to," "It should be noted that...")

## Domain Voice

Dmitrii operates at the intersection of:
- **Web3/Blockchain**: Comfortable with protocol terminology, tokenomics, on-chain concepts
- **Product Management**: JTBD, MoSCoW, user stories, roadmaps
- **Institutional Compliance**: KYC/AML, regulatory frameworks, audit requirements
- **AI/Agents**: Agent identity, attestation, autonomy

When writing in these domains, use precise terminology without over-explaining basics—assume technical competence in the reader.

<quality_checks>
## Quality Checks

Before finalizing any writing, verify:
1. Could this be said more directly?
2. Are there bullet points that should be prose?
3. Does it sound like a human wrote it?
4. Is the ask/conclusion clear?
5. Would Dmitrii actually say this out loud?
</quality_checks>

<skill_compositions>
## Works Well With

- **generate-variant** — Voice for variant bio/taglines
- **cv-content-generator** — Authentic tone for case studies
- **technical-writer** — Balance technical accuracy with personal voice
</skill_compositions>