Menu
日本語の技術文書を書いた後・公開前にレビューし、重要度つきの指摘レポートを出すスキル（ファイルは変更しない）。日本語の文章品質・AI Slop・表記の慣習・整合性・独自性・語り口を点検する。媒体非依存の汎用版で、ブログMDXなどプロジェクト固有のレビュースキルがあればそちらを優先・併用する。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
cmuxターミナル内での操作スキル。CMUX_*環境変数が存在する場合、cmuxのCLIコマンドを使う前に必ずこのスキルを読む。ペイン分割、コマンド送信、ブラウザ自動化、通知、Markdown/diffのプレビュー、cmux設定の変更など、cmux操作全般で使用する。「別ペインで開いて」「横に表示して」「ブラウザで確認して」「プレビューして」「diffを見せて」などのときにも使用する。
Preview generated Markdown (plans, design notes, reviews, research reports) in the user's browser. Use when sharing long, structured output — documents with headings, tables, code blocks, or Mermaid diagrams — that is hard to read in the terminal.
バグを場当たり修正せず、根本原因を特定してから直すためのデバッグ手順。再現→切り分け→根本原因→検証の順で進める。バグ・デバッグ・原因不明・落ちる・再現しない・CIが赤・flakyなテスト・想定外の挙動に遭遇したときに使用する。「デバッグして」「なぜ落ちる」「原因を調べて」などのときにも使用する。
「完了」「直した」と報告する前に、実際に実行・テスト・観察して根拠を確かめるための検証ルール。修正・実装・リファクタが終わって成功を報告しようとするとき、変更が意図どおり動くと主張する前に使用する。「できた」「直した」「実装した」「修正完了」と言おうとしているときに使用する。
新しい k8o プロジェクト/リポジトリを立ち上げる一連の手順。@k8o/create で雛形生成 → GitHub リポジトリ作成 → ブランチ保護 ruleset とマージ設定 → リリース用 secret(fnox経由) → npm 初回 publish と Renovate 有効化まで。「新しい repo を作る」「プロジェクトを立ち上げる」「リポジトリの初期設定をする」ときに使用する。
Conventional Commitsに従ったアトミックなgitコミットを作成する。変更を論理単位に分割し、独立してrevert可能なコミットを生成する。コードの変更をコミットしたいとき、コミットメッセージを作りたいときに使用する。
| name | writing-review |
| description | 日本語の技術文書を書いた後・公開前にレビューし、重要度つきの指摘レポートを出すスキル（ファイルは変更しない）。日本語の文章品質・AI Slop・表記の慣習・整合性・独自性・語り口を点検する。媒体非依存の汎用版で、ブログMDXなどプロジェクト固有のレビュースキルがあればそちらを優先・併用する。 |
日本語の技術文書全般（README・ドキュメント・スキル文書・PR説明・記事・スライドなど）の文章品質をレビューする観点とワークフロー。プロジェクトや媒体を問わず使える汎用スキルで、結果は重要度つきの指摘レポートとして出す。
プロジェクト固有のレビュースキル（例: ブログMDX用の
/blog-review）があれば、媒体固有チェックはそちらに任せ、本スキルはどの文書にも共通する文章面を見る。
行うこと: 日本語文章ルール／AI Slop・LLMっぽい言い回し／表記の慣習／整合性・流れ／独自性・価値／語り口・演出を点検し、重要度つきの指摘と修正提案をレポートする。
行わないこと: ファイルの自動修正（レポートのみ）／執筆・アウトライン作成／コード・設定の技術的な正しさ（文章面に限る。コードの動作は別途確認）。
修正依頼の場合でも、まずレポートを出し、どの指摘を直すか合意してから着手する。ファイルは変更しない。
**）** は一般の文書では使ってよい（強調・初出用語など要所に絞る）。観点2で弾くのは「AI的な機械的な太字」だけ。媒体によっては太字なしの方針もある（その場合はその規約に従う）。...）は日本語ルールの対象外（コメントや注釈テキストは日本語として読む）。機械検出できる項目はコマンドで先に洗い出す。対象のパスをFILEに入れて実行（ripgrep / awk）。
コード除外: (1)〜(4)は文書全体に当たるため、コードフェンス内・インラインコード（
...）内・注釈（[!callout:]等）内も拾う。マッチがコード内なら違反ではないので除外して判断する。コードが多い文書では下のPROSE（フェンス除外済み本文）に当てると誤検出が減る（ただし行番号は本文内通し番号になる）。
FILE='path/to/doc.md'
PROSE=$(awk '/^[[:space:]]*```/{f=!f;next} !f' "$FILE") # フェンス内を除いた本文
# (1) AI的な太字の候補（中身のない強調・ラベル型。一般文書では正当な太字も拾う）
rg -n '\*\*[^*]+\*\*' "$FILE"
# (2) ラベル型リスト（- **ラベル**: …）
rg -n '^\s*[-*+]\s+\*\*[^*]+\*\*\s*[:：]' "$FILE"
# (3) 英語(英数字)と日本語の間のスペース
rg -n '[A-Za-z0-9] [ぁ-んァ-ヶー一-龥]|[ぁ-んァ-ヶー一-龥] [A-Za-z0-9]' "$FILE"
# (4) 全角英数・emダッシュ・語並列の中黒（固有名詞内の中黒は目視除外）
rg -n '[Ａ-Ｚａ-ｚ０-９]|──|—|[ぁ-ん一-龥]・[ぁ-ん一-龥]' "$FILE"
# 観点1の客観ルール（数えれば判定できるもの。PROSE=本文のみに当てる）
# (5) 読点が4つ以上の一文（観点1: 読点は最大3）
printf '%s' "$PROSE" | awk 'BEGIN{RS="。"} {n=gsub(/、/,"&"); if(n>=4) printf "読点%d: %s。\n", n, $0}'
# (6) 漢字が7文字以上連続（観点1: 連続漢字は最大6）
printf '%s' "$PROSE" | rg -n '[一-龥]{7,}'
# (7) 文体混在の手がかり（両方とも1以上なら です/ます と である/だ の混在の可能性。だ。は誤検出あり）
printf '%s' "$PROSE" | rg -c '(です|ます)。'; printf '%s' "$PROSE" | rg -c '(である|だ)。'
出力ゼロなら基本OK。(5)(6)はそのまま要修正候補、(7)は両方ヒットしたら該当文を目視で確認する。
各観点の見出し＋見るところ。詳細カタログは references/ に置く。
文体統一・文末句点・読点数・連続漢字・ら抜き・冗長表現・ひらがな化・表記ゆれ・誤用など。客観ルール（読点数・連続漢字・文体混在）は上のコマンドで先に数える。全ルールとNG→OK例は references/japanese-rules.md。
一次担当=語句レベル（一文単体で判定できる定型表現）。中身のない太字・ラベル型リスト・誇張表現・「重要なのは〜である」式の予告・空虚な形容/動詞など。一覧とNG→OK例、定型句リストは references/ai-slop.md。
| 観点 | 内容 |
|---|---|
| 英日スペース | 英語（英数字）と日本語の間にスペースを入れない（コマンド3で検出。コード内は除外） |
| 半角/全角 | 数字・英字・記号は半角に統一 |
| ダッシュ・中黒 | emダッシュ・2倍ダッシュ（──）を地の文・見出しで使わない。日本語の語の並列に中黒「・」を使わない（「、」「と」でつなぐ。固有名詞内部は可） |
| 用語の定義 | 用語と説明は全角コロン（用語：説明）で書く |
| インラインコード | API名・プロパティ名・コード断片はバッククォートでインラインコード化する |
例（英日スペースなし）: Baseline 2026で揃いました / React のフックではなくReactのフック。
一次担当=論理構造の破綻。通しで読み、段落・節・文書全体のレベルで見る（読者が実際につまずく箇所に絞る）。
| 観点 | 見るところ |
|---|---|
| 論理の飛躍・矛盾 | 根拠なく結論へ飛んでいないか。前半と後半で主張が食い違っていないか |
| 段落・文のつなぎ | 接続詞が論理関係と合っているか（「しかし」なのに逆接でない 等） |
| 説明の順序 | 前提→本論→応用の順か。定義する前に用語を使っていないか |
| 重複・冗長 | 同じ内容を別の場所で繰り返していないか。読者が自力で補える中間段階を書きすぎていないか。重要度=理解を進める繰り返しなら任意、二度同じ理解をさせるなら推奨 |
| 見出しの中身 | 節が答える問い・扱う対象を表す具体的な句か。情報量ゼロ（「例に戻す」等）や、結論を言い切る「オチ」でないか。二要素を詰め込まず単一の句か（「はじめに/おわりに」など慣例見出しは許容） |
| 指示語・主述のねじれ | 「これ・それ」が指すものが明確か。主語と述語が対応しているか。読点3つ以内でも引用・条件・結論を1文に詰めて60〜80字超で主述が遠いものは分割を提案 |
| 導入と結論の回収 | 冒頭で示した問い・目的が本文と結びで回収されているか |
| 初出の用語 | 専門用語が説明・リンクなしに突然出てこないか |
| 論証の厳密さ | 推量・可能性を根拠なく断定に変えていないか。別々の決定・原因を「同じ」とまとめていないか。因果は機構（なぜそうなるか）を示しているか。「必ず」でなく条件付き（「〜しやすい」）で述べているか。確認していないことを確認したように書いていないか（事実整合） |
| 伏線の回収 | 「次節で扱う」とした論点を本当に回収しているか。逆接で終えて放置していないか |
公開する読み物向け。公式ドキュメントや既存記事の焼き直しで終わっていないか。
一次担当=文書を通した語りの一貫性・修辞の量（複数箇所の総量で判定）。
[テキスト]()）が無いか。外部リンクは到達性を確認（任意で curl -sI <url> | head -1）。ファイルは変更せず、重要度ごとに整理したレポートを出す。各指摘に「場所（file:line）・該当箇所・なぜ問題か・修正提案」を含める。
## 文章レビュー: <ファイル名>
### 🔴 要修正
- `doc.md:88` 文体混在（ですます/である）→「〜です」に統一 ［該当: 「…注意すべきである。」］
- `doc.md` 全体 焼き直しで独自要素ゼロ（検証・比較・落とし穴なし＝足切り該当）→ 著者の検証・使い分けを足す
### 🟡 推奨
- `doc.md:30-46` 「基本構文」より先に応用が来て理解順が逆 → 節を入れ替える
- `doc.md:15` 「React の」→「Reactの」（英日スペース）
- `doc.md:50` 「正面から扱う」→ 何をどう書くかを具体的に
### 🟢 任意
- `doc.md:60` 同じ説明が前節と重複（言い回し違いの補強）→ どちらかに寄せる
### 指摘なしの観点
- 観点1 日本語ルール / 観点3 表記: OK
- 観点2 AI Slop: 検出なし
- 観点4 整合性・流れ: 問題なし
重要度の天井: