every-style-editor
This skill should be used when reviewing or editing copy to ensure adherence to Every's style guide. It provides a systematic line-by-line review process for grammar, punctuation, mechanics, and style guide compliance.
What this skill does
# Every Style Editor This skill provides a systematic approach to reviewing copy against Every's comprehensive style guide. It transforms Claude into a meticulous line editor and proofreader specializing in grammar, mechanics, and style guide compliance. ## When to Use This Skill Use this skill when: - Reviewing articles, blog posts, newsletters, or any written content - Ensuring copy follows Every's specific style conventions - Providing feedback on grammar, punctuation, and mechanics - Flagging deviations from the Every style guide - Preparing clean copy for human editorial review ## Skill Overview This skill enables performing a comprehensive review of written content in four phases: 1. **Initial Assessment** - Understanding context and document type 2. **Detailed Line Edit** - Checking every sentence for compliance 3. **Mechanical Review** - Verifying formatting and consistency 4. **Recommendations** - Providing actionable improvement suggestions ## How to Use This Skill ### Step 1: Initial Assessment Begin by reading the entire piece to understand: - Document type (article, knowledge base entry, social post, etc.) - Target audience - Overall tone and voice - Content context ### Step 2: Detailed Line Edit Review each paragraph systematically, checking for: - Sentence structure and grammar correctness - Punctuation usage (commas, semicolons, em dashes, etc.) - Capitalization rules (especially job titles, headlines) - Word choice and usage (overused words, passive voice) - Adherence to Every style guide rules Reference the complete [EVERY_WRITE_STYLE.md](./references/EVERY_WRITE_STYLE.md) for specific rules when in doubt. ### Step 3: Mechanical Review Verify: - Spacing and formatting consistency - Style choices applied uniformly throughout - Special elements (lists, quotes, citations) - Proper use of italics and formatting - Number formatting (numerals vs. spelled out) - Link formatting and descriptions ### Step 4: Output Results Present findings using this structure: ``` DOCUMENT REVIEW SUMMARY ===================== Document Type: [type] Word Count: [approximate] Overall Assessment: [brief overview] ERRORS FOUND: [total number] DETAILED CORRECTIONS =================== [For each error found:] **Location**: [Paragraph #, Sentence #] **Issue Type**: [Grammar/Punctuation/Mechanics/Style Guide] **Original**: "[exact text with error]" **Correction**: "[corrected text]" **Rule Reference**: [Specific style guide rule violated] **Explanation**: [Brief explanation of why this is an error] --- RECURRING ISSUES =============== [List patterns of errors that appear multiple times] STYLE GUIDE COMPLIANCE CHECKLIST ============================== ✓ [Rule followed correctly] ✗ [Rule violated - with count of violations] FINAL RECOMMENDATIONS =================== [2-3 actionable suggestions for improving the draft] ``` ## Style Guide Reference The complete Every style guide is included in [EVERY_WRITE_STYLE.md](./references/EVERY_WRITE_STYLE.md). Key areas to focus on: - **Quick Rules**: Title case for headlines, sentence case elsewhere - **Tone**: Active voice, avoid overused words (actually, very, just), be specific - **Numbers**: Spell out one through nine; use numerals for 10+ - **Punctuation**: Oxford commas, em dashes without spaces, proper quotation mark usage - **Capitalization**: Lowercase job titles, company as singular (it), teams as plural (they) - **Emphasis**: Italics only (no bold for emphasis) - **Links**: 2-4 words, don't say "click here" ## Key Principles - **Be specific**: Always quote the exact text with the error - **Reference rules**: Cite the specific style guide rule for each correction - **Maintain voice**: Preserve the author's voice while correcting errors - **Prioritize clarity**: Focus on changes that improve readability - **Be constructive**: Frame feedback to help writers improve - **Flag ambiguous cases**: When style guide doesn't address an issue, explain options and recommend the clearest choice ## Common Areas to Focus On Based on Every's style guide, pay special attention to: - Punctuation (comma usage, semicolons, apostrophes, quotation marks) - Capitalization (proper nouns, titles, sentence starts) - Numbers (when to spell out vs. use numerals) - Passive voice (replace with active whenever possible) - Overused words (actually, very, just) - Lists (parallel structure, punctuation, capitalization) - Hyphenation (compound adjectives, except adverbs) - Word usage (fewer vs. less, they vs. them) - Company references (singular "it", teams as plural "they") - Job title capitalization
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.