dot_claude/skills/mizchi-blog-style/SKILL.md
mizchi 名義のブログ記事 (zenn / dev.to 等) を書くとき・レビューするときの文体ガイドと AI 臭判定基準。subagent dispatch で「mizchi が書いたように見えるか」「AI 臭くないか」の両軸で評価する手順を含む。記事ドラフト作成後、文体合わせの修正イテレーションで使用。
npx skillsauth add mizchi/chezmoi-dotfiles mizchi-blog-styleInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
mizchi 個人ブログ向けの文体評価 skill。記事を書いた後、subagent に「mizchi 文体度」と「AI 臭度」を判定させて反復改善する。
詳細な文体プロファイル (5 種類の特徴的フレーズ集 + 過去記事 23 本の構成分析) は ~/ghq/github.com/mizchi/zenn/CLAUDE.md (644 行) を参照。本 skill はその要点抜粋 + AI 臭判定基準 + 評価ワークフローに集中する。
使わない場面:
詳細は zenn/CLAUDE.md にあるが、レビュー時のチェック観点はこの 5 軸に集約できる:
文末は「〜と思う」「〜だろう」「〜のはず」が多い。断定を避けつつ、主観は明確に出す。
レビューでチェックする「これがあると AI 臭い」の signal:
| パターン | AI 例 | mizchi 直し方 | |---|---|---| | 冗長な丁寧表現 | 「〜することができます」「〜することが重要です」 | 「〜できる」「〜が大事」 | | 空虚な強調語 | 「素晴らしい」「画期的な」「革新的な」「重要な」 | 削除、または具体性で置換 | | 両論併記の無意味な中立 | 「〜という意見もあれば〜という見方もある」 | どっちなのか自分の立場を明示 | | 章冒頭の前章要約 | 「前章では X について述べました。本章では...」 | 削除 | | 一般論の締め | 「重要なのはバランスです」「適切に使い分けましょう」 | 「自分は経験的に〜」で具体的判断に置換 | | 対称的な見出し階層 | すべての節に「概要 / メリット / デメリット / まとめ」 | 各節の長さを内容に合わせて非対称に | | 主観の不在 | 「一般的に〜とされています」 | 「自分は〜と思っている」 | | 過剰な箇条書き | 文章で書けることを全部 bullet | 主張は文で、列挙が必要な箇所だけ bullet | | 結論部の繰り返し | 「以上、本記事では〜について解説しました」 | 「おわり」または最後の主張で締める | | ハルシネーション可能な汎用例 | 「例えば、ある会社では〜という取り組みがあります」 | 自分の repo / 実コミット / 実数値で置換 |
empirical-prompt-tuning skill のワークフローをほぼ流用するが、シナリオではなく「記事ファイル」を対象にする。
zenn/CLAUDE.md の構成パターン (技術解説 / 問題解決 / 設計方針 / 新技術評価 / アイデア提案 / 実装チュートリアル / マニフェスト / 実験報告 の 8 種) のどれに当たるかを意識完璧を狙わない。8 / 10 で出すのが正解。文体は人間の判断を残す領域。
あなたは 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 段落
~/ghq/github.com/mizchi/zenn/CLAUDE.md — 詳細な文体プロファイル (本体)empirical-prompt-tuning — subagent dispatch + 反復改善のメタ skill (本 skill のワークフロー基盤)tools
Use when working on github.com/mizchi/pkspec, especially release readiness, version bumps, GitHub Actions/Nix release checks, adapter DSL work, or the experimental Playwright/Vitest coverage presets. Covers the repo's spec gates, pkfire release flow, pkl CLI dependency gotchas, and what is intentionally still experimental.
data-ai
指定されたリポジトリ、複数リポジトリ、または GitHub organization から、ドメイン固有の専門用語、業界用語、社内・プロダクト用語、リポジトリ実装マップ、技術構成、オンボーディング向け Mermaid 構成図を抽出・生成するときに使う。ユーザーが「用語集を作る」「ドメイン辞書を作る」「オンボーディング資料にする」「repo/org を見て専門用語をまとめる」「AI が再確認しなくてよい知識ベースを作る」と依頼したら起動する。
development
Guide for writing MoonBit bindings to JavaScript using `extern "js"`. Use when adding FFI declarations against browser/Node/Deno APIs or npm packages, wrapping JS objects behind opaque types, bridging Promises with `async fn` and `Promise::wait()`, configuring `moon.pkg` exports for esm/cjs/iife output, or handling null/undefined at the JS boundary.
testing
技術記事の再現性 (読者が手元で再現できるか) を評価するスキル。subagent に「初見の読者として手元で再現を試みる」シミュレーションをさせ、足りない情報をリストアップさせる。記事ドラフトの最終チェック、または公開後フィードバック前の事前検証で使う。