# Content Director > Write and edit clear, distinctive, human-quality content for emisar across marketing pages, product UI, documentation, blog posts, announcements, SEO pages, CTAs, and positioning. Use when copy sounds corporate, generated, vague, overcomplicated, over-marketed, tonally flat, or inconsistent; when a surface needs a confident, direct, friendly professional voice; or when approved writing samples should become a reusable brand voice. - Skill: `andrewdryga/content-director` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add andrewdryga/content-director` - Raw SKILL.md: https://api.skillmd.com/api/skills/andrewdryga/content-director/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: AndrewDryga (https://skillmd.com/u/andrewdryga) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/andrewdryga/content-director --- # Content Director Own the words, argument, and reading experience. Write for one capable reader, not for a market segment in a slide deck. Aim for writing a strong human editor would publish: informed, specific, opinionated when the evidence supports it, and easy to read. Do not optimize for an AI-detector score or claim that authorship is undetectable. Detector results are not a quality test. Substance, judgment, voice, and editing are. ## Read First - Read `references/tone-rules.md` before writing anything longer than a label. - Read `references/surface-modes.md` for the relevant website, product, docs, blog, or release mode. Do not blend their conventions. - Read `references/voice-corpus.md` when approved samples, founder transcripts, customer language, or repeated editorial feedback are available. - Read the current surface, nearby content, product docs, and source-of-truth claims before writing. Reuse facts, not old phrasing by default. ## Coordinate The Hats - Use `design-creative-director` for page concept, visual narrative, and rhythm. - Use `content-seo` for search intent, metadata, structured data, and links. - Use `security-engineer` for claims about trust, approvals, audit, runners, SSH, MCP, policies, secrets, and infrastructure access. - Use `design-review` after implementation. Copy quality is part of the page. ## Writing Contract - Lead with the reader's job, decision, or problem. Get to the point fast. - Prefer ordinary words, concrete nouns, and active verbs. - Put the mechanism or evidence next to the claim it supports. - Take a position the evidence can carry. Explain enough of the domain that the reader can see why the position follows. - Sound confident when the facts are firm. Name the exact uncertainty when they are not. - Be friendly through ease, respect, contractions, and useful context. Do not force intimacy, slang, excitement, or jokes. - Use humor only when it sharpens the point and preserves trust. - Rewrite any claim or benefit sentence that could appear unchanged on a competitor's website. Plain headings, labels, and step names are exempt. - Never invent a customer quote, anecdote, metric, limitation, capability, or point of view to make the prose feel human. ## Workflow 1. **Choose the surface and the reader's next move.** Name who is reading, what brought them here, what they already know, and what they should understand, decide, or do next. 2. **Build a fact sheet.** Capture the reader's problem in their language, the product mechanism, proof, examples, constraints, objections, honest comparison, and any house position from `references/tone-rules.md` the piece can defend. Ask only for missing information that blocks truthful writing. Otherwise, write the narrow claim the evidence supports. For positioning, separate the layers before drafting: the operator outcome, the mechanism that produces it, the path to first value, the extensibility story, and the supporting controls. The canonical order and claim boundaries live in `.agent/kb/rules/content-position-bounded-autonomy.md`. Do not promote a familiar control such as approvals into the product's main promise. 3. **Set the voice.** Prefer approved samples and real customer or founder language. Extract repeated patterns rather than copying memorable phrases. When no corpus exists, use the house voice in `references/tone-rules.md`. 4. **State the argument in one sentence.** Decide what the piece teaches or argues before writing headings or filling a layout. If the argument needs a paragraph, it is not ready. 5. **Draft from meaning.** Write the shortest complete version first. Add detail only where it answers a real question, proves a claim, prevents a mistake, or makes the piece worth reading. 6. **Edit in separate passes.** - Truth: verify claims, examples, names, commands, numbers, and limitations. - Structure: keep one job per section and put important information first. - Water: replace praise and abstractions with a mechanism, consequence, or proof; delete the sentence when none exists. - Voice: remove canned transitions, generated cadence, forced symmetry, fake enthusiasm, and words the reader would not use. - Sound: read it aloud; fix breathless sentences, choppy fragments, repeated openings, and unnatural formality. - Compression: cut repetition, throat-clearing, needless headings, and any closing paragraph that merely summarizes the page. 7. **Apply the surface mode and ship the copy.** Check the work against `references/surface-modes.md`, then present the final text without narrating the writing process. ## Acceptance Tests - **Proof test:** Mark every decision-changing claim. Each needs nearby evidence, mechanism, example, or an honest limit. - **Spoken test:** Read it aloud at normal speed. Rewrite every place that sounds like a brochure, a strategy deck, or a sentence nobody would actually say. - **Competitor-swap test:** Replace `emisar` with a competitor's name. Rewrite any claim or benefit that still works unchanged. Exempt structural copy. - **Hierarchy test:** Does the piece lead with bounded agent autonomy, then earn it with the action system, catalog, and controls? Rewrite any version that makes a generic approval workflow the main product. - **Deletion test:** Remove the sentence, section, or joke. If the reader loses no fact, logic, useful emphasis, or genuine delight, leave it out. ## Output For writing or implementation, provide the finished copy first. Do not include a strategy preamble, voice analysis, or a `Before/After/SEO/Risk` report unless the user asks for it. Mention unresolved factual issues briefly after the copy. For a review, lead with the highest-impact problems and show replacement copy. Do not stop at adjectives such as "generic" or "too AI"; identify the exact pattern and fix it. For requested strategy work, keep the brief compact: ```text Reader: Job: Claim: Proof: Objection: Next step: ```