菜单
sh1ma 本人が書いたブログ記事 (このリポジトリの `src/markdown/posts/` 配下の `.md`) を校正する。誤字脱字・表記揺れ・伝わりにくい表現を指摘し、ユーザが承認したら修正する。ユーザが「校正して」「この記事チェックして」「typo 見て」「表記揺れ拾って」「この記事おかしくない?」「レビューして」「文体見て」「読みにくい所ある?」など、自分の書いた投稿の質を上げる意図で頼んできたら明示指定なしでも積極的にこのスキルを発動する。翻訳・英訳・記事の内容そのものを考える作業は範囲外 (それは他スキル・別作業に譲る)。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
このブログ (`sh1ma/blog`) の新規記事のボイラープレート (`src/markdown/posts/YYYYMMDD_N_slug.md`) を生成する。ユーザが「新しい記事を書きたい」「記事のテンプレを作って」「新規ポスト」「post 作って」「記事のボイラープレート」「今日の記事書き始めたい」などと言ったら明示的なスキル指定がなくても発動する。日付プレフィックスと同日内の連番 N を自動で付与し、`title` / `publishedAt` / `description` / `tags` の frontmatter 雛形を書き出す。
このブログ (`sh1ma/blog`) を本番環境 (blog.sh1ma.dev) にデプロイするための本番PRを起動する。「デプロイして」「本番出して」「本番にあげて」「リリースして」「リリースする」「production PR 作って」など、本番反映を意図した依頼で必ず発動する。staging は main への push で自動デプロイされるためこのスキルの対象外。
日本語の技術記事を、英語圏の技術読者向けに自然で正確な英語へ翻訳・編集する。技術ブログ、エンジニアリングノート、README、ドキュメント草稿、個人技術エッセイ、Issue/PR 説明、リリースノート、調査記録などを対象にする。ユーザーが「英訳して」「英語版を作って」「英語記事に翻訳」「自然な英語に直して」「translationese を減らして」「polish this English」「英語版として完成させて」「review this translation」など、日本語→英語の技術翻訳・編集や、既存英訳のレビューを求めたときは、明示的なスキル指定がなくても積極的にこのスキルを使うこと。単なる用語辞書引きや一文レベルの翻訳ではなく、記事レベルの翻訳・書き直し・レビューが必要な場合に発動する。
GitHubのPR（プルリクエスト）を管理する。PR作成、一覧、マージ、レビュー、コメント確認時に使用。「PRを作りたい」「マージして」「レビューして」「コメントを確認」などのキーワードで発動。
GitHub CLI (`gh`) を使ってこのリポジトリ (`sh1ma/blog`) を操作する。サブスキルへディスパッチする。
| name | proofread-post |
| description | sh1ma 本人が書いたブログ記事 (このリポジトリの `src/markdown/posts/` 配下の `.md`) を校正する。誤字脱字・表記揺れ・伝わりにくい表現を指摘し、ユーザが承認したら修正する。ユーザが「校正して」「この記事チェックして」「typo 見て」「表記揺れ拾って」「この記事おかしくない?」「レビューして」「文体見て」「読みにくい所ある?」など、自分の書いた投稿の質を上げる意図で頼んできたら明示指定なしでも積極的にこのスキルを発動する。翻訳・英訳・記事の内容そのものを考える作業は範囲外 (それは他スキル・別作業に譲る)。 |
sh1ma 本人が書いた blog 記事を校正するスキル。
sh1ma の記事は「個人的な口調・自虐・独り言」を含めた癖の塊が味なので、「らしさ」を消してしまう校正は失敗とみなす。まず references/style-rules.md を読み、守るべき癖と検出すべき揺れの両方を頭に入れてから作業する。
このリポジトリ内で校正対象になる記事は次の 2 ヶ所:
src/markdown/posts/*.md — 日本語記事本体src/markdown/posts/en/*.md — 英訳記事 (このスキルの対象外。英文校正が必要なら ja-en-tech-translator スキル側で扱う)ユーザがファイルを名指ししなかった場合、まず「どの記事?」と聞く。ファイル名や日付、タイトルの一部だけ言われた場合は src/markdown/posts/ の下から絞り込む。
対象記事を全文読む。長い記事も端折らない。校正は「一箇所ずつしか見つけられない情報」の総合ゲームなので、全文が必要。
修正候補を挙げる前に、references/style-rules.md の【守るべき癖】セクションを踏まえて、この記事のトーンを掴む:
このトーンを 記事単位のベースライン として、そこから外れたところを揺れとして拾う。「全記事で統一されたスタイル」に無理やり寄せない。
指摘は次のカテゴリに分けて出す。ユーザが取捨選択しやすいよう、カテゴリごとにまとめて箇条書き。
Cloudflare / cloudflare、「サーバ」/「サーバー」、括弧の全角/半角、句点あり/なしの箇条書き、バッククォート前後のスペース有無、が混在しているケース。どちらに寄せるかの提案付きで出す。. / , ミス、H2/H3 の階層飛ばし、Front matter のクォート揺れなど。Github、・・・、括弧内自ツッコミ) は原則残すが、記事内で自分でも揺れている場合は寄せる方向を確認する。各指摘には ファイルパス:行番号 と 該当箇所の該当部分の引用、推奨修正案 をつける。行番号は Read ツールで見た番号を使う。
「あってもなくてもいい直し」は挙げない。sh1ma 記事の校正で「文全体を書き直したほうが自然」と言い出すのは越権。あくまで著者の書いた形を尊重した最小変更を提案する。
指摘一覧を出したら、そこで一度止まる。ユーザが「全部直して」「1, 3, 5 だけ直して」「これは残して」など指示してから初めて Edit で修正する。勝手に修正しない。
修正時は Edit ツールを使い、指摘した箇所ごとに 1 edit を原則とする。まとめて replace_all するのは、同じ typo が本当に全て同じ意味で修正されるべきときだけ。
修正が終わったら、直したファイル・箇所を短くまとめて報告する。長い diff の再掲は不要。