安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install make-blog-post
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 make-blog-post。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

Make Blog Post 是 Openclaw Skills 中的一套写作工作流程，可将当前会话中的代码、提供的代码片段或指定主题转化为主题明确的教程、文章、分步指南或 gist。每篇文章都围绕一个目的和一个通用化代码示例展开，并附上实用用法示例和预期输出。
该技能会从写作样本中学习作者风格，根据用户指示或当前博客的配置确定内容去向，并采用适合该发布渠道的 SEO 做法。它会先起草内容并提交计划供审核，之后才保存；它不会发布、上传、提交或推送内容。

应用场景

将完成的函数、脚本、类或工具整理成博客分步指南。
根据当前会话中编写或修改的代码起草文章或教程。
为专用小工具（例如重试辅助函数或 slugify 函数）创建 gist 风格的说明。
使用用户提供的链接、文件、粘贴的文字或已保存的资料，贴合作者一贯的风格。
为指定的博客仓库、本地路径、gist 或聊天准备内容，并遵循目标位置的格式和惯例。
在发布需要明确人工批准时，生成可供审核的草稿。

工作原理

选择主题： 使用用户指定的代码或主题；否则考虑本次会话中修改过的代码。如果有多个合适的候选项，最多列出三个并询问用户要讲解哪一个。确认主题适合写成有用且完整独立的文章。
确定目标位置： 按照用户指定的目标位置操作；如果当前工作区是博客，则使用其博客配置。如果两者都不适用，就在聊天中准备文章，不要擅自假设文件位置。
了解作者风格： 从用户指定的来源收集三到五篇作者样本；适当时也可从博客仓库中收集近期文章。说明匹配程度是完整、部分还是中性。
提交计划： 确认主题、目的、目标位置、风格依据、拟定的标题和 slug、SEO 级别及待解决的问题。起草前等待批准；仅在只通过聊天交付时，才可同时展示计划和草稿。
起草和修订： 展示完整文章并邀请用户修改。持续修订，直到用户明确批准；沉默或含糊的回复不构成保存许可。
安全交付： 获批后，按照目标位置的格式保存到已确认的路径，或通过聊天提供内容，或整理成适合相应发布渠道的形式。说明内容交付到了哪里。发布、上传、提交和推送都需要单独请求。

配置指南

技能说明中未指定任何软件包安装、CLI 设置或配置命令。代码准备好讲解时，调用此技能：

在编程代理对话中调用此技能：

/make-blog-post
也可以提供主题、目标位置以及写作样本或链接。例如：
/make-blog-post src/http.ts 中的重试辅助函数
/make-blog-post slugify 函数，作为 gist
/make-blog-post 将它放进博客，并参考这两篇写作样本：

交付文件前，确认拟定计划和目标位置。技能要求在写入文件前，明确批准所展示的草稿。如果目标位置属于另一个仓库，请提供其本地检出路径；技能不会克隆或远程修改仓库。

数据架构

该技能不定义数据库或持久化内容存储。只有获得批准后，它才会按照已确认目标位置所要求的格式创建文章。
内容或元数据 处理方式
文章正文 Markdown 分步指南，涵盖一个目的、通用化代码、用法示例、预期输出，以及相关限制或边界情况。
可选的独立 front matter 当目标位置读取 YAML front matter 且没有特定于站点的 schema 时，使用：title、description、slug、category、tags 和 date。
站点元数据 优先遵循站点自己的 front matter 和生成器惯例；省略不受支持的字段。
不使用 front matter 的发布渠道 将标题放在第一个标题中，将描述放在开篇句中；遵循该发布渠道特定的交付指南。
风格资料 简短的工作资料可描述称呼方式、正式程度、节奏、开篇、标题、代码说明、结尾、拼写和标点。是否保存可复用资料由用户选择，并且必须指定保存位置。
文件命名和位置 独立文件使用基于 slug 的名称，例如 slugify-text.md；博客文章遵循已配置的文章文件夹、扩展名、命名规则和 front matter。
安全规则适用于所有输出：排除凭据、私人信息和无关上下文；示例使用通用样例数据；将项目专属代码通用化；准确保留公开技术名称。

高级特性

适配作者风格：
在有样本时，根据三到五篇样本建立风格资料；如果匹配依据不足或仅为中性，会明确标注，不会声称存在缺乏依据的完整匹配。
根据目标位置调整格式：
检查当前博客生成器的配置和惯例，或将内容整理成适合聊天、gist、wiki 或用户指定的其他发布渠道的形式。
按目标位置选择 SEO 级别：
已发布的博客采用完整 SEO；普通文件或目标位置未知的聊天草稿采用轻量 SEO；gist 风格页面采用适合发布渠道的 SEO；文档集合采用内部 SEO。用户偏好和站点惯例优先。
写入文件前须获批准：
提交完整草稿供审核；未经明确批准，不会保存、发布、提交或推送；技能本身不会执行这些外部操作。
内容与隐私保护：
将标识符通用化，删除无关的实现细节，使用占位凭据和陈词滥调式样例数据，并避免复制写作样本中的内容。
控制范围：
文章聚焦于一个目的和一个完整示例，并指出不适合的主题，例如过于简单的包装器、多文件分步讲解、API 参考和发行说明。

name: make-blog-post description: 'Turn code from the current session into a blog post written in the voice of its author. Covers one function, script, class, or tool as a focused walkthrough with a generalized sample and a usage example, learns tone and structure from existing posts or writing samples by the same author, takes the destination from what the user names or the blog repository in use instead of assumed folders, and saves no file until the draft is approved. Use when asked to write, draft, or turn code into a blog post, article, tutorial, or gist, or when invoked as /make-blog-post at the end of a turn.' argument-hint: "Optional: code or topic to cover, where the post goes, and links or files of your past posts"

Make Blog Post

Turn code from the current session into a blog post that reads as if its author wrote it: one walkthrough of one function, script, class, or tool, built around a generalized sample and a usage example.

This skill runs only when the user asks for a post. The natural moment is the end of a turn, once the code works: /make-blog-post, optionally followed by what to cover, where the post goes, and links or files of the author's past posts.

When to Use This Skill

The user asks to write, draft, or turn code into a blog post, article, tutorial, walkthrough, or gist.
The user invokes /make-blog-post, with or without naming the subject, the destination, or writing samples.

Do not use it for API reference, READMEs, changelogs, or release notes, or for a post that needs several unrelated examples or a multi-file walkthrough.

Examples

/make-blog-post
/make-blog-post the retry helper in src/http.ts
/make-blog-post the slugify function, as a gist
/make-blog-post put it in the blog, match https://example.com/posts/one and https://example.com/posts/two

Workflow

Work through the steps in order. Nothing is written to disk until the draft is approved in step 5.

1. Pick the subject Use what the user named: a function, file, selection, snippet, or topic. Code pasted into the conversation is in scope too.
   Otherwise, take the code written or changed in this session. When more than one piece qualifies, list up to three, each with a one-line purpose, and ask which one to write up.
   Check that the subject works as a standalone post. It should:
   Solve one clear, general-purpose problem.
   Fit in one self-contained example.
   Not depend on project-specific state, services, or configuration that cannot be replaced with a stand-in.
   Not be trivial. A one-line wrapper or a lone standard-library call does not qualify.
   When a check fails, say which one and suggest an angle that works, such as the technique behind the code. Proceed with the original subject if the user still wants it.
2. Resolve the destination

Consider only what the user said, the current workspace, and paths the user provides. Do not assume any folder exists, and do not walk parent or sibling directories looking for one.

The user named a destination (a local path, the current workspace repository, a venue such as a gist, or "just show me"): use it, and do not move the post elsewhere because another place fits conventions better. If the user names another repository, ask for its local checkout path; do not clone or modify it remotely. A partial name such as "the blog" resolves against the current workspace only. If the workspace is not that blog, ask for the path.
The workspace is a blog or site: take the posts folder from the generator's own configuration, and match an existing post's folder, extension, file naming, and front matter. See references/blog-platforms.md for detection and each generator's contract.
Otherwise: write no file. Deliver the post in chat and offer to save it to a path the user names.

A default destination or voice profile recorded in the user's custom instructions counts as named by the user. That is the place for a personal workflow, such as a folder where every post is archived.

When writing to a named path:

Create missing subfolders under a root that exists. If the root itself does not exist, ask instead of building a tree that may be a typo.

If the path breaks the detected generator's contract (the wrong folder for the collection, a missing date prefix), state in one line what would break, offer the compatible path, and ask which to use.
If the request conflicts with the site's conventions, say so once, then follow the request. The security rules and the approval gate still apply.

3. Learn the author's voice

A post that reads like generic documentation is not the author's post. Before drafting, collect three to five samples of the author's own writing, from these sources in order:

Samples named in the request: files, folders, URLs, or pasted text.
A saved voice profile the user points to, in the request or in their custom instructions.
When step 2 resolved a blog repository, the most recent posts by this author in its posts folder.

When these sources give fewer than three samples, ask once for enough links or files to reach three, unless the user has already said there are no more. Then work with what there is:

Three or more: build the full profile.
One or two: build a thin profile from only the patterns those samples confirm, and offer the three quick questions in the reference to fill the gaps.
None: offer the three quick questions, or write in a plain, neutral voice.

A saved profile counts as the number of samples it records. Say at the plan check which case applies and how many samples the profile rests on. Never present a thin or neutral draft as a full match.

Build a short profile with references/voice-profile.md: person and address, formality, rhythm, openings, headings, how code is introduced and explained, closings, and mechanics such as spelling and punctuation habits. The samples are evidence of style only. Nothing from their content (sentences, anecdotes, names, links) goes into the new post, and no personal experience is invented to fit a pattern.

4. Check the plan

Before drafting, present these in a few lines and wait for a yes:

The subject and the single purpose the post covers.
The destination as a full path, with the config file it was resolved from when a generator was involved, or "chat only".
The voice source (which samples or profile, and how many samples it rests on) and three to five bullets summarizing it. Call a thin profile or one built from answers a partial match, and a neutral voice no match.
The working title, the slug, and the SEO level.
Any open question, when there is one, such as the real story behind a personal opening, or an existing post at the destination on the same subject (update it, take a new angle, or stop).

On a decline, stop and write nothing. When the post will be delivered in chat, no file is saved, so skip the extra round trip: put the plan at the top of the reply that carries the draft, and let one approval cover both.

5. Draft and get approval

Draft the post per Building the post, show it in full, and invite edits. Revise and show it again until the user approves. Silence or an ambiguous reply is not approval. Drafting and showing the post in the conversation needs no approval, but nothing is saved to a file, published, committed, or pushed before an explicit yes.

6. Deliver File: write to the confirmed path in the site's format, using the host's path separators and the repository's line endings. Name a standalone file after the slug (slugify-text.md), which describes what the code does, not the project. Approval was the gate, so write the post ready to publish. If the user asks for a draft instead, use the platform's draft mechanism (see references/blog-platforms.md) and name it in the report.
   Chat: follow the copy-paste rules in references/delivery.md.
   A gist, discussion, wiki page, or hosted platform the user posts to by hand: shape the post and list its field values per references/delivery.md.

Report what was written and where. Committing, pushing, uploading, or publishing is a separate action that needs its own request.

Close with up to two one-line offers:

Link the post from the docs, when the post has a published URL or a path inside this repository to point to, and the repository already documents this code. That means a README section, a docs page, or a doc comment such as a docstring or JSDoc block that explains what the code does. A plain inline comment, or one that only gives internal context, does not count, and internal-only code gets no offer. The link goes next to that documentation in one line, such as Walkthrough:
. Do not create a docs file just to hold it.
Save the voice profile, when it came from samples, with assets/voice-profile-template.md at a location the user chooses, so the next post can reuse it.

Building the post

The post explains one specific purpose of the code as an informational walkthrough. It contains:

A title naming the problem the code solves.
A short opening stating what the code does and the single use case covered.
The generalized function, method, or tool in one code block.
A minimal usage example with cliche sample data and the expected output.
A closing note on limits or edge cases, when there is something worth saying.

The implementation and its usage count as one worked example, and can share a block where the language makes that natural. A second, unrelated example, or a walkthrough that needs several files, is out of scope.

The voice profile decides how these parts are worded, ordered, and headed. It never drops a required part and never overrides the security rules.

Apply SEO at the level that fits the destination, per references/seo.md: full for a published blog, light for a plain file or a chat draft with no destination yet, venue for a gist-style page, internal for a documentation set. A level the user asks for, including none, wins. Where the site's own conventions or the author's voice clearly differ from an SEO default (title style, tagging, linking habits), the site and the author win.

Default post layout

Use this layout only where YAML front matter is read as metadata and no site defines its own fields, such as a standalone Markdown file saved at a path the user names, or a platform that accepts front matter on paste:

title:

description:
slug:
category:
tags: [, , ]
date:

A site's own front matter wins over this layout: map these values onto the fields it already uses and drop any it does not read.
A destination that does not parse front matter never gets this block. That covers a gist, a Discussions post, a wiki page, most hosted editors, and a chat draft whose target is still unknown. Use the shape in Venues with no front matter in references/delivery.md instead, which moves the title into the first heading and the description into the opening line.

Security and content rules

These rules apply to everything that goes into a post, whatever the destination or voice.

No credentials or secure data. No API keys, tokens, passwords, secrets, connection strings, private URLs, internal hostnames or IPs, account IDs, environment variable values, file paths that reveal user or machine names, or personal information beyond the public byline rule 6 allows. Replace anything the code needs with an obvious placeholder such as YOUR_API_KEY or https://api.example.com.
Cliche sample data only. For example "Hello, World!", Jane Smith, user@example.com, foo / bar / baz, 123 Main St, 42, Acme Corp. When the code needs data the list lacks, such as accented text or a date, choose something equally generic (Café, 2026-01-01), never a value from the working context.
No incidental detail from the working context or the samples. People's names other than the byline, project, client, and internal product names, business terms, internal file names, and values from the conversation stay out, and so does content from the voice samples. Code or a topic the user supplies directly is the subject rather than incidental detail: use it, generalized under rule 4 and held to rule 1.
Rewrite, don't copy. Generalize the code into a clean demonstration: rename project-specific identifiers, strip unrelated logic, and remove internal dependencies.
Paths in samples follow the sample. A PowerShell or batch sample shows Windows paths, a shell sample shows POSIX paths, and a cross-platform sample shows both or a token such as .
Public attribution and public technology keep their real names. When the destination has an author or byline field, fill it with the value the author's existing posts there use, or with the name the user gives. Never take it from elsewhere in the working context, such as git config or a system account. The full draft shows it, so approval covers it. Public languages, frameworks, libraries, and tools the code uses, such as Python, React, or SQLite, are named as they are.

Limitations

One post, one purpose, one worked example.
A full voice match needs at least three samples. With fewer, the profile is thin or neutral, and the plan check says so.
The skill writes files. It does not publish, upload, commit, or push.
HTML CSS 样式配色指南

OpenAd