Mc Zenn

Zenn

A bundled MulmoClaude preset skill (mc- prefix = launcher-managed; do not edit this file in the workspace, it is overwritten on every server boot).

Help the user share what they did in MulmoClaude as a Zenn tech article. Two jobs in one skill: (1) make sure a Zenn project exists in the workspace and (2) write an article from the work. Writing auto-runs setup first when the project isn't there yet, so the user can jump straight to "Zenn にまとめて" without thinking about setup.

Keep the machinery invisible — the user shouldn't have to think about slugs, frontmatter, or zenn-cli internals.

Where things live

The Zenn project is a git repo inside the workspace at github/zenn/ (cwd-relative — the agent runs with cwd = workspace, so every path here is plain cwd-relative). Articles are markdown files at github/zenn/articles/<slug>.md. Zenn publishes by syncing a connected GitHub repo, so this directory is a real git repo the user pushes to.

Is it initialized? The project is ready when github/zenn/articles/ exists. Use that as the idempotency marker — never re-init a directory that already has it.

Workflow 1: set up the Zenn project (idempotent)

Triggers: "Zenn のリポを用意して", "Zenn 始めたい", "set up Zenn", "まだ Zenn 作ってない". Also runs automatically as Step 0 of Workflow 2.

Step 1 — check first. If github/zenn/articles/ already exists, the project is ready: say so in one line and stop. Re-initializing is never correct. Only continue when it's missing.

Step 2 — clone or init. Ask which with one presentForm (two choices), unless the user already told you:

• Clone an existing Zenn repo (they already write Zenn on GitHub). Get the repo URL, then:

  git clone <url> github/zenn

  npx zenn fetches zenn-cli on demand, so a missing local dependency is fine.

• Create a fresh project (standard zenn-cli flow):

  mkdir -p github/zenn
  cd github/zenn && npm init --yes && npm install zenn-cli && npx zenn init

  (yarn add zenn-cli works too if the user prefers yarn.) npx zenn init scaffolds articles/, books/, and a README. Then make it a git repo:

  cd github/zenn && git init -b main

Step 3 — confirm + point at the next step. One line ("Zenn project ready at github/zenn/."). For a freshly created project, name the one manual step Zenn needs: connect the GitHub repo on zenn.dev → "Deploy from GitHub" (browser only — it can't be automated). Then offer to write the first article.

Workflow 2: write an article from MulmoClaude work

Triggers: "この作業を Zenn 記事にして", "今やったことを記事化", "Zenn に まとめて", "share this on Zenn".

Step 0 — ensure setup. If github/zenn/articles/ doesn't exist, run Workflow 1 first, then continue.

Step 1 — gather the material. Prefer what the user points at (a wiki page, an artifact, files, a MulmoScript story). Otherwise use the current session's work: the chat transcript at conversations/chat/<session-id>.jsonl (list with ls -t conversations/chat/*.jsonl | head if you don't know the id) plus the artifacts and files it produced. Pull out what / why / how / result and keep the reproducible commands and code. Ground every claim in what actually happened — don't invent.

Step 2 — pick a slug. Zenn slugs are 12–50 characters, lowercase a–z / 0–9 / - / _ (pattern ^[a-z0-9_-]{12,50}$). Build a readable kebab slug from the title's English keywords (e.g. mulmoclaude-zenn-workflow). Pad a short one with a date (date '+%Y%m%d') or 4 hex chars. Check github/zenn/articles/ for collisions. If a clean slug is hard, run cd github/zenn && npx zenn new:article to get a valid random-slug skeleton and fill it in. A published slug becomes the article URL and can't change — pick it deliberately.

Step 3 — write the frontmatter (Zenn house style):

---
title: "<a clear title, in the user's language>"
emoji: "<one emoji that fits the topic>"
type: "tech" # tech: 技術記事 / idea: アイデア
topics: ["MulmoClaude", "<related>"]
published: true
---

• Always include MulmoClaude in topics. At most 5 topics, no spaces inside a single topic.
• type defaults to tech; published defaults to true (use false when the user wants a draft). emoji is exactly one character.

Step 4 — write the body. Zenn markdown: intro (what / why) → steps or implementation (fenced ```lang blocks, runnable commands) → result → a short wrap-up. Informative but casual; describe the work, not yourself. Put images in github/zenn/images/ and reference them as ![alt](/images/<file>).

Write it the way a person would, not the way a model defaults to. Each rule below comes from real reader feedback — ignore them and the draft reads as machine output: