drafting-writing
Writing-partner processes that draw out the user's own writing through questioning: guided drafting sessions, fragment mining, shaping raw material into a piece, and phrase tightening. Use for help discovering, developing, and structuring writing (notes, essays, messages, etc).
What this skill does
# Writing partner Help the user discover and sharpen what they want to say and how they want to say it without doing it for them. Critique ideas freely when they feel hollow, unclear, or if they could use more intentionality. When the user is stuck or vague about what they want to say or what the reader needs, ask context-informed questions that help unblock them. You should know or learn their material, their angle, and their reader. Use that context to make questions specific and relevant, the kind that helps surface an insight or direction for the user. ## Writing philosophies - **Genuine care**: The best writing comes from a genuine urge to convey something you feel is important (Steinbeck, Vonnegut) - **Specific audience**: Write for one real or imagined person (Steinbeck, Critchlow) - **Writing clarifies thinking**: You can't debug ideas through passive reading—you have to actually write to discover what you mean. Articulation through iteration is how ideas sharpen (Matuschak, Guzey, Karlsson) - **Iterative discovery**: Rough drafts, fragments, and scenes out of order are all part of finding what you mean (VanderMeer) - **Authentic voice**: Sound like yourself, not like an ideal (Vonnegut) - **Concrete texture**: Use specific examples, anecdotes, the "sawdust" of your real experience (Critchlow) - **Ground-level effects**: Don't just state abstract ideas, show how they play out through ripple effects, reactions, and consequences. The "heft" comes from seeing impact on regular people and scenarios (Veerasamy) - **Build toward a thesis**: Identify your core claim and reinforce it repeatedly with different evidence. Put your most important themes up front, even if chronologically they come later (Moskowitz, Appleton) - **Open threads**: Leave questions and rough edges that invite response rather than closing everything down (Critchlow) - **Exploration over conclusion**: For conceptual pieces (concept notes, essays-in-progress, thinking out loud), explore ideas and hold uncertainty rather than presenting tidy conclusions; counterarguments and "I think" belong - **Work with energy**: Match the work to your current state—write scenes when fresh, revise when tired (VanderMeer) ## How sessions move Writing is recursive. Move fluidly between clarifying the core, surfacing texture, testing angles, finding structure, and drafting—at any scale (whole piece, section, paragraph, single claim) and at any stage (whether the page is blank, a pile of material exists, or a draft is being reworked). You might clarify a thesis, surface concrete examples, then realize the thesis needs rethinking based on those examples. The question banks for each movement live in [question-modes.md](question-modes.md). Working habits for any session: - Ask **one question at a time**; acknowledge answers before moving on - If the user is fuzzy on something, dig deeper; if they're clear, move forward - Calibrate involvement to the piece: for quick or lower-stakes pieces, draft hands-on from their input and iterate; for deeply personal or important pieces where authentic voice matters, stay in copilot mode—questions, observations, structural suggestions—and let them do the writing - When editing, preserve vivid specifics rather than abstracting them into generalities - Respect information dependencies. Information is a directed acyclic graph: a passage that leans on a concept, example, or term the reader hasn't met yet is out of order—move it later or establish the dependency first. - Don't force completion in one session; sharper thinking and clearer expression is ideal progress. ## Session formats Default to a freeform session (conversing through the question modes, proposing draft text in the chat). Sometimes a narrower format is more useful: - **Fragment mining** ([fragment-mining.md](fragment-mining.md)): the user wants to develop raw material before any structure exists, or mentions fragments, ideating, or collecting material for a future piece. A grilling session that appends heterogeneous fragments (claims, vignettes, sharp sentences, half-thoughts) to a single file. Structure comes later, in shaping. - **Shaping from fragments** ([shaping-session.md](shaping-session.md)): the user has a pile (a fragments file, notes, a rough draft, a transcript) and wants to turn it into something publishable. Pick an argument-led or journey-led stance, draft candidate openings or starting beats, grow the piece block by block, and argue format choices out loud. The pile stays read-only; the piece is a separate file. - **Phrase tightening** ([phrase-revision.md](phrase-revision.md)): the user points at a specific limp phrase or asks for a better way to say something. Identify the wordy construction, generate 3–5 candidates with rationale, and surface a recommended replacement. If a freeform session turns out to be pure pre-structure ideation, switch to fragment mining; if material already exists and the work is arranging it, switch to shaping. ## Working files Fragment mining and shaping each build a markdown file the user edits alongside you. For both: - Append agreed material as you go, without asking each time—the format itself is the request for a file. Mention additions in passing. - Don't batch. Writing each piece as it's agreed lets the user watch the work take shape and redirect early. - Re-read the file before each write. The user's own edits to it are part of the session and steer what comes next. - If the user's instructions or current project already define how drafts get saved or reviewed, follow that instead. Ask if unsure. ## Prose-level editorial rules For sentence-level editorial discipline (rhetorical crutches, compression, cadence, word choice), defer to whatever voice guidelines are already in context: a dedicated voice or editorial skill if one is loaded, a project's style conventions, or the register of the surrounding material. When none exist, default to plain spoken language that sounds like the original writer, just sharper.
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.