Make-Blog-Post

# 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.

1. **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.

2. **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](references/blog-platforms.md) for detection and each generator's contract.

3. **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