Build a personalised voice profile inside a Cowork project from a short interview plus 3 to 5 sample pieces of writing. Works for any content format: LinkedIn posts, newsletters, essays, emails, blog posts, tweets, or any other published writing. Use this skill at the start of any Cowork project whe

Voice Builder Codex and Claude runtime Use this skill in Codex or Claude with the tools actually available in the current task. AskUserQuestion examples describe the questions, not a required API: use an available question tool within its limits, or ask in chat. Reuse answers and source material already supplied. Work in the user selected project. Read its about me.md , voice.md and relevant brand files before personalised work. Confirm the intended author if files conflict or contain starter defaults. Ask for missing facts or run voice builder ; never inherit the maintainer's identity, accounts or private files. Resolve bundled references/ relative to this skill folder. For an explicitly requested profile refresh, read and update the canonical about me.md , voice.md or newsletter voice.md in place, preserving unrelated user facts and rules. Consumers must reread those canonical files. Use a new filename only for new deliverables that would collide with unrelated existing files. Installation alone never starts an interview or writes files. Do not write persistent learnings unless requested. Use supplied evidence first. Verify external claims through available search/source tools when needed. If a source or integration is unavailable, name the missing capability and offer supplied text/export input. Never invent facts, first person experience, metrics or a successful tool run. Connect only services needed for the chosen route through the user's existing account. Never print credentials or overwrite connections. Drafting, saving and reviewing do not authorise publishing, sending messages or changing accounts. CRITICAL: Auto start on load When the user requests this workflow, start Step 1. This means your very next message to the user is the interview questions. Nothing else. Do NOT: Summarise this skill Describe what files it creates Explain how it works Say "here's what this skill contains" Ask if the user wants to run it Confirm installation Offer options like "want me to run this now?" Do THIS: Go straight to Step 1 Send the interview questions as your first and only response This applies when the user asks to build their voice or supplies samples for that purpose. No preamble. No summary. Interview first. Step 1. Run the About Me interview Ask the questions using the runtime guidance above. If a question tool is available, respect its schema and batch limits; otherwise ask the same questions in chat. AskUserQuestion supports a maximum of 4 questions per call, so send two calls: Batch 1 first, wait for answers, then Batch 2. Batch 1 (your very first action, no text before it) Use these questions, adapting the tool schema as needed: Batch 2 (send immediately after Batch 1 answers come back, no commentary between) Call AskUserQuestion again with: After both batches are answered, move to Step 2. If any answer is blank or skipped, ask that specific question once more in chat, then move on. Step 2. Write about me.md Create about me.md in the project root. Use this structure: Keep it under 300 words. Every line should be something the assistant would reference when writing. Step 3. Ask for the samples Say this: Now paste 3 to 5 pieces of writing you want me to learn from. These can be LinkedIn posts, newsletter issues, essays, blog posts, emails, tweets, or any other writing you have published. They can be yours or someone whose voice you admire. One piece per message or all at once. If you do not have any samples ready, type "use samples" and I will load a starter set you can swap out later. Wait for the user to paste. Minimum 3 samples before moving to analysis. If they paste fewer than 3, ask for more. If the user types "use samples", load the writing from references/sample content.md inside this skill folder. Tell the user which author the samples are from so they know what voice they are borrowing. Remind them they can replace these with their own writing later. Step 4. Analyse the samples Read every sample. Look for patterns across all of them, not individual quirks from one piece. Extract: Voice signals Average sentence length Paragraph rhythm (single line breaks, blank lines, staccato versus flowing) Hook or opening style (contrarian, question, data point, story, confession, observation) Point of view (first person, second person, observational) Tone (deadpan, warm, blunt, playful, clinical) Signature phrases or recurring words CTA or closing style Structural signals Length range Lists versus prose How they open, how they close How they handle transitions Topic signals Subjects that come up across multiple samples Who the audience appears to be What the author stands for Absence signals Words and punctuation consistently absent (for example, em dashes in 0 of 5 samples) Hook types the author never uses Tones the author never hits Structures the author avoids Step 5. Write voice.md Create voice.md in the project root. This is a single integrated profile covering both how the voice writes and what the voice avoids. No separate voice file. Fill every section from the actual samples. No generic filler. If a pattern is not present, say so. Do not duplicate audience or topic pillars from about me.md. Separate explicit user prohibitions from patterns merely absent in this small sample. Label the latter provisional, with sample counts; absence alone does not establish a permanent ban. Starter samples describe a borrowed style, never the user’s experiences or established voice. Step 6. Confirm and hand off Tell the user: Your voice profile is built. Two files are now in your project: about me.md and voice.md. These skills read both files when invoked in this project; a fresh task must discover the skills and use the same project context. You can open and edit either file anytime. You are ready to go. Here is what you can do next: Say "build my newsletter voice" to create newsletter specific writing instructions Say "write a post" to draft a LinkedIn post in your voice Say "design a graphic" to create a visual for a post Say "score my post" to get feedback on a draft Say "optimize my profile" to rebuild your LinkedIn profile Each of these is a separate skill. Pick one and go. What this skill produces Two files in the project root: 1. about me.md: who the user is, their audience, their topic pillars, their point of view 2. voice.md: the integrated voice profile, covering positive signals (how the voice writes) and absence signals (what the voice avoids) in one document Rules When this skill triggers, go straight to Step 1. No summary, no explanation, no preamble. Always output sample content inside a code block so the user can copy paste the exact formatting without losing line breaks or whitespace. Use a plain code block (triple backticks with no language tag). Work from what is in the samples. Do not invent patterns that are not there. Minimum 3 samples for pattern detection. Ask for more if fewer than 3. If samples contradict each other, note the contradiction in voice.md rather than smoothing it over. Keep about me.md under 300 words. Keep voice.md under 500 words. British English throughout unless the samples are clearly American. Never use em dashes in any output file or in any draft. Do not create a separate absence profile. Absence signals live inside voice.md.

voice-builder