Author a Playbook Play

VerifiedCaution

Add a new play to hogsend.com/playbook. Follows strict frontmatter and five-part body structure with copy rules.

Sby Skills Guide Bot
ContentIntermediate
7/24/2026
Claude Code
#content-authoring#mdx#frontmatter#copywriting#playbook

Recommended for

Automated summary

Guides the end-to-end authoring of a hogsend.com playbook play, from validated frontmatter to the five-part body, including register rules and verification gates.

Strengths

  • Supplies the exact frontmatter contract (category, personas, channels, tags) backed by registries and build-time validation
  • Cleanly separates tool-agnostic play steps from the Hogsend reference implementation in a `defineJourney()` snippet
  • Enforces checkable editorial rules: no invented statistics, deletion test on every line, no hype adjectives
  • Explains that the "Copy for your agent" block is generated from the raw MDX, which justifies keeping the play steps vendor-neutral

Limitations

  • Tightly bound to the hogsend monorepo: `lib/playbook/*` registries, `source.config.ts`, the `defineJourney()` API and a sibling dogfood checkout
  • The supplied text cuts off mid-way through the weekly-rotation sync section, leaving that step only partly described
  • No guidance on internal linking, imagery or SEO beyond the meta description
When to use it

Use it when creating or revising an MDX file under apps/docs/content/playbook in the hogsend repository.

When not to use it

Avoid it for general-purpose content writing or for a playbook hosted outside the Hogsend ecosystem.

Security analysis

Caution
Quality score82/100

The skill is a documentation-authoring guide. Its only execution surface is standard build/lint/dev-server commands and appending an entry to a sibling repo, all legitimate for a docs workflow. There are no destructive commands, no curl|sh, no base64 payloads, no secret/token exfiltration, and no safety-disabling instructions. Because it does invoke bash/build tooling with file writes, it lands at 'caution' rather than 'safe', but the risk is low and expected.

Findings
  • •Instructs running shell/package-manager commands (pnpm biome check --write, pnpm --filter @hogsend/docs check-types, build, next dev), which execute project and dependency code.
  • •Directs editing a sibling checkout (hogsend-dogfood) and appending to a PLAYS array — writes outside the primary skill directory, though append-only.
  • •Includes a screenshot/browser verification step requiring running the local dev server.
How this analysis is made

Examples

New winback play
Add a new playbook play called 'Win back subscribers who stopped opening' at apps/docs/content/playbook/winback-cold-subscribers.mdx — category winback, channels [email], and follow the full play contract.
Tool-agnostic play steps
Draft the MDX for a play about converting onboarding drop-offs; keep 'The play' section tool-agnostic and put every Hogsend event name only in 'Ship it with Hogsend'.
Audit an existing play
Review apps/docs/content/playbook/activation-first-week.mdx against the play contract and fix any frontmatter, section-order or register issues you find.

name: author-playbook-play description: Add a new play to hogsend.com/playbook (apps/docs/content/playbook). Use whenever someone wants a new playbook item — it walks the whole contract end to end - frontmatter, the intro + five-part template in the right register, the copy rules (tool-agnostic play steps, honest facts, valid engine snippets), the dogfood weekly-rotation sync, and the verification gates. The plays shipped in #492 follow this shape.

Author a playbook play

A play is a ~300–600 word micro-play at apps/docs/content/playbook/<slug>.mdx, rendered at hogsend.com/playbook/<slug>. It must survive the "is this from real work?" test — same discipline as the marketing copy register.

1. Frontmatter (validated by source.config.ts — unknown slugs fail the build)

---
title: Imperative, outcome-first (max ~60 chars)
description: One sentence, for meta tags and cards.
hook: The one-line symptom the reader recognizes — present tense, their pain.
category: one of activation | onboarding | retention | revenue | winback | referral | deliverability | measurement (registry: lib/playbook/categories.ts)
personas: [] or a subset of gtm | founders | recruiters | internal | agencies (registry: lib/playbook/personas.ts; empty = everyone)
channels: subset of email | sms | ads | video (registry: lib/playbook/channels.ts) — only channels the play's body actually uses; feeds the filter drawer
tags: [two, or, three]
date: YYYY-MM-DD
timeToResults: honest — "same day", "one week", "2–4 weeks", "ongoing"
---

Do NOT set blueprint: unless a same-id Journey Blueprint actually exists and has been verified end-to-end (create via admin API → hogsend blueprints list → promote --dry-run). No unverified Installs badges.

2. Body structure — intro + the five parts, in this exact order

  1. Intro paragraph (no heading, right after frontmatter): one or two sentences of plain language saying what the play IS. No code, no event names, no product names beyond "email".
  2. ## When to run it — the trigger/symptom, who feels it.
  3. ## Why it works — the mechanism. A real number ONLY if we honestly have one; never invent statistics. Mechanism reasoning beats fake benchmarks.
  4. ## The play — a numbered list of steps in general terms: someone on any stack (or no stack) could hand this section to an engineer and get the play built. No event.names, no Hogsend APIs, no vendor lock. "Track two moments", not "emit setup.step_started".
  5. ## Ship it with Hogsend — the Hogsend reference implementation. A short lead-in sentence, then a defineJourney() snippet that would actually compile: real API only (ctx.waitForEvent, exitOn, entryLimit + entryPeriod, suppress is required meta, ctx.guard.isSubscribed() after long waits, distinct idempotencyLabel when the same template sends twice). Event names live HERE. Cross-link the deeper recipe (/docs/recipes/...) when one exists.
  6. ## How you'll know — the metric: outcome within a window, framed as a funnel/lift the reader can actually build. Link /docs/conversions/impact where holdout/lift talk earns it.

3. Register rules

  • Every line a fact (deletion test). Guide-through voice, why-first.
  • No hype adjectives, no "unlock", no invented percentages.
  • The hook and title must not overlap word-for-word with the intro.

4. The install path is the agent prompt — it's automatic

The play page ships a "Copy for your agent" block (components/playbook/copy-play-prompt.tsx + lib/playbook/prompt.ts) that wraps the raw MDX as an implement-this prompt. It reads the file directly — nothing to wire per play. This is WHY section 4's steps must be tool-agnostic: the prompt is handed to agents on stacks that aren't Hogsend.

5. Sync the weekly rotation

The dogfood repo (hogsend-dogfood, sibling checkout) sends one play a week: src/journeys/playbook-weekly.ts holds a hand-synced PLAYS array (slug/title/hook). Append the new play there (append-only — never reorder or remove while enrollments are active; each week is anchored by sleep + idempotency labels derived from the slug).

6. Verify before commit

pnpm biome check --write apps/docs
pnpm --filter @hogsend/docs check-types
pnpm --filter @hogsend/docs build     # validates frontmatter + MDX

Then run the real app (pnpm --filter @hogsend/docs exec next dev --port 3105 if 3005 is busy) and screenshot the play page AND the index with the new card — no HTML mockups. Check: intro renders above the numbered 01–05 sections, list markers show, the copy button copies the full prompt.

One commit per play, conventional format, e.g. feat(docs): playbook play — <slug>.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/author-a-playbook-play-mryiqijb/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/author-a-playbook-play-mryiqijb' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/author-a-playbook-play-mryiqijb/download' --output '.skill-downloads/author-a-playbook-play-mryiqijb/SKILL.md.part' && mv '.skill-downloads/author-a-playbook-play-mryiqijb/SKILL.md.part' '.skill-downloads/author-a-playbook-play-mryiqijb/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code
test -f '.skill-downloads/author-a-playbook-play-mryiqijb/SKILL.md' && test -s '.skill-downloads/author-a-playbook-play-mryiqijb/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/author-playbook-play' && cp -R '.skill-downloads/author-a-playbook-play-mryiqijb' '.claude/skills/author-playbook-play'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/author-a-playbook-play-mryiqijb'

openskills read 'author-a-playbook-play-mryiqijb'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/author-a-playbook-play-mryiqijb/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills