@design-ai/cli 4.55.0

package/skills/design-system-builder/PLAYBOOK.md

@@ -0,0 +1,218 @@
+# design-system-builder — playbook
+
+Bootstrap a complete design system from a brand brief. Output is a directory of design tokens, foundational guidelines, and a starter component set.
+
+## When to use
+
+- "We're starting a new product, build the design system."
+- "Migrate our hardcoded styles into a token system."
+- "I have these brand colors and fonts — turn it into a system."
+
+## Inputs (ask if missing)
+
+1. **Product type / category** — SaaS, e-commerce, fintech, etc. Use to seed palette and density.
+2. **Brand inputs**:
+   - Primary brand color (hex).
+   - Optional: secondary color, font preferences, mood words.
+3. **Target framework** — `tailwind v4`, `shadcn-ui`, `mui`, `antd`, `css variables`, `style dictionary`.
+4. **Content language(s)** — affects type system (Korean line-height, RTL).
+5. **Density default** — comfortable / compact.
+6. **Light + dark, or light only?** — default both.
+
+## Steps
+
+### 1. Seed from a curated row
+
+Open [`knowledge/colors/palettes-by-product-type.md`](../../knowledge/colors/palettes-by-product-type.md). Find the closest product-type row. Use it as a reference shape — not values to copy. The user's brand color overrides the primary.
+
+### 2. Build tokens — color
+
+Invoke the `color-palette` skill (or its playbook) with the brand color as seed. Get back:
+- Brand ramps (primary, accent, neutrals)
+- Semantic aliases (light + dark)
+- Contrast matrix
+
+### 3. Build tokens — typography
+
+- Pick a font pairing from [`knowledge/typography/font-pairings.md`](../../knowledge/typography/font-pairings.md) by mood.
+- Build the type scale using base 14 (product UI) or 16 (marketing). Ratio 1.25 (major third) is the safe default. See [`knowledge/typography/type-scale-fundamentals.md`](../../knowledge/typography/type-scale-fundamentals.md).
+- Define 5–7 named variants: `display`, `heading-lg`, `heading-md`, `heading-sm`, `body-lg`, `body`, `caption`.
+- Each variant has: family, weight, size, line-height, letter-spacing, casing.
+
+For Korean content: bump line-heights by 10%.
+
+### 4. Build tokens — spacing, radius, elevation, motion
+
+Spacing: 4-base scale, 9 stops (`4, 8, 12, 16, 20, 24, 32, 40, 48, 64`). See [`knowledge/layout/spacing-and-grid.md`](../../knowledge/layout/spacing-and-grid.md).
+
+Radius:
+- `radius-none: 0`
+- `radius-sm: 4px`
+- `radius-md: 6–8px` (system default)
+- `radius-lg: 12px`
+- `radius-full: 9999px`
+
+Elevation (4 levels):
+- `elevation-0`: `none`
+- `elevation-1`: `0 1px 2px rgba(0,0,0,0.06)`
+- `elevation-2`: `0 4px 8px rgba(0,0,0,0.08)`
+- `elevation-3`: `0 12px 24px rgba(0,0,0,0.12)`
+
+In dark mode, replace shadow with subtle border + elevated background.
+
+Motion:
+- `motion-fast: 150ms`
+- `motion-default: 250ms`
+- `motion-slow: 400ms`
+- `easing-default: cubic-bezier(0.4, 0, 0.2, 1)` (standard)
+- `easing-emphasized: cubic-bezier(0.2, 0, 0, 1)` (emphasized accelerate)
+
+Cite Ant Design's motion easings ([`knowledge/design-tokens/ant-design.md`](../../knowledge/design-tokens/ant-design.md)) — they ship a tested set.
+
+### 5. Define foundations document
+
+Write a `FOUNDATIONS.md` with:
+- Color usage rules (when to use primary vs accent).
+- Typography hierarchy rules.
+- Iconography (set choice — Material symbols, Lucide, custom — and stroke/size rules).
+- Voice and tone (1 paragraph or skip).
+- Layout grid (12-col, 24px gutter, 24px margin scaling).
+- Density modes if applicable.
+
+### 6. Pick component baseline
+
+Recommend a baseline based on the framework choice:
+- **shadcn-ui** for new React projects with Tailwind. Copy the components, adapt tokens.
+- **MUI** for React projects needing rich pre-built widgets (date pickers, data grids).
+- **Ant Design** for enterprise/dense/Chinese-market or where Form, Table, Tree need to be production-grade out of the box.
+- **Custom (Radix + Tailwind)** if the team has senior FE bandwidth.
+
+Don't recommend more than one — pick the strongest fit and explain why.
+
+### 7. List the starter component set
+
+Pick the right starter set for the product category. Don't ship a 30-component v1 if 12 will do. Don't ship a 12-component v1 if you're building a fintech that needs AmountInput on day 1.
+
+#### Always-needed core (every system, no exceptions)
+
+- Button (3 sizes × 4 intents)
+- Input, Textarea
+- Select / Combobox
+- Checkbox, Radio, Switch
+- Card
+- Modal / Sheet
+- Toast
+- Form (Field/Label/Control composition — see [examples/component-form.md](../../examples/component-form.md))
+- Alert (4 intents: info, success, warning, error)
+- Skeleton, EmptyState
+- Tooltip
+- Badge, Tag
+
+#### Category-specific extensions
+
+| Category | Add to core |
+| --- | --- |
+| **Consumer mobile (B2C)** | Bottom-tab-bar, top-app-bar, list item primitives, pull-to-refresh, swipe actions, quick action sheet, biometric gate (KR fintech) |
+| **B2B SaaS / dashboard** | Table (TanStack), advanced filter bar, column visibility menu, bulk-action bar, breadcrumb, pagination, sidebar nav, command palette (`Cmd+K`) |
+| **Fintech consumer** | All consumer mobile + AmountInput, AmountDisplay (hero), TransactionListItem, AccountCard, CategoryPicker, PaymentMethodSelector, biometric gate, 본인인증 modal |
+| **E-commerce** | Product card grid, AddToCart button, QuantityStepper, Price (with discount), ImageGallery, ProductOptionPicker (size/color), CartSummary, Address autocomplete (Daum Postcode for KR) |
+| **Content / Publishing** | Article header, byline, table-of-contents, share menu, comment thread, reaction bar, related-articles list |
+| **Marketing / Landing** | Hero block, FeatureGrid, TestimonialCarousel, PricingCards, FAQ accordion, NewsletterCTA, Banner (announcement bar) |
+| **Productivity / Tools** | Sidebar with collapsible nav, command palette, keyboard-shortcut display, progress bar, activity log, mention picker |
+| **Social / Community** | Post composer, FeedItem, reactions, comment thread, mention/hashtag autocomplete, infinite-scroll feed, follow button |
+| **Health / Wellness** | Tracker chart (line + area), goal progress ring, streak indicator, reminder card, log entry list |
+
+#### Marked component status
+
+Format the list as:
+
+```
+| Component | Status | Source |
+| --- | --- | --- |
+| Button | derived | shadcn-ui baseline + token override |
+| Input | derived | shadcn-ui baseline |
+| AmountInput | custom | spec via `component-spec-writer` (Phase 2) |
+| TransactionListItem | custom | spec via `component-spec-writer` (Phase 2) |
+```
+
+The custom ones go on the **Phase 2** spec list to be authored next via `component-spec-writer`.
+
+#### Worked example
+
+For a Korean fintech consumer app, the starter set is articulated in [`examples/dogfood-korean-fintech-system.md`](../../examples/dogfood-korean-fintech-system.md). Use it as a structural reference.
+
+### 8. Output structure
+
+Produce a directory:
+
+```
+design-system/
+├── tokens/
+│   ├── color.css        # all color tokens, light + dark
+│   ├── typography.css
+│   ├── spacing.css
+│   ├── radius.css
+│   ├── elevation.css
+│   ├── motion.css
+│   └── tokens.json       # Style Dictionary source
+├── foundations/
+│   ├── color.md
+│   ├── typography.md
+│   ├── spacing.md
+│   ├── iconography.md
+│   └── motion.md
+├── components/
+│   └── README.md         # baseline choice + starter set list
+├── README.md             # how to consume the system
+└── CHANGELOG.md          # versioned token changes (start at v0.1.0)
+```
+
+If the user just wants a single document instead of a directory, condense into one markdown file in the same order.
+
+### 9. Validate
+
+Before declaring done, verify:
+- Every semantic color token has a contrast number.
+- Light and dark are both populated.
+- Type scale has line-heights AND letter-spacing.
+- Motion has both duration and easing.
+- README explains how to consume (CSS import / Tailwind config / MUI ThemeProvider).
+
+## Source files this skill reads
+
+- [`knowledge/colors/color-theory.md`](../../knowledge/colors/color-theory.md)
+- [`knowledge/colors/palettes-by-product-type.md`](../../knowledge/colors/palettes-by-product-type.md)
+- [`knowledge/typography/type-scale-fundamentals.md`](../../knowledge/typography/type-scale-fundamentals.md)
+- [`knowledge/typography/font-pairings.md`](../../knowledge/typography/font-pairings.md)
+- [`knowledge/typography/mui-type-scale.md`](../../knowledge/typography/mui-type-scale.md)
+- [`knowledge/layout/spacing-and-grid.md`](../../knowledge/layout/spacing-and-grid.md)
+- [`knowledge/design-tokens/ant-design.md`](../../knowledge/design-tokens/ant-design.md)
+- [`knowledge/components/INDEX.md`](../../knowledge/components/INDEX.md)
+- [`knowledge/motion/principles.md`](../../knowledge/motion/principles.md)
+- [`knowledge/i18n/korean-typography.md`](../../knowledge/i18n/korean-typography.md) (Korean content)
+- [`knowledge/i18n/korean-product-conventions.md`](../../knowledge/i18n/korean-product-conventions.md) (Korean content)
+- [`knowledge/platforms/react-native.md`](../../knowledge/platforms/react-native.md) (RN target)
+
+## Verification phase (run before declaring done)
+
+- [ ] Did I cite at least one knowledge file per major domain (color, typography, spacing, motion)?
+- [ ] Are tokens named by **role** in the semantic layer, not by hex value?
+- [ ] Does the contrast matrix flag pass/fail for every UI-relevant pair?
+- [ ] Light AND dark are both populated (when both requested)?
+- [ ] Type scale has line-height AND weight AND letter-spacing?
+- [ ] If Korean content: did I apply +10% line-height bump? Recommend Pretendard?
+- [ ] If RN target: did I provide tokens as numbers (not strings)?
+- [ ] Did I pick exactly **one** component baseline with rationale (not multiple)?
+- [ ] Is the starter set sized for the product category (consumer mobile vs B2B SaaS)?
+- [ ] Does each starter component have a status (derived / custom)?
+- [ ] Did I include foundations docs (color, type, spacing, motion, iconography)?
+- [ ] Is the engineering hand-off list specific (commands, configs, vendor SDKs)?
+
+## Done when
+
+- Token files in the requested format(s).
+- Foundations docs cover color, type, spacing, motion, iconography.
+- Component baseline is named with one-paragraph rationale.
+- Starter component list with derived/custom labels and category-appropriate scope.
+- A consumer (frontend dev) can import and start building without questions.
+- The verification phase checklist passes.

package/skills/design-system-builder/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: design-system-builder
+description: Bootstrap a complete design system — tokens (color, type, spacing, radius, elevation, motion), foundations docs, component baseline choice, and starter component list — from a brand brief.
+---
+
+See [PLAYBOOK.md](PLAYBOOK.md).

package/skills/design-system-qa/PLAYBOOK.md

@@ -0,0 +1,163 @@
+# design-system-qa — playbook
+
+Audit a design system for drift, regression, and inconsistency. Output is a prioritized findings list with concrete CI/lint integration recommendations.
+
+## When to use
+
+- "Audit our design system QA"
+- "We have visual bugs slipping into prod — set up testing"
+- "Tokens are drifting — how do we lock this down?"
+- Pre-release: "Is the design system ready to ship?"
+
+## Inputs (ask if missing)
+
+1. **Current QA state**: existing tests? CI pipeline? Visual regression? A11y testing?
+2. **Stack**: React + Storybook + Tailwind? React Native + Detox? Vue + Vitest?
+3. **Scale**: number of components, number of consuming products, team size.
+4. **Pain points**: what's been breaking? Tokens? Visual? A11y? API?
+5. **Budget**: free tools only or willing to pay (Chromatic, Percy)?
+
+## Steps
+
+### 1. Inventory current QA coverage
+
+For each layer, document what exists:
+
+| Layer | Tools currently in use? |
+| --- | --- |
+| TypeScript / type safety | tsc, strict mode? |
+| Token drift | lint rule? Stylelint? |
+| Component contract tests | Jest/Vitest + Testing Library? |
+| A11y | axe-core, storybook-addon-a11y? |
+| Visual regression | Chromatic, Percy, Playwright snapshots? |
+| Figma sync diff | Manual? Tokens Studio? Custom script? |
+
+Cite [`knowledge/patterns/design-system-qa.md`](../../knowledge/patterns/design-system-qa.md) for the canonical layer model.
+
+### 2. Identify gaps
+
+For each missing layer, document:
+- What it would catch
+- Estimated setup effort (S/M/L)
+- Recurring cost (free / paid)
+- Recommended tool
+
+### 3. Audit existing tests for quality
+
+Existing tests aren't necessarily good tests. Run:
+
+- **Coverage report**: which components have any tests?
+- **Story inventory**: how many stories per component? Cover all variants × states?
+- **A11y violations**: run axe on all stories. Count current violations.
+- **Visual snapshot age**: how recent are baselines? Many old snapshots might mask real bugs.
+
+### 4. Priority-order the gaps
+
+Use this severity:
+
+| Severity | Gap |
+| --- | --- |
+| 🔴 Critical | No a11y testing, raw hex in component code, no TypeScript |
+| 🟠 High | No contract tests, no Storybook stories, manual visual review only |
+| 🟡 Medium | Visual regression incomplete, Figma sync not automated |
+| 🟢 Low | Edge case stories missing, dark mode not snapshot-tested |
+
+### 5. Recommend a tactical setup
+
+Based on stack + budget, propose:
+
+```
+Stack: React + Tailwind + Storybook
+Budget: free tier OK
+
+Recommended Phase 1:
+1. Add storybook-addon-a11y (free) — catches ~80% of a11y issues at story level
+2. Set up axe-playwright for page-level a11y (free)
+3. Configure Stylelint with no-color-literal rule (free)
+4. Set up TypeScript strict mode if not already (free)
+5. Write contract tests for top 5 components (Button, Input, Modal, etc.)
+
+Phase 2 (later):
+6. Chromatic for visual regression (paid: $149/mo for Pro tier)
+   OR: Playwright + image-snapshot if free is required
+7. Token drift Figma sync diff
+8. Per-component QA checklist enforcement
+```
+
+### 6. Write the report
+
+Use the structure:
+
+```markdown
+# Design System QA Audit
+
+> Reviewed: <date>
+> System: <name>
+> Reviewer: design-system-qa skill
+
+## Summary
+- Critical gaps: <n>
+- High: <n>
+- Medium: <n>
+- Low: <n>
+- Recommended tools to adopt: <n>
+
+## Layer 1: TypeScript / type safety
+- Status: ✓ in place / ⚠ partial / ✗ missing
+- Findings: ...
+
+## Layer 2: Token drift detection
+- Status: ...
+- Recommendation: Add Stylelint `color-no-hex` rule (free, 30min setup)
+  - Example config: ...
+
+## Layer 3: Component contract tests
+...
+
+## Layer 4: A11y regression
+...
+
+## Layer 5: Visual regression
+...
+
+## Layer 6: Figma sync diff
+...
+
+## CI pipeline integration
+- Recommended GitHub Actions workflow: ...
+
+## Phased rollout
+- Phase 1 (this sprint): ...
+- Phase 2 (next quarter): ...
+
+## Cited sources
+- knowledge/patterns/design-system-qa.md
+```
+
+## Verification phase (run before declaring done)
+
+- [ ] Did I cite `knowledge/patterns/design-system-qa.md` for the layer model?
+- [ ] Does every gap have a specific recommended tool with cost + setup effort?
+- [ ] Is each Critical issue actionable within one sprint?
+- [ ] Did I propose a CI pipeline (or extend an existing one)?
+- [ ] Did I include a phased rollout (not "do everything at once")?
+- [ ] Did I distinguish between layers a tool catches and what still needs human review?
+- [ ] Did I tailor recommendations to the user's stack and budget (not generic)?
+
+## Source files this skill reads
+
+- [`knowledge/patterns/design-system-qa.md`](../../knowledge/patterns/design-system-qa.md) — full layer model
+- [`docs/TOKEN-SYNC.md`](../../docs/TOKEN-SYNC.md) — token sync workflows
+- [`docs/FIGMA-INTEGRATION.md`](../../docs/FIGMA-INTEGRATION.md) — Figma side
+- [`knowledge/a11y/contrast.md`](../../knowledge/a11y/contrast.md) — what a11y tests catch
+- [`knowledge/a11y/keyboard-and-focus.md`](../../knowledge/a11y/keyboard-and-focus.md) — what keyboard tests catch
+- The component specs in [`examples/README.md`](../../examples/README.md) — what contract tests should verify per component
+
+## Done when
+
+- One audit report file.
+- Every gap rated by severity.
+- Every recommendation has tool + cost + setup effort.
+- Phased rollout (Phase 1 = this sprint, Phase 2 = next quarter).
+- CI pipeline recommendation with specific GitHub Actions / GitLab CI config.
+- Verification checklist passes.

package/skills/design-system-qa/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: design-system-qa
+description: Audit a design system for drift, regression, and inconsistency. Outputs a prioritized findings list with concrete CI/lint integration recommendations across 5 testing layers (TypeScript, token drift, contract tests, a11y, visual regression).
+---
+
+See [PLAYBOOK.md](PLAYBOOK.md).

package/skills/document-author/PLAYBOOK.md

@@ -0,0 +1,167 @@
+# document-author — playbook
+
+Write and structure technical or product documentation. Outputs ready-to-publish markdown matching one of the four Diátaxis types (tutorial / how-to / reference / explanation).
+
+## When to use
+
+- "Write a tutorial for getting started with our API"
+- "Document the deployment process"
+- "Create a reference for our SDK"
+- "Write the 'why we chose Postgres' explainer"
+- Any documentation work, technical or product-facing.
+
+## Inputs (ask if missing)
+
+1. **Type** — tutorial / how-to / reference / explanation. If unsure, see decision rules below.
+2. **Topic** — what's being documented.
+3. **Audience** — beginner / intermediate / advanced; technical / non-technical.
+4. **Length** — under 500 words / standard (~1500) / long-form (~3000+).
+5. **Locale** — Korean / English / both.
+6. **Existing system** — design system / docs site to match style with.
+
+## Steps
+
+### 1. Pick the right Diátaxis type
+
+If the user says "documentation," they often mean specifically:
+
+| User says | They probably want |
+| --- | --- |
+| "How do I [verb a goal]?" | **How-to guide** |
+| "Walk me through [feature]" | **Tutorial** |
+| "What does [API/component/method] do?" | **Reference** |
+| "Why did we [decision]?" | **Explanation** |
+
+If genuinely mixed: **split into multiple docs** rather than one mongrel.
+
+Cite [`knowledge/patterns/information-architecture.md`](../../knowledge/patterns/information-architecture.md) for type definitions.
+
+### 2. Apply the right template
+
+Open the template for the chosen type from [`knowledge/patterns/information-architecture.md`](../../knowledge/patterns/information-architecture.md):
+
+- Tutorial: time estimate + audience + prerequisites + numbered steps + "what's next"
+- How-to: TL;DR + steps + variations + pitfalls
+- Reference: signature + parameters + returns + throws + examples per item
+- Explanation: problem + alternatives + decision + tradeoffs
+
+### 3. Write per voice rules
+
+Cite [`knowledge/patterns/technical-writing.md`](../../knowledge/patterns/technical-writing.md):
+
+- Active voice, second person, imperative for instructions.
+- Sentences ≤ 25 words; one idea each.
+- Cut throat-clearing on every pass.
+- Concrete over abstract.
+- Verb-strong.
+
+For **Korean docs**: cite [`knowledge/i18n/korean-document-style.md`](../../knowledge/i18n/korean-document-style.md):
+- 합쇼체 (~합니다) for formal / B2B / technical.
+- 해요체 (~해요) for friendly / consumer / tutorials.
+- Korean prose + English code identifiers.
+- No italic on Hangul.
+
+### 4. Add code samples
+
+Cite [`knowledge/patterns/technical-writing.md`](../../knowledge/patterns/technical-writing.md) on code samples:
+- Must run.
+- Strip noise.
+- Show context, not full files.
+- Comment surprising lines inline.
+- Simplest example that demonstrates.
+
+For Korean docs: prose Korean, code English. Example:
+
+```markdown
+이 함수는 사용자 정보를 조회합니다.
+
+```ts
+const user = await getUserById("u_123");
+console.log(user.email);
+```
+
+`getUserById`은 `User | null`을 반환합니다. 사용자가 존재하지 않으면 `null`입니다.
+```
+
+### 5. Add the right embellishments
+
+| Type | Add | Skip |
+| --- | --- | --- |
+| Tutorial | Screenshots, "what you'll build" preview, encouraging callouts | Reference tables, dense API docs |
+| How-to | TL;DR snippet, numbered steps, "common pitfalls" | Long preamble, motivation |
+| Reference | Tables, code per signature, exhaustive | Narrative, "why we built this" |
+| Explanation | Comparison tables, prose, citations | Step-by-step instructions |
+
+Use `Callout` for important asides. See [`examples/component-callout.md`](../../examples/component-callout.md).
+
+### 6. Layout for the medium
+
+If the doc renders on a doc site (Docusaurus / Nextra / etc.): use MDX with the site's components.
+
+If standalone markdown: plain markdown that renders on GitHub.
+
+For long docs: include in-page TOC pattern that the [`component-doc-page.md`](../../examples/component-doc-page.md) describes (most doc sites auto-generate from h2/h3).
+
+### 7. Write the metadata
+
+Every doc page should have:
+
+```markdown
+---
+title: <title>
+description: <1-2 sentence lede>
+type: tutorial | how-to | reference | explanation
+audience: <who>
+last_updated: 2026-05-08
+---
+
+# <Title>
+
+<Lede paragraph — 1-2 sentences. What this doc is about.>
+
+<Body...>
+
+## Cross-reference
+
+- [Related doc 1](path)
+- [Related doc 2](path)
+```
+
+### 8. Cross-reference + cite
+
+Every doc should:
+- Link to **related docs** in the same site (cross-reference section at end).
+- Cite **knowledge files** (in design-ai's case) or other authoritative sources.
+- Link to upstream / official docs (e.g., MDN for web APIs).
+
+## Verification phase (run before declaring done)
+
+- [ ] Did I pick the right Diátaxis type, or split into multiple docs?
+- [ ] Did I follow the type's template?
+- [ ] Did I cite relevant knowledge files (`knowledge/patterns/document-typography.md`, etc.)?
+- [ ] Are sentences ≤ 25 words and one-idea-each?
+- [ ] Are code samples runnable + minimal?
+- [ ] If Korean: is voice level (~합니다 vs ~해요) consistent throughout?
+- [ ] Do I have a "Cross-reference" section linking related docs?
+- [ ] Did I avoid throat-clearing intros / conclusions?
+- [ ] Is the lede answer-led, not preamble?
+
+## Source files this skill reads
+
+- [`knowledge/patterns/document-typography.md`](../../knowledge/patterns/document-typography.md)
+- [`knowledge/patterns/information-architecture.md`](../../knowledge/patterns/information-architecture.md)
+- [`knowledge/patterns/technical-writing.md`](../../knowledge/patterns/technical-writing.md)
+- [`knowledge/patterns/report-design.md`](../../knowledge/patterns/report-design.md) — for report-style docs
+- [`knowledge/i18n/korean-document-style.md`](../../knowledge/i18n/korean-document-style.md) — Korean conventions
+- [`examples/component-callout.md`](../../examples/component-callout.md) — for callouts
+- [`examples/component-doc-page.md`](../../examples/component-doc-page.md) — for layout
+
+## Done when
+
+- One markdown file (or set of files for a multi-doc deliverable).
+- Frontmatter complete.
+- Lede paragraph leads with the answer / what this is.
+- Body matches the chosen Diátaxis template.
+- Code samples are runnable.
+- Cross-reference section links related docs.
+- Verification phase passes.

package/skills/document-author/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: document-author
+description: Write and structure technical or product documentation. Picks the right Diátaxis type (tutorial / how-to / reference / explanation), applies its template, follows technical-writing voice rules, includes runnable code samples, and links related docs. Korean-aware.
+---
+
+See [PLAYBOOK.md](PLAYBOOK.md).