| name | mizchi-blog-style |
| description | Japanese-language style guide and AI-tone detection rubric for mizchi-authored blog posts (zenn / dev.to). Includes a subagent dispatch procedure that scores a draft on two axes — looks-like-mizchi vs sounds-AI-generated. Use after drafting an article during the style-matching revision loop. |
mizchi Blog Style
mizchi 個人ブログ向けの文体評価 skill。記事を書いた後、subagent に「mizchi 文体度」と「AI 臭度」を判定させて反復改善する。
詳細な文体プロファイル (5 種類の特徴的フレーズ集 + 過去記事 23 本の構成分析) は ~/ghq/github.com/mizchi/zenn/CLAUDE.md (644 行) を参照。本 skill はその要点抜粋 + AI 臭判定基準 + 評価ワークフローに集中する。
いつ使うか
- zenn / dev.to / 個人 blog の記事ドラフトを書いた直後
- AI に下書きさせた記事を mizchi 文体に寄せたいとき
- 「AI 臭い」と感じるが具体的にどこかが言語化できないとき
使わない場面:
- 業務文書 / OSS の README (公的に英語、技術リファレンス調)
- ペアプロのチャット応答 (リアルタイム会話)
mizchi 文体の核 (5 軸)
詳細は zenn/CLAUDE.md にあるが、レビュー時のチェック観点はこの 5 軸に集約できる:
- tl;dr 先出し: 記事冒頭に 3〜5 箇条の要点。結論を先に出して読者を引き込む
- 主観の明示: 「自分は経験的に」「自分が思う」「自分の結論」など、判断主体を明確化。中立を装わない
- 口語混入: 「めっちゃ」「シュッと」「だるい」「消耗した」「〜っぽい」「なんか」など、技術記事に話し言葉を混ぜる。距離を縮める効果
- 具体性とコード: 抽象論の合間に必ず具体的なコマンド / コード / 数値 / スクショ。「動きました」の事実報告
- 率直な限界開示: 「もうちょい研究が必要」「妥協の産物になった」「使う場合は自己責任で」など、できないこと・課題を明示
文末は「〜と思う」「〜だろう」「〜のはず」が多い。断定を避けつつ、主観は明確に出す。
AI 臭の典型パターン (避けるべき)
レビューでチェックする「これがあると AI 臭い」の signal:
| パターン | AI 例 | mizchi 直し方 |
|---|
| 冗長な丁寧表現 | 「〜することができます」「〜することが重要です」 | 「〜できる」「〜が大事」 |
| 空虚な強調語 | 「素晴らしい」「画期的な」「革新的な」「重要な」 | 削除、または具体性で置換 |
| 両論併記の無意味な中立 | 「〜という意見もあれば〜という見方もある」 | どっちなのか自分の立場を明示 |
| 章冒頭の前章要約 | 「前章では X について述べました。本章では...」 | 削除 |
| 一般論の締め | 「重要なのはバランスです」「適切に使い分けましょう」 | 「自分は経験的に〜」で具体的判断に置換 |
| 対称的な見出し階層 | すべての節に「概要 / メリット / デメリット / まとめ」 | 各節の長さを内容に合わせて非対称に |
| 主観の不在 | 「一般的に〜とされています」 | 「自分は〜と思っている」 |
| 過剰な箇条書き | 文章で書けることを全部 bullet | 主張は文で、列挙が必要な箇所だけ bullet |
| 結論部の繰り返し | 「以上、本記事では〜について解説しました」 | 「おわり」または最後の主張で締める |
| ハルシネーション可能な汎用例 | 「例えば、ある会社では〜という取り組みがあります」 | 自分の repo / 実コミット / 実数値で置換 |
評価ワークフロー (empirical-prompt-tuning 流用)
empirical-prompt-tuning skill のワークフローをほぼ流用するが、シナリオではなく「記事ファイル」を対象にする。
- ベースライン: 記事ドラフトを書く。
zenn/CLAUDE.md の構成パターン (技術解説 / 問題解決 / 設計方針 / 新技術評価 / アイデア提案 / 実装チュートリアル / マニフェスト / 実験報告 の 8 種) のどれに当たるかを意識
- subagent dispatch: Task tool で新規 subagent を立ち上げ、後述のテンプレで「mizchi 文体度」「AI 臭度」のレビューを依頼
- 両面評価: subagent のレポートから次を抽出
- mizchi 度 (0〜10): tl;dr / 主観 / 口語 / 具体性 / 率直さ の 5 軸を各 0〜2 点で採点、合計
- AI 臭度 (0〜10): 上の 10 パターンの該当箇所を 1 件 1 点で減点 (10 - hits、最低 0)
- 指摘箇所: subagent が「ここが mizchi っぽくない / AI 臭い」と挙げた行番号付きリスト
- 差分適用: 指摘箇所のうち合意できるものを修正。1 iter で全部潰さなくていい (関連する 3〜5 箇所まで)
- 再評価: 新規 subagent で再レビュー
- 収束判定: 「mizchi 度 ≥ 8 かつ AI 臭度 ≥ 8 が連続 2 iter」または「指摘の質が "本人しか判断できない好み" レベルになった」で停止
完璧を狙わない。8 / 10 で出すのが正解。文体は人間の判断を残す領域。
subagent dispatch テンプレ
あなたは mizchi (https://zenn.dev/mizchi) の長年の読者です。
今回、新しい記事ドラフトをレビューしてほしい。
## 対象記事
<記事ファイルのパス>
## 文体プロファイル
mizchi 文体の核を理解するため、まず次を Read してください:
- /Users/mz/.claude/skills/mizchi-blog-style/SKILL.md (本 skill 本体)
- /Users/mz/ghq/github.com/mizchi/zenn/CLAUDE.md (詳細プロファイル 644 行、特に "特徴的フレーズ集" "AI 臭の典型パターン" 節)
## レビュー観点
### A. mizchi 度 (0〜10)
次の 5 軸を各 0〜2 点で採点、合計。
1. tl;dr 先出し: 冒頭で結論を 3〜5 箇条で出している
2. 主観の明示: 「自分は」「自分が思う」等で判断主体を明確化
3. 口語混入: 「めっちゃ」「シュッと」等の口語が適度に混じる (過剰でも不足でもなく)
4. 具体性: 抽象論ばかりでなく具体コマンド / コード / 数値 / 実例がある
5. 率直な限界開示: 課題 / 失敗 / 妥協を隠さず書いている
### B. AI 臭度 (0〜10)
SKILL.md「AI 臭の典型パターン」表の 10 項目について、本文で該当する箇所を行番号 + 引用付きでリストアップ。
スコアは「10 - 該当件数」(最低 0)。
### C. 個別指摘
特に強い違和感を覚えた箇所 (mizchi っぽくない / AI 臭い) を最大 5 件、行番号 + 引用 + 改善案 で書く。
## レポート構造
- mizchi 度: X/10 (内訳 1: x, 2: x, 3: x, 4: x, 5: x)
- AI 臭度: X/10 (該当パターン: ...)
- 個別指摘 Top 5: <行番号> "<引用>" → <改善案>
- 総評: 1 段落
落とし穴
- subagent に「mizchi っぽく書き直して」と任せる: AI が AI 臭を排除しきれない。判定までで止めて、修正は人間 (または親 agent) が手で行う
- mizchi 度 10/10 を狙う: 過剰に「めっちゃ」「シュッと」を入れると逆に不自然 (パロディ化)。8 / 10 で十分
- AI 臭判定だけ追う: 主観 / 具体性 / 率直さの 3 軸を足さないと、ただの「冷たい技術文書」になる
- 同じ subagent を使い回す: 前回の指摘を学習してる、毎回新規 dispatch
- ドラフトを書く前に文体 skill を読ませる: 過剰適応する。書いた後にレビューさせる順を守る
関連
~/ghq/github.com/mizchi/zenn/CLAUDE.md — 詳細な文体プロファイル (本体)empirical-prompt-tuning — subagent dispatch + 反復改善のメタ skill (本 skill のワークフロー基盤)
