blog-writing-specialist by manojbajaj95/claude-gtm-plugin
npx skills add https://github.com/manojbajaj95/claude-gtm-plugin --skill blog-writing-specialist综合性的博客写作,结合技术深度、个人声音转换和 AEO 优化。
| 输入类型 | 使用章节 |
|---|---|
| 技术教程、深度解析、基准测试 | 技术博客写作 |
| 思维转储 → 润色后的文章 | Nick Nisi 声音 |
| 个人声音(Jarad 风格) | Jarad 的声音 |
| 公司/产品/技术类别文章 | Lightfast 类别系统 |
| 不确定 | 从这里开始,根据需要调整 |
撰写面向开发者的技术博客文章。
分步指导。读者应该能构建出东西。
结构:
1. 我们要构建什么(附截图/演示)
2. 先决条件
3. 步骤 1:设置
4. 步骤 2:核心实现
5. 步骤 3:...
6. 完整代码(GitHub 链接)
7. 后续步骤 / 扩展
| 规则 | 原因 |
|---|
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 先展示最终结果 | 让读者知道是否值得继续 |
| 明确列出先决条件 | 不要浪费错误受众的时间 |
| 每个代码块都应该是可运行的 | 复制-粘贴-运行是检验标准 |
| 解释“为什么”而不仅仅是“怎么做” | 解释原理的教程更易被分享 |
| 包含错误处理 | 真实代码会遇到错误 |
| 链接到完整的代码仓库 | 教程后的参考 |
深入解释一个概念、技术或架构决策。
结构:
1. 什么是 [概念] 以及为什么你应该关心?
2. 它是如何工作的(简化的心智模型)
3. 它是如何工作的(详细机制)
4. 真实世界示例
5. 权衡以及何时不应该使用它
6. 延伸阅读
描述出了什么问题、原因以及修复了什么。
结构:
1. 摘要(发生了什么、影响、持续时间)
2. 事件时间线
3. 根本原因分析
4. 实施的修复
5. 我们为防止再次发生所做的措施
6. 经验教训
对工具、方法或架构进行数据驱动的比较。
结构:
1. 我们比较了什么以及为什么
2. 方法论(以便结果可复现)
3. 带图表/表格的结果
4. 分析(数字意味着什么)
5. 建议(附注意事项)
6. 原始数据 / 复现说明
解释系统是如何构建的以及为什么做出这些决策。
结构:
1. 我们需要解决的问题
2. 约束和需求
3. 考虑的选项
4. 选择的架构(附图表)
5. 我们接受的权衡
6. 结果和经验教训
| 要做 | 不要做 |
|---|---|
| 直接了当:“使用连接池” | “你可能想要考虑使用...” |
| 承认权衡:“这增加了复杂性” | 假装你的解决方案是完美的 |
| 使用“我们”表示团队决策 | “我单枪匹马设计了...” |
| 具体数字:“将 p99 从 800ms 降低到 90ms” | “显著提高了性能” |
| 引用来源和基准测试 | 做出无来源的断言 |
| 承认替代方案 | 假装你的方法是唯一的方式 |
❌ “在当今快节奏的技术世界中...”(废话)
❌ “正如我们所知...”(如果我们都知道,为什么要写?)
❌ “只需做 X”(如果是在看教程,没有什么是简单的)
❌ “这很容易...”(轻视读者的经验)
❌ “显然...”(如果显而易见,就不要写)
❌ 技术内容中的营销语言
❌ 在 3 段背景介绍后才切入主题
| 规则 | 原因 |
|---|---|
| 每个代码块都必须是可运行的 | 损坏的示例会摧毁信任 |
| 展示完整、可工作的示例 | 没有上下文的代码片段是无用的 |
| 在围栏代码块中包含语言标识符 | 语法高亮 |
| 在代码后展示输出/结果 | 读者验证理解 |
| 使用现实的变量名 | calculateTotalRevenue 而不是 foo |
| 在示例中包含错误处理 | 真实代码处理错误 |
| 固定依赖版本 | “适用于 React 18.2” 而不是 “React” |
| 受众信号 | 深度 |
|---|---|
| “X 入门” | 解释一切,假设没有先验知识 |
| “高级 X 模式” | 跳过基础,深入细节 |
| “X 与 Y 对比” | 假设熟悉两者,专注于差异 |
| “我们如何构建 X” | 技术受众,可以跳过基础知识 |
在开头明确说明你假设的受众水平。
# 标题(包含主要关键词,说明结果)
[主图或图表]
**TL;DR:** [2-3 句摘要,包含关键要点]
## 问题 / 为什么这很重要
[说明读者为什么应该关心——具体,而非泛泛而谈]
## 解决方案 / 我们如何做到的
[核心内容——代码、架构、解释]
### 步骤 1: [第一件事]
[解释 + 代码 + 输出]
### 步骤 2: [第二件事]
[解释 + 代码 + 输出]
## 结果
[数字、基准测试、结果——要具体]
## 权衡和限制
[诚实地说明缺点——建立信任]
## 结论
[关键要点 + 下一步做什么]
## 延伸阅读
[3-5 个相关链接]
| 类型 | 字数 | 原因 |
|---|---|---|
| 快速提示 | 500-800 | 一个概念,一个示例 |
| 教程 | 1,500-3,000 | 分步需要细节 |
| 深度解析 | 2,000-4,000 | 彻底探索 |
| 架构文章 | 2,000-3,500 | 图表承载部分内容 |
| 基准测试 | 1,500-2,500 | 数据和图表承担重任 |
将非结构化的思维转储转化为润色后的博客文章。
接受任何提供的内容:
不需要组织。混乱就是输入。
加载 references/voice-tone.md 以了解 Nick 的写作风格。
关键特征:
阅读 references/story-circle.md 以了解叙事框架。
确定内容是否符合故事结构:
将材料组织成章节:
常见结构:
开头:
正文:
技术内容:
结尾:
具有独特声音的个人博客写作。
句子结构:
具体而非抽象:
语气元素:
绝不使用:
标题风格:
开头:
正文:
回应批评者:
结尾:
糟糕: “垃圾软件并没有缺失。它正在孵化。” 优秀: “我会说这更准确地说是‘一个孵化阶段’。副作用包括大量垃圾代码、投入到理论上的超长周期——通常是教科书里的东西——只不过我们还没写出来。”
糟糕: “我每周都会遇到这些不可思议的‘顿悟’时刻。” 优秀: “我势头正猛,日夜不停地构建东西——真的,就像我不怎么睡觉了一样。”
糟糕: “不懈地实验。推动边界。试图打破东西。” 优秀: “当大家都在嘲笑 Claude 糟糕的幽默感时,我把每一次失败都看作是进步。数据就是数据。当大家都在追捧 Matt Wolfe 或 MattVidPro 谈论的工具时,我每天早上都把线抛进 GitHub 的海洋,了解社区的脉搏——你猜怎么着——有太多安静的非 YouTube 开发者以 10 倍的速度在制作工具,多到无法报道。用你的大脑,自己筛选它们。”
创建具有类别感知、AEO 优化的博客文章。
在撰写任何内容之前:
验证每一个主张:
绝不夸大:
匹配类别声音:
| 类别 | 使用时机 | 受众 |
|---|---|---|
| 技术 | 技术深度解析、架构、研究 | 开发者、工程师 |
| 公司 | 融资、合作伙伴关系、活动、招聘 | 高管、投资者 |
| 产品 | 功能发布、更新、教程 | 客户、潜在客户 |
每份草稿必须包含:
title, slug, publishedAt, category(核心)excerpt, tldr(AEO)seo.metaDescription, seo.focusKeyword(SEO)_internal.status, _internal.generated(可追溯性)| 场景 | 图表类型 |
|---|---|
| 请求流程 | 序列图 |
| 系统架构 | 方框箭头图 |
| 决策逻辑 | 流程图 |
| 数据模型 | ER 图 |
| 性能比较 | 条形图/折线图 |
| 前后对比 | 并排对比 |
对于架构图和基准测试可视化:
使用图表工具(Mermaid, Excalidraw, draw.io)绘制架构图,使用图表库(matplotlib, Chart.js)进行基准测试可视化。这些工具提供更好的控制,可以自托管,并避免第三方执行风险。
| 平台 | 格式 | 如何发布 |
|---|---|---|
| 你的博客 | 完整文章 | 主要——拥有你的内容 |
| Dev.to | 交叉发布(规范 URL 指向你的网站) | Markdown 导入 |
| Hashnode | 交叉发布(规范 URL) | Markdown 导入 |
| Hacker News | 链接提交 | 项目用 Show HN,故事用 Tell HN |
| Reddit (r/programming, r/webdev 等) | 链接或讨论 | 遵守 subreddit 规则 |
| Twitter/X | 线程摘要 + 链接 | 参见 twitter-thread-creation 技能 |
| 改编版本 + 链接 | 参见 linkedin-content 技能 |
| 错误 | 问题 | 修复方法 |
|---|---|---|
| 没有 TL;DR | 忙碌的开发者还没看到重点就离开了 | 在顶部提供 2-3 句摘要 |
| 损坏的代码示例 | 摧毁所有可信度 | 发布前测试每个代码块 |
| 没有固定版本 | 代码在 6 个月后失效 | “适用于 Node 20, React 18.2” |
| “只需做 X” | 轻视、居高临下 | 删除 “只需”、“仅仅”、“容易地” |
| 架构文章没有图表 | 用大段文字描述系统 | 一张图表 > 500 字 |
| 营销语气 | 开发者立即失去兴趣 | 直接、技术性、诚实 |
| 没有权衡部分 | 读起来像有偏见的营销 | 始终讨论缺点 |
| 内容前有冗长的介绍 | 读者跳出 | 在 2-3 段内切入主题 |
| 未固定的依赖项 | 教程对未来的读者失效 | 固定版本,注明撰写日期 |
| 没有“延伸阅读” | 死胡同,没有上下文 | 3-5 个链接以加深理解 |
references/voice-tone.md - 完整的 Nick Nisi 声音和语气指南references/story-circle.md - 故事圈叙事框架在特定声音下写作时加载参考文件:
references/voice-tone.md + references/story-circle.md每周安装次数
100
仓库
GitHub 星标数
16
首次出现
14 天前
安全审计
安装于
opencode100
gemini-cli27
github-copilot27
amp27
cline27
codex27
Comprehensive blog writing combining technical depth, personal voice transformation, and AEO optimization.
| Input Type | Use Section |
|---|---|
| Technical tutorial, deep dive, benchmark | Technical Blog Writing |
| Brain dump → polished post | Nick Nisi Voice |
| Personal voice (Jarad style) | Jarad's Voice |
| Company/product/technology category post | Lightfast Category System |
| Not sure | Start here, adapt as needed |
Write developer-focused technical blog posts.
Step-by-step instruction. Reader should build something.
Structure:
1. What we're building (with screenshot/demo)
2. Prerequisites
3. Step 1: Setup
4. Step 2: Core implementation
5. Step 3: ...
6. Complete code (GitHub link)
7. Next steps / extensions
| Rule | Why |
|---|---|
| Show the end result first | Reader knows if worth continuing |
| List prerequisites explicitly | Don't waste wrong audience time |
| Every code block should be runnable | Copy-paste-run is the test |
| Explain the "why" not just the "how" | Tutorials that explain reasoning get shared |
| Include error handling | Real code has errors |
| Link to complete code repo | Reference after tutorial |
Explains a concept, technology, or architecture decision in depth.
Structure:
1. What is [concept] and why should you care?
2. How it works (simplified mental model)
3. How it works (detailed mechanics)
4. Real-world example
5. Trade-offs and when NOT to use it
6. Further reading
Describes what went wrong, why, and what was fixed.
Structure:
1. Summary (what happened, impact, duration)
2. Timeline of events
3. Root cause analysis
4. Fix implemented
5. What we're doing to prevent recurrence
6. Lessons learned
Data-driven comparison of tools, approaches, or architectures.
Structure:
1. What we compared and why
2. Methodology (so results are reproducible)
3. Results with charts/tables
4. Analysis (what the numbers mean)
5. Recommendation (with caveats)
6. Raw data / reproducibility instructions
Explains how a system is built and why decisions were made.
Structure:
1. Problem we needed to solve
2. Constraints and requirements
3. Options considered
4. Architecture chosen (with diagram)
5. Trade-offs we accepted
6. Results and lessons
| Do | Don't |
|---|---|
| Be direct: "Use connection pooling" | "You might want to consider using..." |
| Admit trade-offs: "This adds complexity" | Pretend your solution is perfect |
| Use "we" for team decisions | "I single-handedly architected..." |
| Specific numbers: "reduced p99 from 800ms to 90ms" | "significantly improved performance" |
| Cite sources and benchmarks | Make unsourced claims |
| Acknowledge alternatives | Pretend yours is the only way |
❌ "In today's fast-paced world of technology..." (filler)
❌ "As we all know..." (if we all know, why writing it?)
❌ "Simply do X" (nothing is simple if reading a tutorial)
❌ "It's easy to..." (dismissive of reader's experience)
❌ "Obviously..." (if obvious, don't write it)
❌ Marketing language in technical content
❌ Burying the lede under 3 paragraphs of context
| Rule | Why |
|---|---|
| Every code block must be runnable | Broken examples destroy trust |
| Show complete, working examples | Snippets without context are useless |
| Include language identifier in fenced blocks | Syntax highlighting |
| Show output/result after code | Reader verifies understanding |
| Use realistic variable names | calculateTotalRevenue not foo |
| Include error handling in examples | Real code handles errors |
| Pin dependency versions | "Works with React 18.2" not "React" |
| Audience Signal | Depth |
|---|---|
| "Getting started with X" | Explain everything, assume no prior knowledge |
| "Advanced X patterns" | Skip basics, go deep on nuances |
| "X vs Y" | Assume familiarity with both, focus on differences |
| "How we built X" | Technical audience, can skip fundamentals |
State your assumed audience level explicitly at the start.
# Title (contains primary keyword, states outcome)
[Hero image or diagram]
**TL;DR:** [2-3 sentence summary with key takeaway]
## The Problem / Why This Matters
[Set up why the reader should care — specific, not generic]
## The Solution / How We Did It
[Core content — code, architecture, explanation]
### Step 1: [First thing]
[Explanation + code + output]
### Step 2: [Second thing]
[Explanation + code + output]
## Results
[Numbers, benchmarks, outcomes — be specific]
## Trade-offs and Limitations
[Honest about downsides — builds trust]
## Conclusion
[Key takeaway + what to do next]
## Further Reading
[3-5 relevant links]
| Type | Word Count | Why |
|---|---|---|
| Quick tip | 500-800 | One concept, one example |
| Tutorial | 1,500-3,000 | Step-by-step needs detail |
| Deep dive | 2,000-4,000 | Thorough exploration |
| Architecture post | 2,000-3,500 | Diagrams carry some load |
| Benchmark | 1,500-2,500 | Data and charts do heavy lifting |
Transform unstructured brain dumps into polished blog posts.
Accept whatever provided:
Don't require organization. The mess is the input.
Load references/voice-tone.md to understand Nick's writing style.
Key characteristics:
Read references/story-circle.md to understand the narrative framework.
Determine if content fits a story structure:
Structure material into sections:
Common structures:
Opening:
Body:
Technical content:
Ending:
Personal blog writing with distinctive voice.
Sentence Structure:
Concrete Over Abstract:
Tone Elements:
NEVER Use:
Header Style:
Opening:
Body:
Addressing Critics:
Closing:
Bad: "The shovelware isn't missing. It's incubating." Good: "I would say this is more accurately 'an incubation phase'. Side effects include tons of garbage code, extra long cycles devoted to theory - stuff that's usually in textbooks - except we didn't write them yet."
Bad: "I was hitting these incredible 'a-ha' moments weekly." Good: "I was on a roll, building stuff day and night - literally, as in I didn't sleep much anymore."
Bad: "Experimented relentlessly. Pushed boundaries. Tried to break things." Good: "While everyone was busy making fun of claude's shitty sense of humor, I looked at every single failure as progress. Data is data. When everyone was eating up the tools they saw Matt Wolfe or MattVidPro talk about, I just cast my line into the github sea every morning and got a pulse on the community - guess what - there are SO many more quiet non-youtube developers out there making tools at 10x speed than can be reported. Use your brain and curate them yourself."
Create category-aware, AEO-optimized blog posts.
Before writing anything:
Verify every claim:
Never oversell:
Match category voice:
| Category | Use When | Audience |
|---|---|---|
| Technology | Technical deep-dives, architecture, research | Developers, engineers |
| Company | Funding, partnerships, events, hiring | Executives, investors |
| Product | Feature launches, updates, tutorials | Customers, prospects |
Every draft MUST include:
title, slug, publishedAt, category (core)excerpt, tldr (AEO)seo.metaDescription, seo.focusKeyword (SEO)_internal.status, _internal.generated (traceability)| Scenario | Diagram Type |
|---|---|
| Request flow | Sequence diagram |
| System architecture | Box-and-arrow diagram |
| Decision logic | Flowchart |
| Data model | ER diagram |
| Performance comparison | Bar/line chart |
| Before/after | Side-by-side |
For architecture diagrams and benchmark visualizations:
Use diagramming tools (Mermaid, Excalidraw, draw.io) for architecture diagrams and charting libraries (matplotlib, Chart.js) for benchmark visualizations. These tools provide better control, are self-hosted, and avoid third-party execution risks.
| Platform | Format | How to Post |
|---|---|---|
| Your blog | Full article | Primary — own your content |
| Dev.to | Cross-post (canonical URL back to yours) | Markdown import |
| Hashnode | Cross-post (canonical URL) | Markdown import |
| Hacker News | Link submission | Show HN for projects, tell HN for stories |
| Reddit (r/programming, r/webdev, etc.) | Link or discussion | Follow subreddit rules |
| Twitter/X | Thread summary + link | See twitter-thread-creation skill |
| Adapted version + link | See linkedin-content skill |
| Mistake | Problem | Fix |
|---|---|---|
| No TL;DR | Busy devs leave before getting the point | 2-3 sentence summary at the top |
| Broken code examples | Destroys all credibility | Test every code block before publishing |
| No version pinning | Code breaks in 6 months | "Works with Node 20, React 18.2" |
| "Simply do X" | Dismissive, condescending | Remove "simply", "just", "easily" |
| No diagrams for architecture | Walls of text describing systems | One diagram > 500 words |
| Marketing tone | Developers instantly disengage | Direct, technical, honest |
| No trade-offs section | Reads as biased marketing | Always discuss downsides |
| Giant introduction before content | Readers bounce | Get to the point in 2-3 paragraphs |
| Unpinned dependencies |
references/voice-tone.md - Complete Nick Nisi voice and tone guidereferences/story-circle.md - Story Circle narrative frameworkLoad reference files when writing in specific voices:
references/voice-tone.md + references/story-circle.mdWeekly Installs
100
Repository
GitHub Stars
16
First Seen
14 days ago
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
opencode100
gemini-cli27
github-copilot27
amp27
cline27
codex27
新闻稿撰写工具:使用 inference.sh CLI 进行事实核查与专业新闻稿创作
7,700 周安装
.NET/C# 最佳实践指南:代码规范、设计模式、依赖注入与AI集成
9,300 周安装
UnoCSS 即时原子化 CSS 引擎:灵活可扩展,Tailwind CSS 超集,前端开发必备
9,200 周安装
VideoAgent AI视频生成器:文生视频/图生视频,支持7大模型一键制作短视频
9,300 周安装
Playwright MCP 测试生成工具 - 自动生成 TypeScript 端到端测试代码
9,500 周安装
Chrome DevTools 浏览器自动化与调试技能 - 网页性能分析、自动化测试工具
9,500 周安装
PostgreSQL优化助手 - JSONB操作、性能调优、窗口函数、全文搜索实战指南
9,600 周安装
| Tutorial breaks for future readers |
| Pin versions, note date written |
| No "Further Reading" | Dead end, no context | 3-5 links to deepen understanding |