blog

Turn this conversation into a blog post. Follow these steps exactly: ## Consequential advice Before recommending editorial direction or related links as a consequential choice, follow the `Advice gate` in `dissenter`. When the gate applies, first say that you are using `/dissenter` and why. ## Blog location Read `external_resources.blog` and `external_resources.blog_content` from `~/.agentic/index.json` for the repository and content directory. Use those paths throughout this workflow; do not require per-repo blog-directory setup. ## Step 1: Clarify post scope Say that you are using `/clarify`'s interview discipline to narrow the post's topic, audience, and boundaries. Read and follow [`skills/productivity/clarify/SKILL.md`](../../productivity/clarify/SKILL.md) to interview the user before drafting. ### Clarify adaptation Follow clarify's **interview discipline** only: 1. Explore project context — check files, docs, recent commits 2. Scope check — if the conversation spans multiple independent threads, flag it and clarify one slice at a time 3. Ask clarifying questions — extensively, one at a time — purpose, constraints, success criteria, non-goals, audience, what "done" looks like 4. Stop when thorough — all three pillars are specific enough to act on **Do not** follow clarify's HARD-GATE or end artifact. Do not output a copy-paste prompt. Do not stop after clarify. Do not draft during this phase. Focus questions on: the single narrative thread, audience, angle, and what to include vs exclude from the conversation. ## Step 2: Summarize and gate When clarify is thorough, present a brief summary: - **Topic** — the one thing this post is about - **Include** — what belongs in the post - **Exclude** — what to leave out (even if it appeared in the conversation) - **Shape** — intended structure or angle Wait for explicit yes/no before proceeding. If the user says no, revise the summary or return to Step 1. ## Step 3: Study existing writing style Read 3-5 existing posts from the blog content directory above to learn the user's writing style. Pay attention to: - Tone (casual vs formal, use of humor, directness) - Sentence structure and length - How posts are structured (intro style, use of headings, how they conclude) - Vocabulary and voice - Use of code blocks, links, lists, and other formatting ## Step 4: Draft the post Write a blog post draft in markdown **matching the writing style you observed in Step 3** and **the scope agreed in Steps 1–2**. The post should: - Sound like the user wrote it, not an AI - Follow one narrative thread — do not dump the full conversation - Use proper markdown formatting (headings, code blocks, lists as appropriate) - Include this frontmatter at the top: ``` --- draft: "false" --- ``` ### Distill rules Structure comes from existing posts (style-adaptive), but length and completeness do not mirror the conversation. A good post tells one story — e.g. the problem, the key design choice, one concrete example — not a transcript. **Include:** - One narrative thread agreed in clarify - Core insight or story and key design decisions - At most one concrete illustration where it earns its keep **Exclude (even if in the conversation):** - Implementation minutiae (file paths, configs, exact commands, full code listings) - Side threads and tangents - Step-by-step replay of how the chat unfolded ### Ponytail review gate Say that you are using `ponytail-review` to remove over-engineered writing. After drafting, invoke `$ponytail:ponytail-review` on the post. Apply valid `delete` and `shrink` findings, then review again until it reports `Lean already. Ship.` Do not show the draft, ask the user to act, save, or publish before this gate passes. ## Step 5: Show the draft for review Present the full draft to the user. Ask: - Does the content look good? Any sections to add, remove, or rewrite? - What should the post title be? (This becomes the filename) Incorporate all feedback. Repeat this step until the user approves. ## Step 6: Save the file Save the final post to `<blog_content>/<title>.md`, using the indexed content directory and approved post title. ## Step 7: Update related links Say that you are using `/update-blog-refs` to review cross-links for the saved post. Delegate related-link handling to [`update-blog-refs`](../update-blog-refs/SKILL.md). Follow it with: - The indexed `blog_content` path as the supplied blog directory. - The newly saved post as the focus post, so proposals include only links to or from it. - Its approval gate before writing any related-link changes. ## Step 8: Publish (with confirmation) Ask the user: "Ready to publish with `node ./quartz/bootstrap-cli.mjs sync`?" Only if they confirm, run `node ./quartz/bootstrap-cli.mjs sync` from the indexed `blog` repository. If they decline, let them know the file is saved and they can publish later. After a successful publish or an intentional decision not to publish, append the `blog` completion suggestions from [skill connections](../../../docs/skill-connections.md).