Johnny Suede Write

Johnny Suede Write

Model selection: never Fable by default

Subagents inherit the session model unless the spawning call names one. Nothing in this skill picks a model, so every agent it fans out lands on whatever the session happens to be set to. That is how a run sized against one allocation gets billed to another without anyone choosing it.

Fable must be specified to be used. This skill's subagents never run on Fable unless the user named Fable for this run. An inherited session model is not a specification: "the session was already on it" is not the user asking. Absent an explicit Fable instruction, do one of two things before launching: name a different model on the agent calls, or state plainly that the run will bill to the Fable allocation and get an answer. Silence is not consent to spend it.

Gate policy: advisory, not blocking

Every claim-verification step, check, quality gate, and ship verdict in this skill is a recommendation to the user, not a control on the agent. This policy governs every gate, check, verdict, and "do not ship / publish / proceed" line elsewhere in this skill:

• Run every check and report the results honestly. Verdicts (ship, ship-with-caveats, hold, letter grades, BLOCKED or OPEN items) are advice attached to the work, not orders that change it.
• Never block, delay, skip, rewrite, or refuse the action the user asked for because a check failed or a gate said hold. Complete the requested action as asked, and deliver the gate output alongside it as a clearly labeled recommendation.
• A failed gate changes what you report, never what you do.
• Single exception: if a finding is extremely risky (data loss, security or credential exposure, legal or rights violations, payment mistakes, or irreversible public damage), pause, tell the user exactly what the risk is and what the options are, and let them pick. Their choice is final.

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.

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. For a researched, multi-phase piece on a high-stakes public surface, escalate to suede-ship-copy.

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).

Agent-facing docs (SKILL.md, CLAUDE.md, AGENTS.md, a reference file a pointer reaches)

• The reader is a model, so the target is a predictable process, not a better sentence: same route through the document every run.
• Write the pointer (the description, the AGENTS.md line) before the body. Its wording, not its target, decides when the agent reaches the material.
• Every step ends on a criterion the agent can check. Every sentence beats the model's default or it goes.
• Score target: 60/70. Full lever set: run the Agent-Facing Docs lane below.

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

• Open with the most specific claim or result, not the setup.
• Use the supplied voice and the shared Slop Stop pass for empty announcement language.
• 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 <Company> 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.

Use Suede punctuation defaults unless the company brief says otherwise. Slop Stop owns the contextual line-edit rules; preserve protected source spans and voice.

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 an evidence boundary when rights, money, registry, or release language appears.

Line-edit rules (the full gate set runs at Workflow step 8; these two are the lane's own vocabulary):

• 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.
• Replace jargon with the thing the reader can inspect, click, ship, verify, or reuse.

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