agentleFS
h-watah-wata/claude-skills/skills/zenn-interview/SKILL.md

zenn-interview

Skill0 starsChanged 6 months agoApache-2.0View on GitHub

取材駆動でZenn記事を書くスキル。ユーザーが「記事を書きたい」「Zennにまとめたい」「開発したものを記事化したい」「ブログ書いて」と言ったとき、あるいはリポジトリやプロジェクトの成果を発信したい文脈では必ずこのスキルを使う。いきなり本文を書かず、インタビューで素材を集め、中心メッセージとアウトラインの承認を得てから執筆する。技術記事・体験記・解説記事すべてが対象。

The file

Files
SKILL.md

zenn-interview: 取材駆動の記事執筆

このスキルの目的

AIが自律で記事を書くと、リポジトリの均質な要約(機能ツアー)になり、メッセージがぶれ、実体験のない無機質な長文になる。原因は「人間からしか出ない素材」を集めずに書き始めること。

このスキルは執筆の前に取材フェーズと停止ゲートを強制することで、これを構造的に防ぐ。

絶対ルール: 承認済みアウトラインなしで本文を書き始めてはならない。

全体フロー

1. 取材フェーズ    → materials.md に素材を溜める
2. 停止ゲート      → 中心メッセージ1文 + アウトラインを提示して停止。承認を待つ
3. 執筆フェーズ    → セクション単位で執筆。素材にないことは書かない
4. セルフチェック  → チェックリストで検査してから提出

1. 取材フェーズ

進め方

  • 質問は1回に1つ。ユーザーは音声入力(whisper.cpp)で答えることが多い。長い質問リストを一括で投げない
  • 音声入力の誤変換は文脈から推測して確認する
  • 回答が抽象的だったら掘り直す:「具体的にいつ、何が起きた?」「そのとき画面/ログには何が出てた?」
  • 「特にない」と言われたら別の角度から聞く。それでもなければ諦めてよい
  • 回答は逐次 materials.md に素材IDつきで記録する(下記フォーマット)

質問バンク

必ず全部聞く必要はない。記事の種類に合わせて選ぶが、M1(中心メッセージ)と失敗談・数字は必須。

ID質問狙い
M1この記事を読んだ人が1つだけ覚えて帰るとしたら何?中心メッセージ
M2誰に読んでほしい?その人は今どう困ってる?読者設定
F1開発中に一番イラッとした/詰まった瞬間は?いつ、何が起きた?失敗談(記事の血肉)
F2検討して捨てた案は?なぜ捨てた?意思決定の痕跡(ADR的素材)
F3予想と違ったこと、意外だったことは?発見
N1数字で言えることは?(時間、トークン、行数、回数、金額)具体性
N2ビフォーアフターで何がどれだけ変わった?結果
S1実際のログ、エラーメッセージ、スクショで見せられるものは?一次資料
S2ADRや設計メモ、issueに残っている記録は?既存素材の回収

ADRやdocs/がリポジトリにある場合は、質問の前に読んでおき「ADRにこう書いてあるけど、このときの背景をもう少し聞かせて」と使う。

materials.md フォーマット

# 素材: <記事仮タイトル>

## M1 中心メッセージ候補
- (ユーザーの言葉のまま)

## F1 失敗談
- [f1-1] verify gateを入れる前、Workerが「全部通りました」と報告してきたが実際は…
- [f1-2] …

## N1 数字
- [n1-1] Dispatcherのコンテキスト消費が◯◯から◯◯に

素材IDは執筆フェーズで引用するために付ける。ユーザーの言い回しはなるべく原文のまま残す。要約して漂白しない。

2. 停止ゲート

取材が済んだら以下を提示して必ず停止し、承認を待つ:

  1. 中心メッセージ(1文): 記事全体がこの1文を支える。支えない要素は削除候補として明示する
  2. タイトル案 2〜3個: 中心メッセージが透けるもの。「〜してみた」は体験記で結果の数字がある場合のみ
  3. アウトライン: 各セクションについて
    • 見出し(主張が入った見出し。「概要」「まとめ」のような無内容見出し禁止)
    • そのセクションの主張1文
    • 使う素材ID
  4. 削った素材のリスト: 「これは中心メッセージを支えないので落とした。別記事候補」と明示

ユーザーの修正を反映して再提示。明示的なOKが出るまで本文を書かない。 アウトラインへの指摘は安く、本文への指摘は高くつく。ここで直し切る。

3. 執筆フェーズ

進め方

  • 承認済みアウトラインに沿ってセクション単位で出す。一気に全文を出さない(レビュー不能になる)
  • 各セクションの冒頭コメントに使用素材IDを書く(最終稿では削除): <!-- 素材: f1-1, n1-1 -->
  • 素材にない体験・数字・感想を捏造しない。足りなければ <!-- TODO: ここに実際の数字が欲しい --> と書いてユーザーに聞く
  • 1文1行で改行する(gitでのdiffレビューを楽にするため)

文体ルール

  • 結論ファースト。セクションも記事全体も、最初に主張、あとから理由
  • カジュアルな日本語。「です・ます」基調だが硬くしない
  • 本文に絵文字を使わない
  • 短いフレーズ。一文を長くしない
  • 抽象論より具体例。コード、ログ、数字を優先

AIっぽさ回避ルール

  • セクションの長さを揃えない。重要なセクションは長く、つなぎは短く
  • 「課題→対策」「〜という問題がありました。そこで〜」の同一リズムを3回以上連続させない
  • 箇条書きの乱用禁止。話の流れがあるところは文章で書く
  • 「いかがでしたか」「ぜひ試してみてください」系の定型締め禁止。まとめは中心メッセージの再提示1〜3文で終える
  • すべての選択肢を公平に並べる書き方をしない。書き手の判断と理由を書く

4. セルフチェック

提出前に確認し、結果をユーザーに報告する:

  • 中心メッセージを支えないセクションはないか
  • 失敗談か数字が最低1つ、具体的な形(いつ・何が起きた)で入っているか
  • 素材にない記述(捏造)がないか。TODOが残っていないか
  • 見出しだけ読んで記事の主張が追えるか
  • セクションの長さ・リズムが均質になっていないか
  • 定型締め・絵文字・水増しまとめがないか

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.