substack-writer
starsforks
How to install substack-writer?
getnao/sylph/substack-writer
$npx -y skills add getnao/sylph --skill substack-writer---
SKILL.md
| 1 | # Substack Article Writer |
| 2 | |
| 3 | ```yaml |
| 4 | name: substack-writer |
| 5 | description: > |
| 6 | Writes long-form Substack articles - benchmarks, how-tos, opinion pieces, explainers, |
| 7 | product-led content, and personal essays. Handles the full lifecycle from draft |
| 8 | through review and self-improvement. |
| 9 | triggers: |
| 10 | - substack article |
| 11 | - write an article about |
| 12 | - long-form post |
| 13 | - newsletter article |
| 14 | arguments: |
| 15 | - draft: Create a new article from scratch or from user notes |
| 16 | - refine: Edit and improve an existing draft |
| 17 | - title: Generate title options for a draft |
| 18 | - insights: Review performance and update _insights.md |
| 19 | ``` |
| 20 | |
| 21 | --- |
| 22 | |
| 23 | ## MCP connectors |
| 24 | |
| 25 | | Connector | Purpose | |
| 26 | |-----------|---------| |
| 27 | | Substack | Publish articles (via browser or API) | |
| 28 | |
| 29 | ## Publication Context |
| 30 | |
| 31 | Fill this in for your Substack: |
| 32 | |
| 33 | ```yaml |
| 34 | publication_name: "[Your Publication Name]" |
| 35 | publication_url: "[your-substack].substack.com" |
| 36 | audience: "[Who reads this - roles, interests, level]" |
| 37 | cadence: "[How often you publish]" |
| 38 | topics: "[Core topics the publication covers]" |
| 39 | ``` |
| 40 | |
| 41 | --- |
| 42 | |
| 43 | ## Format Library |
| 44 | |
| 45 | | Format | When to Use | Typical Length | |
| 46 | |--------|------------|---------------| |
| 47 | | **Benchmark** | You have data comparing tools, approaches, or outcomes | 1500-2500 words | |
| 48 | | **How-to** | Teaching a specific process with steps | 1200-2000 words | |
| 49 | | **Opinion** | Taking a stance on an industry trend or practice | 800-1500 words | |
| 50 | | **Explainer** | Breaking down a complex topic for your audience | 1200-2000 words | |
| 51 | | **Product-led** | Showing your product solving a real problem | 1000-1800 words | |
| 52 | | **Personal** | Leadership journey, lessons learned, reflections | 800-1500 words | |
| 53 | |
| 54 | --- |
| 55 | |
| 56 | ## Universal Article Structure |
| 57 | |
| 58 | Every article follows this skeleton, regardless of format: |
| 59 | |
| 60 | ``` |
| 61 | [Title - specific, benefit-oriented or curiosity-driven] |
| 62 | |
| 63 | [Subtitle - one sentence that expands the title] |
| 64 | |
| 65 | [Opening - 2-3 paragraphs max, hook + context + thesis] |
| 66 | |
| 67 | [Body - 3-5 sections with H2 headers] |
| 68 | |
| 69 | [Closing - key takeaway + forward look + CTA] |
| 70 | ``` |
| 71 | |
| 72 | ### Opening Rules |
| 73 | - First sentence must create tension, state a finding, or ask a question |
| 74 | - By paragraph 2, the reader should know what they'll learn |
| 75 | - By paragraph 3, you should be into the substance |
| 76 | - Never open with a dictionary definition |
| 77 | - Never open with "In today's fast-paced world..." |
| 78 | |
| 79 | ### Section Rules |
| 80 | - Each H2 section should have a clear purpose |
| 81 | - Use H3 sparingly - only when a section genuinely has subsections |
| 82 | - Each section should be 200-500 words |
| 83 | - Transition between sections should feel natural, not forced |
| 84 | |
| 85 | ### Closing Rules |
| 86 | - Restate the key takeaway in one sentence |
| 87 | - Add a forward-looking statement (what's next, what to watch for) |
| 88 | - End with a CTA: subscribe, try it, share, reply with your experience |
| 89 | |
| 90 | --- |
| 91 | |
| 92 | ## Format-Specific Rules |
| 93 | |
| 94 | ### Benchmark Articles |
| 95 | - Always state the methodology upfront: what you tested, how, and what the constraints were |
| 96 | - Present data in tables or clear lists - not buried in paragraphs |
| 97 | - Include your raw results or link to them |
| 98 | - Address obvious objections ("But what about X?") |
| 99 | - State limitations honestly |
| 100 | - Compare fairly - don't set up strawmen |
| 101 | |
| 102 | ### How-to Articles |
| 103 | - Number the steps |
| 104 | - Each step should be independently actionable |
| 105 | - Include code blocks, screenshots, or examples where relevant |
| 106 | - Start with prerequisites (what the reader needs before starting) |
| 107 | - End with the expected outcome (what success looks like) |
| 108 | - Add a "Troubleshooting" section for common issues |
| 109 | |
| 110 | --- |
| 111 | |
| 112 | ## Voice Principles |
| 113 | |
| 114 | ### Do |
| 115 | - Write in first person ("I tested...", "We built...") |
| 116 | - Be direct - get to the point fast |
| 117 | - Lead with evidence, then interpret |
| 118 | - Be honest about limitations, failures, and unknowns |
| 119 | - Address the reader as a peer, not a student |
| 120 | - Use specific numbers over vague claims |
| 121 | - Write for your community - reference shared context |
| 122 | |
| 123 | ### Don't |
| 124 | - Use "In conclusion" or "To summarize" - the reader can see it's the end |
| 125 | - Use passive voice when active is clearer ("The data was analyzed" -> "I analyzed the data") |
| 126 | - Use em dashes (--) or en dashes - use hyphens (-) or colons (:) |
| 127 | - Use "game-changing", "revolutionary", "groundbreaking" |
| 128 | - Use "unpack", "deep dive", "landscape" |
| 129 | - Use "leverage" when you mean "use" |
| 130 | - Hedge excessively ("It could potentially maybe...") |
| 131 | - Use "learnings" - use "lessons" or "what we learned" |
| 132 | |
| 133 | --- |
| 134 | |
| 135 | ## Formatting Rules |
| 136 | |
| 137 | - **Bold** for emphasis, not italics (bold is scannable, italics are not) |
| 138 | - Use bullet lists for 3+ items |
| 139 | - Use numbered lists only for sequential steps |
| 140 | - Code blocks for any code, commands, or technical output |
| 141 | - Tables for comparisons and structured data |
| 142 | - One image per major section maximum |
| 143 | - Pull quotes sparingly - only for genuinely striking lines |
| 144 | - Break up any paragraph longer than 4 sentences |
| 145 | |
| 146 | --- |
| 147 | |
| 148 | ## Draft Structure Rules |
| 149 | |
| 150 | When working from user-provided notes or an existing draft: |
| 151 | |
| 152 | 1. **Stay close to the user's narrative arc.** Don't reorganize their structure unless it's genuinely broken. |
| 153 | 2. **Improve, don't rewrite.** Tighten language, strengthen transitions, add eviden |
People who liked this also viewed
6 picksType
- seo-auditWhen the user wants to audit, review, or diagnose SEO issues on their site. Also use when the user mentions "SEO audit," "technical SEO," "why am I not ranking," "SEO issues," "on-page SEO," "meta tagSkillsJul 2026
- copywritingWhen the user wants to write, rewrite, or improve marketing copy for any page — including homepage, landing pages, pricing pages, feature pages, about pages, or product pages. Also use when the user sSkillsJul 2026
- marketing-psychologyWhen the user wants to apply psychological principles, mental models, or behavioral science to marketing. Also use when the user mentions 'psychology,' 'mental models,' 'cognitive bias,' 'persuasion,'SkillsJul 2026
- content-strategyWhen the user wants to plan a content strategy, decide what content to create, or figure out what topics to cover. Also use when the user mentions "content strategy," "what should I write about," "conSkillsJul 2026
- programmatic-seoWhen the user wants to create SEO-driven pages at scale using templates and data. Also use when the user mentions "programmatic SEO," "template pages," "pages at scale," "directory pages," "location pSkillsJul 2026
- marketing-ideasWhen the user needs marketing ideas, inspiration, or strategies for their SaaS or software product. Also use when the user asks for 'marketing ideas,' 'growth ideas,' 'how to market,' 'marketing stratSkillsJul 2026
