Receber por email
← Voltar para o catálogo

create-x-content

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.

744estrelas
Atualizado há 4 meses

Ver no GitHub ↗

Como adicionar

/plugin marketplace add gooseworks-ai/goose-skills

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/create-x-content/svg)](https://www.skillteca.com.br/skills/create-x-content)
#ai

Alerta por categoria

Receba novas skills de Design e Frontend toda segunda

1 email curto, só com as skills novas de Design e Frontend. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

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:
  5. (a) Paste a path to an existing guide
  6. (b) Run /generate-voice-guide --platforms x now to create one (recommended)
  7. (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 email deliverability, finds their domains, verifies their business email via Hunter, drafts a personalized DM. 47 leads in 6 hours at $0.03/lead."

→ 5 variants (personal-experience, mechanism-breakdown, hype, problem-first, simple-howto)

Dependencies

  • A voice guide at the resolved path (see Voice Guide Resolution above)
  • generate-voice-guide skill (for creating one when missing)

Tips

  • Default to fewer variants. Five weak ones is worse than two strong ones. The skill should feel picky, not generous.
  • Framings must actually differ. Don't write five variants with the same opening hook and minor tweaks. Each variant = a different lens on the same idea.
  • Quote the brief's specifics verbatim in the variant. Numbers, tool names, prices — these are the "meat." Losing them to paraphrasing kills the post.
  • If the voice guide has a "field-notes deep-dive" hook pattern and the brief is rich enough, include one long-form variant. That format tends to outperform on X.
Compartilhar X LinkedIn