| name | proofread-post |
| description | sh1ma 本人が書いたブログ記事 (このリポジトリの `src/markdown/posts/` 配下の `.md`) を校正する。誤字脱字・表記揺れ・伝わりにくい表現を指摘し、ユーザが承認したら修正する。ユーザが「校正して」「この記事チェックして」「typo 見て」「表記揺れ拾って」「この記事おかしくない?」「レビューして」「文体見て」「読みにくい所ある?」など、自分の書いた投稿の質を上げる意図で頼んできたら明示指定なしでも積極的にこのスキルを発動する。翻訳・英訳・記事の内容そのものを考える作業は範囲外 (それは他スキル・別作業に譲る)。 |
proofread-post
sh1ma 本人が書いた blog 記事を校正するスキル。
このスキルの守備範囲
- やる: 誤字脱字・助詞抜け・表記揺れ・見出し階層のミス・伝わりにくい主語省略や指示語・句読点や記号の使い方の一貫性チェック。ユーザが承認したら修正を反映する。
- やらない: 記事の内容 (何を書くか) を考える・章構成を大幅に変える・翻訳する。記事の主張や技術的正確性を評価するのも範囲外。あくまで「本人がすでに書いた文章の質を上げる」作業だけ。
sh1ma の記事は「個人的な口調・自虐・独り言」を含めた癖の塊が味なので、「らしさ」を消してしまう校正は失敗とみなす。まず references/style-rules.md を読み、守るべき癖と検出すべき揺れの両方を頭に入れてから作業する。
対象記事の見つけ方
このリポジトリ内で校正対象になる記事は次の 2 ヶ所:
src/markdown/posts/*.md — 日本語記事本体src/markdown/posts/en/*.md — 英訳記事 (このスキルの対象外。英文校正が必要なら ja-en-tech-translator スキル側で扱う)
ユーザがファイルを名指ししなかった場合、まず「どの記事?」と聞く。ファイル名や日付、タイトルの一部だけ言われた場合は src/markdown/posts/ の下から絞り込む。
作業フロー
1. 記事を読む
対象記事を全文読む。長い記事も端折らない。校正は「一箇所ずつしか見つけられない情報」の総合ゲームなので、全文が必要。
2. 「守るべき癖」を確認する
修正候補を挙げる前に、references/style-rules.md の【守るべき癖】セクションを踏まえて、この記事のトーンを掴む:
- 一人称は何か
- ですます / だ・である / 独り言のどのモードで書かれているか
- 半角/全角スペースの流儀 (バッククォート識別子の前後にスペースを入れているか等)
- 括弧は半角優勢か全角優勢か
- 数字・記号の癖
このトーンを 記事単位のベースライン として、そこから外れたところを揺れとして拾う。「全記事で統一されたスタイル」に無理やり寄せない。
3. 指摘を作る
指摘は次のカテゴリに分けて出す。ユーザが取捨選択しやすいよう、カテゴリごとにまとめて箇条書き。
- 誤字脱字・タイポ: 「起きた」→「置きた」の変換ミス、助詞抜け、単位抜け、二重助詞、余剰記号など。ほぼ確実に直すべきもの。
- 表記揺れ: 同一記事内で
Cloudflare / cloudflare、「サーバ」/「サーバー」、括弧の全角/半角、句点あり/なしの箇条書き、バッククォート前後のスペース有無、が混在しているケース。どちらに寄せるかの提案付きで出す。
- 見出し・構造の不整合: 番号見出しの
. / , ミス、H2/H3 の階層飛ばし、Front matter のクォート揺れなど。
- 伝わりにくい表現: 主語省略で誰の話か戻らないと分からない箇所、指示語 (「これ」「この」「上記」) の指す範囲が遠い箇所、前提知識の説明抜け、長すぎる一文。直すか著者の判断が要る領域。
- 判断が要るもの (要相談): sh1ma のクセに沿った表現 (例:
Github、・・・、括弧内自ツッコミ) は原則残すが、記事内で自分でも揺れている場合は寄せる方向を確認する。
各指摘には ファイルパス:行番号 と 該当箇所の該当部分の引用、推奨修正案 をつける。行番号は Read ツールで見た番号を使う。
「あってもなくてもいい直し」は挙げない。sh1ma 記事の校正で「文全体を書き直したほうが自然」と言い出すのは越権。あくまで著者の書いた形を尊重した最小変更を提案する。
4. 修正の実行はユーザ承認後
指摘一覧を出したら、そこで一度止まる。ユーザが「全部直して」「1, 3, 5 だけ直して」「これは残して」など指示してから初めて Edit で修正する。勝手に修正しない。
修正時は Edit ツールを使い、指摘した箇所ごとに 1 edit を原則とする。まとめて replace_all するのは、同じ typo が本当に全て同じ意味で修正されるべきときだけ。
5. 修正後の確認
修正が終わったら、直したファイル・箇所を短くまとめて報告する。長い diff の再掲は不要。
サブスキル・参照
