القائمة
Zenn/Dev.to の記事（tech/idea 問わず全て）を書くときの既定スキル。実用軸——「読者が数秒で何かわかり、そのまま手を動かして再現できる」——を正本として保持する。低情報密度・実コード/図・即実用・低認知負荷・用途が瞬時にわかる。文体は ですます調。Zenn/Dev.to は type で声を分けない。AI-slop 禁止・タイトル誠実さ・ネタ 3 軸は writing-ecosystem に defer。genuine な思索エッセイ（だ/である × 発見調）は Substack corpus へ。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
記事公開前の全チェック（レビュー→セキュリティ→frontmatter→published_at→スケジュール→Dev.to クロスポスト→push）を順に実行する。
記事バッチの公開順序と日程を 4 軸スコアリングで決定し schedule.json に反映する。投稿タイミングの値は zenn-writing.md が正本。
Zenn 記事のタイトル・topics・emoji を Distribution レイヤーで最適化する（内容は変えない、ADR-0001）。タイトル原則・AI slop は writing-ecosystem、文字数は zenn-writing.md が正本。
Claude Code をオーケストレーター（PM）として、執筆チームを編成・指揮する
Zenn 記事の frontmatter・記法・テンプレートの正本。emoji/topics 選定、Markdown 記法、コード埋め込みのベストプラクティスを扱う。文体・執筆プロセスは扱わない（zenn-practical-writing / zenn-idea-voice を参照）。
Zenn/Dev.to 記事の任意の personality flavor。毒の効いたユーモア（AI をツッコミ対象にするシニカルな語り）と刃牙リファレンス（ドメイン置換・ダミーデータ）を保持する。type（tech/idea）問わず、話題が合えば実用記事にも layer できる。essay の基本声（だ/である × 発見調）は writing-ecosystem に defer。
| name | zenn-practical-writing |
| description | Zenn/Dev.to の記事（tech/idea 問わず全て）を書くときの既定スキル。実用軸——「読者が数秒で何かわかり、そのまま手を動かして再現できる」——を正本として保持する。低情報密度・実コード/図・即実用・低認知負荷・用途が瞬時にわかる。文体は ですます調。Zenn/Dev.to は type で声を分けない。AI-slop 禁止・タイトル誠実さ・ネタ 3 軸は writing-ecosystem に defer。genuine な思索エッセイ（だ/である × 発見調）は Substack corpus へ。 |
| user-invocable | true |
| origin | shimo4228 |
この記事で守ること: 読者が記事を開いて数秒で「これは何で、読めば自分に何ができるようになるか」がわかり、そのまま手を動かして再現できる。理解に認知リソースを使わせない。
これが Zenn/Dev.to チャンネルの既定の声。essay（思索・意見）や paper（論文）は別チャンネルに独自の声があり、それらとは意図的に文体を分ける。
| 書くもの | 使うもの |
|---|---|
| Zenn/Dev.to の記事（tech / idea 問わず全て） | このスキル（既定） |
| 学術 paper / preprint | paper-ecosystem skill |
| genuine な思索エッセイ（だ/である × 発見調） | essay corpus（Substack）へ。writing-ecosystem skill |
Zenn/Dev.to は type（tech/idea）で声を分けない — すべて実用軸（ですます・即実用）。Zenn frontmatter の type は platform 要件として残るが voice は分岐しない。毒humor/刃牙 の personality は話題が合えば任意で足せる（zenn-idea-voice）。
判定: Zenn/Dev.to に出すなら実用軸（このスキル）。だ/である で思索を綴る genuine エッセイは Substack corpus（別 channel）へ。
genre 中立の canon は writing-ecosystem skill を正本として defer（再掲しない）。essay 固有の Voice だけ override する。
| writing-ecosystem の資産 | このスキルでの扱い |
|---|---|
| AI-slop 禁止リスト（日英） | 継承（defer。実用記事でも誇張語は使わない） |
| タイトルの誠実さ・煽り禁止 | 継承（defer） |
| ネタ選定 3 軸（検索需要 / 競合 / 一次情報） | 継承（defer） |
| 自リポ言及の節度（本文 self-link は導線 or 一次資料のみ・同一 repo 1 回まで） | 継承（defer。クレジット型リンクは関連リンク節へ寄せる） |
| Voice（発見調・結論の問い化・断定→弱化・初期経典の語り口） | 上書き（実用軸では使わない。ですます調 × 直接指示。下記「文体」参照） |
| Section Length（1 節が全体の 30% を超えない） | 継承 |
ユーザーの 5 マーカーを、検証可能な具体ルールに落とす。
| マーカー | 具体ルール |
|---|---|
| 情報密度を抑えめ | 1 節 1 論点。前置き・throat-clearing を削る。短段落。密な散文より箇条書き/表。読者に再読を要求しない |
| 図や実コード | 1 記事に図/表を ≥1。コードはコピペで動く自己完結（file path + 言語タグ + input→output を必ず示す） |
| すぐ使える | task 志向。再現可能な成果物を渡す。前提（バージョン・必要物）を冒頭に列挙。手順は順序付き・欠落なし |
| 低認知負荷 | BLUF：成果物を第一画面で宣言。見出しは outcome を述べる。前方参照禁止。深掘りは :::details に progressive disclosure |
| 用途が瞬時にわかる | title + 冒頭が「これは何 / 読後に何ができるか」に答える。冒頭に「この記事で作れるもの/わかること」を 1 行 |
情報密度を下げる ≠ 内容を薄くする。 削るのは冗長・前置き・二重説明であって、技術的実質は削らない。深い記事でも、余計な認知負荷を載せなければ実用軸に乗る。「浅い記事を量産する」ことではない。
記事の軸は「読者のどの問題に効くか」。著者の体験談は素材であって軸ではない（2026-07-11 の記事再構成で確定した繰り返し修正パターン）。
判定: 最初の見出しから導入の終わりまでに「読者の問題」が登場するか確認する。体験談が導入・独立節として置かれていたら、対応する論点の中へ圧縮移動できないか検討する。
見出し・地の文に専門用語（造語・業界ジャーゴン）を置くときは、以下から状況に合うものを選ぶ。1 記事で複数を組み合わせてよい。
判定: 記事完成後、専門用語をリストアップし、各語の初出箇所を確認する。説明なしで見出しにだけ登場する語がないかを機械的にチェックする（reader-first-article-review の用語前方集約チェックと同一観点）。
「短段落」という原則だけでは自己レビュー時に見逃される（原則は知っていても、書いている最中は密度を自覚しにくい）。以下の閾値を機械的にチェックする。
判定: 記事完成後、各段落を上から数え、5行超・3ビート以上・比較の地の文埋め込みのいずれかに該当する段落がないか通し読みで確認する。
実用記事は ですます調で書く。 essay（writing-ecosystem）の だ/である × 発見調 とは文体レベルで分ける。ですます調は読者との距離が近く、「教わってすぐ試す」実用軸に合う。
さらに essay が「〜ではないか」と問い化するのに対し、実用 how-to は直接指示で言い切る。
| essay（writing-ecosystem） | 実用（このスキル） | |
|---|---|---|
| 文体 | だ/である | ですます |
| 語り | 発見調（〜だった、〜に見えた） | 直接指示（〜します、〜してください） |
| 結論 | 問い化（〜ではないか） | 言い切り（〜になります、〜できます） |
| 例 | 「〜と読める」 | 「まず X します」「Y を実行します」 |
writing-ecosystem の Title Conventions と禁止リストは実用記事でも守るZenn/Dev.to 実用記事は Diátaxis の how-to（課題達成） と reference（逆引き） 象限。
writing-ecosystem / Substack へ# タイトル（成果物 or 解く課題が一目でわかる）
> **この記事で作れるもの/わかること**: [1 行]
## 前提
- [バージョン・必要なアカウント・前提知識]
## [手順 or 逆引き見出し（outcome を述べる）]
（実コード：コピペで動く。file path + 言語タグ）
（input → output を示す）
## 落とし穴 / Tips
:::details ハマったら
[progressive disclosure。本筋を膨らませない]
:::
## まとめ（次にできること）
## 関連リンク（本文で著者自身のリポジトリ/ツールに言及した場合）
[記事内で紹介した外部リポジトリ・ツールの URL を再掲。最後まで読んだ読者は導入意欲が高い。**紹介 repo が1つでも、著者の GitHub ハブ（プロフィール/一覧 repo）への導線を必ず含める**——ハブは読者を著者の全リポジトリへ送るので、言及 repo の数に依らず付ける。具体的なハブ URL はユーザー固有の設定なので、この skill には書かず**プロジェクト側の規約（例: CLAUDE.md）で指定する**]
形式・記法・frontmatter・emoji・topics の詳細は zenn-format が正本。
記事の執筆は Claude Code 本体が直接行う。専用の執筆エージェントには委譲しない。
上記の「実用軸の 5 ルール」「文体」に従って直接執筆する。
writing-ecosystem の禁止リスト）実用記事は具体素材が命。書き始める前に:
drafts/article-context_<topic>-<date>.md に企画・タイムライン・技術コンテキスト・差別化・リサーチ要点をまとめてから執筆AI 対話などの生ログは articles/_context/{slug}-{source}-log.md に退避する（Zenn の同期対象外。詳細は .claude/rules/zenn-writing.md）。
公開前に機械的に確認できる項目。quality-gate skill がこれを gate する。
writing-ecosystem の禁止リスト）writing-ecosystem の自リポ言及の節度）writing-ecosystem の領分（実用記事は ですます調）~/.claude/skills/writing-ecosystem/SKILL.md（global）— genre 中立 canon（AI-slop / タイトル / ネタ 3 軸）の正本 + essay 声.claude/rules/zenn-writing.md — Zenn プラットフォーム固有ルール（frontmatter 上限・:::message・投稿ペース）docs/adr/0003-*.md（channel 軸 + genre-split）