Johnny Suede Write

Johnny Suede Write

The writing enchilada. Route any writing request through one skill: long-form, short-form, GitHub and docs, social, email, product listing copy, brand-voice alignment, and public explainer talk-tracks. Default voice is the Suede house voice. A supplied company brief overrides everything.

Core principle: copy earns its place on the page with concrete nouns, buyer-visible outcomes, real proof, and one primary action. Nothing decorative, nothing invented.

Pick The Lane (Router)

Read the request, then pick the lane. Most jobs are one lane; some chain.

| You want to... | Lane | |---|---| | Write or rewrite any copy surface from scratch | Write Modes (below) — pick the mode | | Generate headlines, CTAs, or email subjects | Headline Formulas / CTA Formulas / Variant Protocol | | Tune existing copy to sound like Suede, not generic AI | Brand-Voice Alignment lane | | Hand a public user words to explain Suede to someone else | Public Explainer Talk-Track lane | | Audit/review existing copy and return findings + score | Copy Audit output shape | | Do a metadata/structure/copy-quality SEO pass alongside copy | SEO And GitHub Copy + SEO Audit Mode |

Drop down instead of running this stack: for a single standalone conversion surface (one email, one hero, one button set) with no SEO pass and no voice retune, run $suede-copy directly. When the copy ships inside a design or layout build, run $johnny-suede-design; its Copy lane applies these rules.

Cross-lane jobs (e.g. "rewrite the homepage, retune it to our voice, and give me social variants") run sequentially with shared context: write the surface, run Brand-Voice Alignment on it, then spin variants. State the chain you ran.

If the request is a full standalone SEO/AEO audit with a scored report, a landing-page-to-conversion-engine transform, an A-F page grade, a code grade/review, or a reference-URL restyle, those live in dedicated skills outside this writing enchilada ($suede-seo-audit, $suede-site-alchemy, $suede-visibility-grader, $suede-code-grader, $suede-code-review, $suede-agent-teams, $suede-design, or $johnny-suede-design and its Suedify lane for restyles). Route there and pass full context; do not reimplement them here. This skill owns the writing.

Multi-Agent Default

If a job is large or risky enough to run as a coordinated agent team (for example a full launch package spanning many surfaces, or a writing job chained with audits and reviews across several skills), ask the user up front before spawning anything: "Run this as a multi-agent team (more thorough) or single-agent?" Never silently spawn a fleet. Note plainly that multi-agent mode may use slightly more tokens than most. For a single writing surface, just write it — no need to ask.

Write Modes

Identify the mode before writing. Each mode has a different structure, length, and proof requirement. State the chosen mode in the output header.

Long-form (blog post, case study, whitepaper, README, docs page, product listing description)

• Lead with the outcome, not the topic.
• Structure: hook → problem → mechanism → proof → action.
• Minimum: H1, 2-3 subheads, one FAQ block, meta description, answer-ready summary.
• Score target: 62/70.

Short-form (tagline, hero headline, CTA, product description, social caption, onboarding screen)

• One concrete noun + one buyer-visible outcome + one verb. No filler.
• Deliver 3 variants at different lengths. Character counts matter for mobile, social, and ads — state them.
• Score target: 65/70 (density and specificity weighted higher).

GitHub / Docs (README, SKILL.md, API docs, changelog, contributing guide)

• First sentence: what it does, not what it is.
• Structure: one-line description → install → quickstart → reference.
• No marketing language in technical docs. Proof is code examples and working commands.
• Score target: 60/70 (authenticity and specificity weighted higher).

Social (Twitter/X, LinkedIn, Instagram, Discord, launch post)

• Open with the most specific claim or result, not the setup.
• No "excited to announce." No "thrilled to share." No em dashes.
• Deliver: main post + short variant + CTA + 3 hook variants.
• Platform structures and limits: read references/email-and-social-formats.md.

Email / DM (cold outreach, launch email, nurture, public explainer brief)

• Subject line is the headline. Write it last.
• Open with the reader's problem, not the sender's news.
• One ask per email. One CTA.
• Deliver: subject (3 variants) + preview text + body + CTA + P.S. line. Full mechanics: read references/email-and-social-formats.md.

Before Writing

Read any available context files before asking questions: PRODUCT.md, README.md, AGENTS.md, AI_HANDOFF.md, DESIGN.md, product marketing or brand notes, task-specific docs.

If context is missing after reading, ask only for what blocks accurate copy:

• page or doc type
• primary reader
• one action the reader should take
• product or skill being offered
• proof that is safe to claim
• claims, pricing, partners, or metrics that are not approved
• traffic source or publication surface

Company Brief

Supply a brief and all writing, voice, SEO, copy, and claim logic applies to your company. A supplied brief overrides the Suede default everywhere. Use natural language or this form:

Company:
Product or offer:
Audience:
Category:
Voice:
Terms to use:
Terms to avoid:
Proof:
Allowed claims:
Forbidden claims:
Primary CTA:
Reference URLs:
Assets or brand rules:

When a company override is active: replace Suede positioning with the user's company, category, audience, proof, and vocabulary. Keep the full workflow intact. Map Suede-native concepts to the user's domain only when they fit. Rename Cue Suede to Cue in final feedback.

Core Rules

Name the outcome, not the feature.

• Weak: "Suede supports multiple metadata formats."
• Strong: "Export ISRC, ISWC, and split data in one command."

Write buttons as actions with a result.

• Weak: "Learn more" → Strong: "Read how rights routing works"
• Weak: "Get started" → Strong: "Register your first release"

Replace vague claims with artifacts.

• Weak: "Suede makes rights management easy."
• Strong: "Paste your folder path. Suede outputs your ISRC, split sheet, and licensing flags in under 10 seconds."

No invented proof. Do not write stats, testimonials, partner names, pricing, or legal clearance that has not been confirmed. If proof is unavailable, write around the gap or flag it for the human to supply.

No em dashes in public copy. No exclamation points. No rhetorical questions that answer themselves.

Persuasion Frameworks

Match framework to surface and reader temperature. State the chosen framework and reader temperature before drafting. If multiple could apply, pick one and note why.

• Reader arrives cold, no prior awareness: AIDA (Awareness → Interest → Desire → Action). Lead with the category problem, build specificity, make the outcome concrete, drive a single action.
• Reader has a named pain and is actively searching: PAS (Problem → Agitate → Solution). Name the problem, surface the cost of inaction, position the product as the specific relief.
• Hero section, social post, launch email: Before-After-Bridge. Describe life before the product, paint life after, bridge with the product as the mechanism.
• Product page, onboarding, in-app copy: JTBD (Jobs-to-be-Done). Write around what the reader is trying to accomplish — the job they hired the product to do, not the features.
• Homepage, About, long-form brand page: StoryBrand 7-Part. Character (customer) → Problem → Guide (your brand) → Plan → CTA → Avoid failure → Achieve success.

Headline Formulas

Generate 3 headline candidates minimum for any hero or email subject, each from a different formula. Read references/headline-and-cta-formulas.md for the 12-formula bank with structures and examples (curiosity gap, number-led specificity, how-to outcome, because, specificity anchor, before-after, real question, objection flip, if-then, claim with proof hook, problem named exactly, authority plus specificity).

Gate: swap your product name for a competitor's. If the headline still works, it is not specific enough. Rewrite before scoring.

Persona Mode

State the persona before writing. It changes vocabulary, proof type, and CTA framing. If multiple personas share a page, write the hero for the decision-maker and include practitioner proof in the secondary section.

• Decision-maker (exec, founder, buyer, investor): lead with outcome and cost of inaction in revenue/risk/time terms; proof is outcomes and named results, not features ("Cut release prep from 3 days to 40 minutes"); CTA low-risk and high-clarity ("See the workflow"); skip implementation details and CLI commands.
• Practitioner (developer, designer, operator, creator): lead with how it works, not why it matters; proof is commands, file paths, schema examples, error outputs; CTA direct ("Run the linter", "Fork the skill"); skip ROI language and vague transformation claims.
• Skeptic (comparison shopper, previously burned): lead with the objection, named directly ("Every tool claims to solve this. Here's what's different."); proof is third-party verifiable ("Open the script. Read the output."); CTA zero-pressure ("Read the code", "Run it yourself"); skip hype and superlatives.
• Creator / end-user (non-technical): lead with what changes for them, in plain language; proof is before/after in human terms; CTA lowest-friction ("Try it with one release folder"); skip technical vocabulary and command syntax.

Default to practitioner for GitHub/docs copy, decision-maker for sales/landing pages, and skeptic for competitive or comparison copy.

Page And Docs Structure

For a page, README, or docs surface, build this spine. For a small section, use only the pieces that fit.

1. Hero: one sentence that names the outcome.
2. Subhead: one or two sentences that add the audience, workflow, and proof.
3. Primary CTA: the action the reader can take now.
4. Proof: files, scripts, docs, screenshots, URLs, live routes, examples, or commands.
5. How it works: three or four steps, each with a verb and a result.
6. Safety: what the workflow does not claim or do.
7. FAQ: direct answers for objections and search intent.
8. Final CTA: repeat the action with less friction.

Variant Protocol

For any headline, CTA, subject line, or hero copy: generate 3 variants by default unless the user specifies otherwise. Label each variant, state which axis it targets, and recommend one. Let the user pick rather than guessing.

Variant axes: specificity (one abstract, one mid-spec, one hyper-specific with a concrete number or named proof); register (founder voice, product voice, skeptic-facing); length (long full thought, medium compressed, short one punch).

Per surface: headlines get 3 angles (outcome-led, problem-led, mechanism-led); CTAs get 2 variants minimum; email subjects get 3 (curiosity or benefit; social proof or number; direct question or challenge).

CTA Formulas

Every CTA answers: "What happens the moment I click this?" Four formulas with examples live in references/headline-and-cta-formulas.md: verb + immediate result; verb + object + benefit; low-commitment framing (skeptic/discovery); stakes-aware framing (decision-maker).

Anti-patterns to cut: "Get started" (started what?); "Learn more" (more about what?); "Sign up" (for what, exactly?); "Try for free" without naming what they're trying; any CTA with an exclamation point.

Gate: describe what happens after clicking in 3 words. If you cannot, the CTA is too vague.

Email And Social Formats

Read references/email-and-social-formats.md before drafting any email, DM, LinkedIn, X/Twitter, or Instagram copy: subject-line formulas, preview-text rules, the 5-part email body structure, unsubscribe-reduction sequence, and per-platform post structures with formatting limits.

Non-negotiables that survive the summary: write the subject last; one ask and one CTA per email; preview text adds information instead of echoing the subject; the first two lines of a social post are the post; open with the most specific claim, never the setup.

Suede Voice

Use this register: confident, not breathless; technical enough for builders; clear enough for creators; polished, not corporate; specific, not cute; operator-grade, not brochure-grade.

Good Suede copy names what the reader controls: register a work, verify rights, route royalties, publish a claim, package a release folder, prepare licensing evidence, make a work readable to agents, compare provenance, ship a public skill page.

For Suede work, anchor public language in creator ownership, programmable IP, provenance, registry-backed media, royalty routing, licensing readiness, and agent commerce. Do not reduce Suede to a generic AI music app. (For non-Suede work, supply the equivalent domain vocabulary in the company brief.)

Brand-Voice Alignment Lane

Use this lane to tune existing copy to the house voice without flattening it into generic AI product language. This is editing, not greenfield writing.

Voice rules:

• Lead with what the reader can do.
• Name concrete artifacts: skills, docs, scripts, reports, install commands, rights passports, provenance notes, split checks, QA checklists.
• Prefer creator ownership, programmable IP, rights, provenance, registry-backed media, royalty routing, licensing readiness, and agent commerce.
• Avoid vague "AI music app" framing.
• Avoid unsupported metrics, partner claims, legal clearance, payout claims, or guaranteed outcomes.
• Make CTAs verbs: install, audit, create, read, verify, open, package.

Edit pass:

1. Cut filler and throat clearing.
2. Replace broad claims with proof.
3. Make the primary action obvious.
4. Keep local-only details out of public headline copy.
5. Add a claim boundary when rights, money, registry, or release language appears.

Line-edit rules:

• Name the actor. Use the creator, operator, buyer, agent, page, repo, command, workflow, route, or proof artifact instead of vague market or page agency.
• Put the reader in the room with a concrete artifact: rights passport, provenance note, split check, install command, QA checklist, screenshot, source link, release folder.
• Cut pull-quote slogans unless backed by a specific action or proof.
• Replace jargon with the thing the reader can inspect, click, ship, verify, or reuse.
• Avoid formulaic pivots, negative listing, Wh-starter crutches, fake intensity, lazy extremes, passive actor-hiding, and em dashes.

Output of this lane: the revised copy only, plus any claims that need verification. Do not append the full workflow scaffolding unless asked.

Public Explainer Talk-Track Lane

Use this lane when a public user needs words to explain Suede to someone else — not to audit public copy or fix a failing install. Hype-free, claim-safe, outcome-first. Use "explain" language, not "pitch" language.

Explain:

1. Start with the outcome: agents ship better public work with less setup.
2. Route the reader to the right lane: workflow skills, creator skills, MCP, design, copywriting, SEO/AEO/AI EO, artist campaigns, creator utilities, install docs, or copy bank.
3. Keep the language public-safe. Do not imply legal clearance, payout approval, distribution, registry writes, private service access, or guaranteed results.
4. Avoid internal implementation details unless the reader is installing or debugging.
5. Include one next action and one proof link.

Formats:

One-liner:
DM:
Post:
Email:
FAQ answer:
Install explanation:
Claim boundary:

SEO And GitHub Copy

Discoverability is not optional. Every output gets an SEO title, meta description, H1, answer-ready summary, and FAQ candidates unless the

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: JasonColapietro
• Source: JasonColapietro/suede-creator-skills
• License: MIT
• Homepage: https://jasoncolapietro.github.io/suede-creator-skills/

Install and usage instructions live in the source repository linked above.