/create-x-content

name: create-x-content
description: >
  Draft voice-tuned X (Twitter) post variants from a free-form brief. Reads a personal
  voice guide (generated via generate-voice-guide), produces 2–5 variants with
  distinct framings (simple-howto, problem-first, hype, mechanism-breakdown, etc.),
  and self-checks against the voice guide's banned phrases before returning.
tags: [content, social]

Create X Content

Draft X/Twitter post variants that sound like you, not like an AI. Reads a voice guide the user has already generated (or prompts to create one), produces multiple framings of the same idea, and saves each variant as its own markdown file with frontmatter.

**This is an agent-executed skill** — the agent does the drafting and self-check inline. No Python script.

Quick Start

/create-x-content --brief "New open-source CLI that turns Figma files into React components. Called figma2react. Free, MIT licensed."

Or interactively:

/create-x-content

Inputs

| Flag | Required | Default | |------|----------|---------| | `--brief` | Yes (asked interactively if missing) | — | | `--variants` | No | Skill decides based on brief richness (2–5) | | `--voice-guide` | No | Resolved via chain below | | `--output` | No | `./content/YYYY-MM-DD-<topic-slug>/` | | `--topic` | No | Derived from brief |

Voice Guide Resolution

Resolve in this order, stop at first hit:

1. `--voice-guide <path>` flag 2. `~/.goose-skills/config.json` → `voice_guides.x` 3. `~/.goose-skills/voice-guides/voice-x.md` (default path) 4. **Fallback prompt** — no guide found. Give the user three options:

• (a) Paste a path to an existing guide
• (b) Run `/generate-voice-guide --platforms x` now to create one (recommended)
• (c) Proceed with a neutral default (warn that variants will sound generic)

Never silently skip the voice guide. Generic posts are the failure mode to avoid.

Workflow

Phase 1 — Load the voice guide

Read the resolved voice guide into context. Extract, for use throughout drafting:

• **Banned phrases** — treat as hard blocks
• **Hook patterns** — sample these for variant framings
• **Format rules** — length ranges, line-break style, emoji policy
• **Dos/don'ts** — apply to every variant
• **Example posts** — use as calibration targets

Phase 2 — Parse the brief and decide variant count

Decide variant count by richness:

• **2 variants** — one-line opinions, single-angle hot takes, simple tool mentions with no mechanism
• **3 variants** — typical tool spotlights, single how-tos, observations with one clear angle
• **4 variants** — multi-angle topics (a how-to + a problem-first frame + a hype frame + a mechanism breakdown)
• **5 variants** — rich, mechanism-heavy content where several distinct hooks all have real substance

If `--variants` is explicitly set, respect it. Otherwise pick the smallest count where each variant genuinely adds a different angle. **Quality > quantity.** 2 strong variants beat 5 watered-down ones.

Phase 3 — Generate variants with explicit framing

Each variant gets a distinct *framing label* that determines its structure and hook:

| Framing | Structure | When to use | |---------|-----------|-------------| | `simple-howto` | Bare steps, no mechanism | Tool install + usage, 2–3 line how-to | | `howto-plus-mechanism` | How-to + "here's how it works" breakdown | Tools where the mechanism is interesting | | `problem-first` | Open with the pain, then solution | When the problem is visceral/relatable | | `hype` | Punchy "someone just dropped X" energy | Launches, new OSS releases, cool builds | | `mechanism-breakdown` | Focus on the *how* | Technical builds, systems, architectures | | `ecosystem-map` | Curated list of N related tools/companies | Landscape posts | | `contrarian` | "Most people do X wrong" opener | Opinion pieces with a clear counter-take | | `personal-experience` | "We've been doing X. Here's what I learned" | Field notes, lessons learned |

Use framings the voice guide's hook patterns actually support. Don't force framings the user never employs.

Phase 4 — Self-check against the voice guide

Before saving, run each variant through these checks:

1. **Banned phrase check** — does the variant use any phrase from the voice guide's banned list? If yes, rewrite that line. 2. **Length check** — does it fit the voice guide's format rules (short-form <280, long-form 100–1000, etc.)? 3. **"Meat" check** — does it have at least one concrete reference: a specific tool, number, workflow, or build? If not, it's filler — rewrite. 4. **Voice-match spot check** — would this plausibly appear in the example posts section of the voice guide? If it reads like a generic AI tweet, rewrite.

If a variant fails any check and two rewrite attempts don't fix it, drop the variant rather than ship something weak.

Phase 5 — Save outputs

Write each variant as its own `.md` file. File naming:

variant-<letter>-<framing-slug>.md

Examples: `variant-a-simple-howto.md`, `variant-b-problem-first.md`.

Frontmatter schema:

---
id: <topic-slug>-<letter>
platform: x
format: short | long
topic: <slug>
framing: <framing-slug>
status: draft
---

Body: just the post text. No commentary, no surrounding markdown.

Phase 6 — Deliver

Print to the user:

• Output directory path
• List of files created
• Variant count + framings used
• Suggested next step (review, tweak, or run `/social-kit` for a matching graphic)

Outputs

• `<output>/variant-<letter>-<framing>.md` per variant
• No index file — each variant is self-contained

Examples

**Simple brief:**

/create-x-content --brief "npx goose-skills install claude-code-hooks — a new skill that adds pre-commit, pre-tool-use, and post-response hooks to Claude Code so you can enforce coding standards automatically."

→ 3 variants (howto, hype, mechanism)

**Rich brief:**

/create-x-content --brief "Built a Claude-driven lead gen system. Scrapes Reddit for people asking about em