| name | article-writing |
| description | Step-by-step article writing workflow with style selection (personal voice vs serious), a hallucination-prevention fact-check gate, and AI-smell proofreading. Use when writing or co-writing blog/tech articles — triggers: 「記事を書く」「ブログ記事」「記事化して」, turning memos/logs/repos into an article, or drafting for funailog/Zenn/note. For proofreading-only requests, use the japanese-ai-writing-proofreader skill directly. |
| argument-hint | <topic or source material> |
Article Writing
Write articles in distinct phases with user checkpoints.
Never skip ahead: each phase's output is the next phase's input, and the fact-check gate exists precisely because drafting and verifying in one pass lets hallucinations through.
Phase 0: Repo conventions
If the working repo has article-related conventions (.claude/rules/, CLAUDE.md, frontmatter schemas, category/series definitions, build commands), read and follow them.
They override this skill on everything they specify — including prose style（調・一人称・締めの形式）.
The style profiles in references/ fill in only what the repo leaves unspecified (rhythm, structure, character devices).
This skill always owns the process (the phases and gates).
Phase 1: 企画 — CHECKPOINT
Confirm with the user before writing anything:
- 題材とソース: what the article is about, and what raw material exists (repo, logs, memos, URLs, receipts, chat history)
- 想定読者と媒体: who reads it, where it lands (funailog / Zenn / etc.)
- 文体: ask the user to choose
personal — キャラあり。references/style-personal.mdserious — キャラ控えめ。references/style-serious.md
- 分量の目安 and any deadline
Phase 2: 素材収集
Gather facts BEFORE outlining.
Build a 素材ノート (working notes file or message) where every fact is paired with its source:
- 引っ越しタスク総数: 103 — Todoist export, section count 9
- ICL費用: 693,000円 — 領収書 (内金330,000 + 当日363,000)
- For repos: dispatch Explore subagents; have them return claims WITH file paths and line numbers, not summaries
- For URLs: fetch and note which page supports which fact
- Numbers, model names, versions: record exact values with units
Facts not in the 素材ノート do not go in the draft.
If a section needs a fact you don't have, collect it now or mark the gap for the user.
Phase 3: 構成案 — CHECKPOINT
Present an outline for approval:
- Section list with the one key message per section
- Which 素材ノート entries feed each section
- Proposed title (+ description/frontmatter if the repo schema needs it)
Iterate here until approved.
Restructuring an outline is cheap; restructuring a draft is not.
Phase 4: 起稿
- Read the chosen style profile in
references/ — every time, not from memory
- If past articles are available (repo-local or the profile's excerpts), read 2-3 as few-shot calibration before writing
- Draft the full article following the outline
- Constraints while drafting:
- Every factual statement must trace to the 素材ノート
- Concrete numbers over adjectives; bold ≈ one key claim per section
- Follow the style profile's rhythm rules (sentence-end variety, long-short contrast) — these matter more than its surface markers
Phase 5: ファクトチェック＋公開可否 — GATE
Follow references/fact-check.md: extract every verifiable claim, verify each against a primary source, resolve all failures (fix / downgrade / delete / flag).
For articles describing personal infrastructure or accounts (自宅ネットワーク・自宅サーバ・スマートホーム), also run the disclosure sweep (§5) in that reference: scan for real identifiers (SSID・認証情報・公開IP・ホスト名・機器ブランド) and genericize or redact.
Present the claims table.
Do not proceed with unresolved items.
Phase 6: 校正
Invoke the japanese-ai-writing-proofreader skill on the draft in fix mode (the draft is Claude-written).
It runs textlint, removes AI-smell, and checks deep naturalness.
Re-read the result against the style profile: proofreading must not have flattened the chosen voice.
Phase 7: 完成レポート — CHECKPOINT
Deliver to the user:
- The final draft
- Fact-check summary (verified / fixed / downgraded / flagged counts) and the list of items needing manual confirmation (実測値、金額の公開可否など)
- Proofreading summary (what categories of fixes were applied)
- Repo-specific next steps if applicable (frontmatter
isPublished, build check, PR) — only execute these when the user asks
