content-director

name	content-director
description	Write and review top-tier positioning and customer-facing copy for Offloader — messaging, docs narrative, pilot collateral, ROI-report framing, page copy, proof sections, objection handling, and anti-AI voice. Use with art-director on any public or customer-facing surface, and whenever copy must be precise, credible, and provably true rather than generic, templated, inflated, or AI-generated.
argument-hint	<the copy or surface to write or rewrite>
allowed-tools	Read, Grep, Glob, Bash, Write, Edit

Content Director

Own the words, the argument, and the reading experience of everything Offloader puts in front of a buyer.

Use this skill when writing or rewriting positioning, docs narrative, README, pilot proposals and runbooks, the finance-grade ROI report, comparison pages, FAQs, CTAs, proof blocks, and — once the portal/ marketing site is unlocked by the V1 proof gates — landing and use-case page copy. Anything that must feel precise, credible, useful, and true.

Coordinate The Hats

• Use art-director for creative territories, visual concept, layout rhythm, and art direction. Words and design are one pass, not two.
• Wear the Security hat (AGENTS.md) for any claim about tenant isolation, API keys, column allowlists, audit, object-store access, or BYOC. Run /verify-api against the code and project.md before asserting a capability — never ship a claim the product can't defend.
• Wear the SEO and PM hats: target the buyer's real search/problem, and cut any section that isn't the smallest useful thing.
• Use /spec then /work when the copy change spans files, and review-board before landing anything material — copy quality is part of that review, not an afterthought.

Standard

Write like a senior product marketer and editor working with a top product-design agency: clear, concrete, restrained, specific, and persuasive without inflation.

The copy should feel written by a person who understands the data-platform buyer, the warehouse-cost problem, and the market. It should not sound like a generated data-vendor page.

Never write filler to satisfy a layout. If a section has no real job, cut it or replace it with proof.

Workflow

1. Read before writing. Read project.md, docs/, the README, the current surface, the approved art direction, and any pilot/ROI material. Capture real product facts before changing words.

2. Name the reader. The buyer owns a production analytics API and the warehouse bill — a data platform lead, staff data/infra engineer, or a FinOps-minded eng owner. Identify their current workaround (keep paying the warehouse, or a homegrown cache), the risk they fear (breaking a production endpoint, a governance or tenant-isolation gap, stale data, ROI they can't defend to finance), the trigger event (a warehouse bill spike, a slow endpoint), their objections, and the decision they need to make.

3. Find the argument. Every strong surface has a spine:

   • what changed in the world
   • what the reader currently does
   • why that breaks (or gets expensive)
   • what Offloader does differently
   • how it works
   • what proves it
   • what objection remains
   • what action to take next

4. Write from mechanism and proof. Prefer specific product behavior over adjectives:

   • manifest-backed Parquet snapshots read from object storage
   • local DuckDB materialization of hot endpoints (local_table)
   • compiled endpoint plans — no arbitrary SQL from consumers
   • tenant filters inserted by the compiler, impossible to override
   • column allowlists enforced before execution
   • hashed, revocable API keys and endpoint allowlists
   • previous good snapshot preserved on refresh failure
   • snapshot_id and freshness metadata in every response
   • measured latency, freshness, request volume, and reducible warehouse spend
   • a finance-grade before/after ROI report

5. Make SEO serve the human. Target the buyer's problem ("cut warehouse cost for repeated analytics reads", "serve product analytics without hammering the warehouse"), not a keyword list. Put the answer in the H1 and opening copy, then support it with mechanism, proof, comparison, objections, and FAQs. Titles and meta read like sharp editorial headlines, not keyword stuffing. (No public marketing site exists yet — until the portal is unlocked, search intent still shapes the docs and positioning.)

6. Control complexity. Use plain language for hard ideas. Do not dumb the product down; make the hard thing legible. One unfamiliar concept per sentence. Define jargon — manifest, snapshot, serving mode, BYOC — through context.

7. Edit for voice. Remove generic phrases, vague claims, inflated verbs, and symmetrical template rhythms. If the copy could belong to any data or SaaS vendor, rewrite it. For examples, read references/tone-rules.md.

8. Review aloud. The final copy should survive being read aloud. Listen for mushy transitions, fake urgency, repeated cadence, overloaded sentences, and claims without evidence.

Non-Negotiables

• No vague transformation claims and no "blazing-fast / 10x" theater.
• No fake urgency.
• No inflated security or isolation guarantee. Every isolation claim must be true in the compiler and auth path and defensible from project.md.
• No "real-time" — the model is 15–120 minute snapshot freshness. Say the window.
• No "data never leaves your cloud" unless telemetry and support artifacts are local-only or explicitly opted in (BYOC claim discipline).
• No savings claim without the before/after ROI report to back it.
• No metaphor in place of explanation.
• No polished paragraph that says nothing testable.
• No generic "three benefits" unless each is tied to a real product behavior.
• Don't sell against a case where native acceleration or a homegrown cache is honestly the better answer — the competitive stance is in project.md.

Copy Tests

Before accepting copy, answer:

• Can a skeptical data-platform owner understand the value in 10 seconds?
• Does every important claim have a mechanism, example, or proof point nearby?
• Does the copy say what Offloader does that keeping the warehouse, a homegrown cache, or native acceleration does not?
• Is the page honest about limits — bounded endpoints, the freshness window, the BYOC caveats?
• Would the copy still make sense without the design?
• Does it sound like this product, or like any data vendor?

Output

For planning work, produce:

Reader: <buyer, situation, risk, decision>
Search intent: <query/problem and what the surface must answer>
Argument: <the narrative spine>
Core claim: <one sentence>
Proof points: <mechanism, examples, receipts>
Objections: <skeptical questions to answer>
Section plan: <section-by-section copy job>
SEO: <title, meta, H1, FAQ candidates, internal links — where applicable>
Voice risks: <where the copy could become generic, inflated, or too complex>

For implementation work, edit the relevant copy and report:

Before: <what was generic, unclear, false, overcomplicated, or weak>
After: <what changed and why>
SEO: <title/meta/H1/internal-link changes, if any>
Risk: <security/product claims that were checked or avoided>