zpaper-articlify

name: zpaper-articlify description: "Convert conversation context into a zpaper blog article via the zpaper-writer subagent. ONLY invoke when the user explicitly asks — NEVER proactively propose. Triggers: 'write zpaper article', 'zpaper記事', 'zpaperに書いて', 'articlify for zpaper', or /zpaper-articlify. Gathers context, creates a writing brief, delegates to the writer subagent."

Convert the current conversation into a zpaper blog article by crafting a detailed writing brief and delegating to the zpaper-writer subagent.

When $ARGUMENTS contains --conversation, the article must preserve the actual conversation as-is. This means:

NEVER summarize the conversation. Reproduce the actual dialogue flow faithfully.
Keep casual utterances. Words like 「なるほど」「ふーん」「どう思う？」「OK」

「hum...」are meaningful conversational texture — they make the article sound natural and human. Removing them makes it look AI-auto-written.
Minimal rewriting only. Typo fixes and light formatting are OK. Do NOT

restructure, condense, or rephrase the user's words beyond that.
PRESERVE THE ORIGINAL LANGUAGE. DO NOT TRANSLATE. This is critical. If the

conversation was in English, keep it in English. If it was in Japanese, keep it in Japanese. If it was mixed, keep both languages as-is. Translating the conversation to Japanese destroys the original text — it is a total loss of the source material the user wanted to preserve. The whole point of --conversation is to capture the raw dialogue, and translation defeats that purpose. The surrounding frontmatter title and any minimal scaffolding headings MAY be in Japanese, but the conversation body itself must remain in its original language.
Include the brief in the writing prompt with explicit instruction:

"This is a conversation-style article with --conversation mode. Preserve the dialogue verbatim IN THE ORIGINAL LANGUAGE. Only fix typos and apply vocabulary rules. Do NOT summarize, restructure, or translate. If the conversation is in English, the article body must remain in English."

Review the conversation history and identify:

What topic was discussed
What was tried (approaches A, B, C...)
What worked and what didn't
Key technical details, code snippets, commands
The conclusion or final approach taken
Any opinions or insights expressed
Images: Any images attached to the conversation (screenshots, diagrams, etc.)

Before crafting the writing brief, scan the gathered context for client-identifying information:

Replace client/company names with generic placeholders (acme-corp, some-client)
Anonymize project-specific file names and variable names (some-project, SomeComponent)
Remove internal URLs and staging URLs
Remove client-specific internal tool names

Exception: Takazudo's personal projects and Takazudo Modular are public — keep them as-is.

If images were provided in the conversation (attached screenshots, diagrams, etc.):

Determine the article slug from the topic (e.g., 20260209-package-json-organization)

Create the image directory in the zpaper repo:

mkdir -p $HOME/repos/w/zpaper/doc/public/img/articles/YYYYMMDD-slug/

Copy each image to that directory with a descriptive filename:

cp /path/to/source/image.png $HOME/repos/w/zpaper/doc/public/img/articles/YYYYMMDD-slug/descriptive-name.png

Record the image paths for the writing brief. The markdown reference format is:
```
![alt text](/img/articles/YYYYMMDD-slug/descriptive-name.png)
```

Create a detailed, self-contained prompt that the writer subagent can use without any conversation context. The brief must include:

Article topic: Clear one-line description
Background: Why this was done, what motivated it
Story arc: The journey (tried X, it failed because Y, then tried Z which worked)
Technical details: Specific code, commands, configurations, error messages
Key points to cover: Bullet list of must-include content
Images: If images were copied in Step 1.5, list each with its markdown path and a description of what it shows and where it should be placed in the article
Conclusion: What was the outcome, what was learned
Tone guidance: Any specific angle or framing (if applicable)
Suggested tags: Suggest tag IDs from the tag list (the writer will read the tags doc). Suggest at most 7 tags — prefer broader tags over overly specific ones. See the tag selection rules in doc/src/content/docs/overview/tags.md.

The brief must not contain any client-identifying information. All confidential details should have been purged in Step 1.3.

The brief should be written so that someone with zero context could write the full article from it alone.

Use the Agent tool to spawn the zpaper-writer subagent with run_in_background: true so the user is not blocked during writing:

Agent tool:
  subagent_type: zpaper-writer
  run_in_background: true
  prompt: [the detailed writing brief from Step 2]

The subagent will:

Read the repo's writing style guides
Write the draft article following zpaper conventions (in Japanese by default, but preserving the original language when --conversation is specified)
Set sidebar_position using the formula 999999999999 - YYYYMMDDHHMM (ensures newest articles appear first)
Save to the draft articles directory (doc/src/content/docs/articles/)
Run formatting checks
Report the file path

After the subagent completes, report:

The writing brief is the ONLY context the subagent receives - make it thorough
Include actual code snippets, error messages, and command outputs in the brief
If the conversation involved multiple topics, ask the user which one to articlify
Images must be copied BEFORE delegating - the subagent cannot see conversation images
Include the full markdown image reference paths in the brief so the subagent can embed them
$ARGUMENTS can provide additional guidance on focus or angle
The subagent writes a draft in the doc site — the conversion to blog MDX is a separate step via /convert-to-article