Author

Not blog posts. Playbooks. The kind of document that becomes organizational IP—something people reference for years, not days.

5 levels 12-20 weeks artifact: Multi-volume playbook (20,000+ words)

Demonstrated, not asserted

  • Blueprint install BRD/PRD/ADR document generation at reference-work scale, agent-drafted, publicly inspectable. npx @nino-chavez-labs/blueprint-cli init verified 2026-07-15
  • Signal Dispatch voice guide read The published voice guide is itself organizational-IP-grade reference writing, and the spec that keeps long-form voice consistent. verified 2026-07-15
  • forge-brand clone The brand-kit JSON that drives consistent tokens/docs across outputs — the config-file mechanics this track teaches, shipped. verified 2026-07-15

Who this is for

This path is for you if

  • ·You have deep expertise you want to codify into a reference
  • ·You're building playbooks, guides, or manuals for organizations
  • ·You want repeatable frameworks others can use without you
  • ·You're comfortable with long-form writing (20,000+ words)

Probably not if

  • ·You want to write blog posts, not books (that's the Voice track)
  • ·You need one-off strategy briefs (that's the Strategist track)
  • ·You're exploring AI for self-understanding (that's the Explorer track)
  • ·You don't yet have domain expertise to document

Playbook vs Blog Post

A playbook isn't just a long blog post — it's structured differently. A blog post says "here's what I think about X right now." A playbook says "here's how to do X, with enough detail that you can do it without me." Playbooks are reference material: someone should be able to open Chapter 7 six months from now and follow the process without context.

The levels

0 Design Playbook Architecture 2-3 days

Plan a multi-volume structure before writing a single chapter.

4-Volume Structure

  • Volume 1: Strategic Framework — Why this matters, core concepts, maturity model
  • Volume 2: Methodology — How to do each major activity, step-by-step
  • Volume 3: Execution — Team structure, engagement models, governance
  • Volume 4: Reference — Templates, checklists, decision trees, glossary

Design principles

  • ·Each volume should be readable standalone
  • ·Chapters within a volume build on each other
  • ·Reference material lives in appendices, not inline
  • ·Plan cross-references before writing

Checkpoints

  • ·4-volume structure with clear purpose for each
  • ·12+ chapter outlines with section headers
  • ·Dependency map (which chapters reference which)
  • ·Estimated word count per chapter

Done when — You have a complete outline with 4 volumes and 12+ chapters

1 Master a Single Chapter 2-3 weeks

Write one complete chapter that could stand alone as a reference.

Chapter structure

  • Introduction — What this chapter covers, who should read it
  • Core Concepts — Key ideas with definitions
  • Process/Steps — How to do the thing, with detail
  • Examples — Real or realistic scenarios
  • Common Pitfalls — What goes wrong and how to avoid it
  • Summary — Key takeaways, next steps

Requirements

  • ·Pick the chapter you know best
  • ·Write it as if you won't be there to explain it
  • ·Include enough detail that someone could act on it

Checkpoints

  • ·5,000+ word chapter with all 6 sections
  • ·Consistent heading hierarchy (H2 → H3 → H4)
  • ·At least 2 concrete examples
  • ·Someone unfamiliar with the topic could follow it

Done when — You have a 5,000+ word chapter with consistent structure

2 Maintain Voice Across Chapters 3-4 weeks

Write 3 chapters that read like one author wrote them.

Consistency dimensions

  • Terminology — Always "playbook" not "handbook/guide/manual"
  • Tone — Confident but not arrogant, instructional not academic
  • Structure — Same sections in same order across chapters
  • Depth — Similar detail level (don't over-explain one thing)

Tools to help

  • ·Style guide document (terms to use/avoid) — the published Signal Dispatch voice guide is one worked example of documenting voice precisely enough to keep it consistent across a body of work
  • ·Chapter template with required sections
  • ·Cross-chapter review (read all 3 sequentially)

Checkpoints

  • ·3 chapters totaling 15,000+ words
  • ·Style guide document with 20+ terms
  • ·Consistent structure across all chapters
  • ·Someone could read chapters 1, 5, 9 and notice same author

Done when — You have 3 chapters with consistent terminology and tone

3 Build Reference Appendices 3-4 weeks

Create the supplementary materials that make a playbook actionable.

Appendix types

  • Templates — Fill-in-the-blank documents for common outputs (e.g. assessment template, status report template)
  • Worksheets — Structured exercises to work through (e.g. capability gap analysis, priority matrix)
  • Decision Trees — If-then logic for common decisions (e.g. which approach to use based on context)
  • Checklists — Step-by-step validation lists (e.g. launch readiness, quality gates)
  • Glossary — Definitive terms with definitions (e.g. domain-specific vocabulary)

Checkpoints

  • ·At least 3 templates (different types)
  • ·At least 2 worksheets with worked examples
  • ·At least 1 decision tree
  • ·Glossary with 30+ terms
  • ·Appendices reference main chapters and vice versa

Done when — You have appendices with templates, worksheets, and decision trees

4 Create Client-Agnostic Frameworks 4+ weeks

Make your playbook reusable across contexts with variable substitution.

Abstraction patterns

  • Variable Substitution — {{client.name}}, {{client.industry}}, {{engagement.scope}}
  • Conditional Sections — Include/exclude based on context (enterprise vs SMB)
  • Scalable Examples — Examples that work at different scales/industries
  • Configuration Files — style-guide.json, quality-rubric.json, abstractions.json. This is the config-driven pattern forge-brand ships: one brand-kit JSON drives consistent tokens and docs across every output

Validation

  • ·Test with 2 different "clients" (real or hypothetical)
  • ·Have someone else use the framework without your help
  • ·Check that substitutions produce coherent output

The test

  • ·Can someone else use your framework to produce quality output without your help?

Checkpoints

  • ·Framework tested with 2+ different contexts
  • ·Configuration files for customization
  • ·Quality rubric for scoring outputs
  • ·Someone else can use the framework independently

Done when — You have a framework that works for multiple clients/contexts

Start at Level 0 Read the voice guide

Tool links and level references live in a dated data file checked by the link sensor on every build — this page can't silently point at a moved doc or a dead demo.