文章スキルの作り方

• スキル＝Claude Codeに読ませる「指示書（SKILL.md）」＋「参照データ（catalogフォルダ）」のセット。プログラミングは不要で、中身は全部日本語の文章です
• この資料は「何を・どの順で・どんな情報を集めて作るか」だけを書いています。判断軸データの中身（誰がどう直したか）は社内限定のため載せていません
• 全部やる必要はありません。「6. 最初の1週間」だけで動くものはできます。残りは精度を上げる工程です

スキル作りで一番の失敗は「作り方」から入ることです。先にこの3つを1行ずつ書いてください（大ちゃんさんの「スキルの育て方」の型）。

「判断軸」＝責任者が原稿を直すときの理由。「絵文字が多い」のような表面ではなく、「この企画の案内なら背景の見出しが要る」のような構成レベルの理由まで掘ります。

過去に一度失敗した方法：コメント30件をAIに読ませて「FBスキルを作って」→ 語尾や絵文字の指摘はできたが、構成レベルの指摘ができず実用化断念。

1. 実例から掘る：コメントを「どの箇所に・何を・なぜ」で1件ずつ整理する。⚠️コメントの位置情報（アンカー）は当てにならない。必ず本文全文と突き合わせて、実際に何が直ったかを見る
2. 本人の記憶から掘る：責任者が普段使っているChatGPT等に「あなたが文章を直すときの判断基準を全部出して」というプロンプトを渡し、出力を貼ってもらう
   • 本人の作業は「貼る→『続けて』→結果をドキュメントに貼る」だけ。○×の添削や質問回答は求めない（負荷が上がると回収できない）
   • 深掘りの観点：直す理由／優先順位と衝突したときのルール／例外と境界線／即差し戻しの条件／黙って直すもの／「良い」の定義
3. 突合してタグを付ける：実例と本人出力が一致＝【確定】／実例のみ＝【実例】／本人出力のみ＝【GPT】。このタグが後でAIの指摘の強さになります（確定・実例＝直すべき、GPT＝提案どまり）

AIが参照するデータを4種類に分けて書きます。分ける理由は、後で違和感が出たときに「どこを直せばいいか」が一発で分かるようにするためです。

スキルは2本に分けました。1本にまとめると使い分けができません。

指示書に入れる要素（順番どおり）

1. 参照ファイルと読む順番（判断軸→型→表層）
2. 案件の判定を先にやらせる：媒体・種類・段階・想定読者。ここを飛ばすと依頼文の項目順に並べただけの原稿が出ます
3. 型の当てはめ度合いの判定：型どおり／型＋調整／型なし。型なしでも文章の形で出す（構成案だけ返すと結局人が書くことになる）
4. チェックの手順を上から順に（誰向けか→何の話か→何をすればいいか→構成→過不足→誇張→事実→トーン→導線）
5. 禁止事項：カタログにない判断で指摘しない／依頼文にない事実を作らない／利用者の環境でファイルを書き換えない
6. 止まる条件：「読者が困るか」で判定。より良くできる＝直すべき、ではない
7. 推測した箇所は明示させる（「⚠️推測」を付ける）。ライターが全文を疑わず、直す箇所だけ見れば済むように

• ZIPで配布するのが確実です。中に install.sh（コピーするだけの短いスクリプト）を入れ、「Claude Codeに『この中のinstall.shを実行して』と伝える」で導入完了
• GitHubのトークン入りコマンドは、Claude Codeが認証情報を含むコマンドを拒否することがあり失敗しました
• 使い方の資料は1ページのWebページにすると共有しやすいです（例：ライティングAIスキル 全体像）
• 呼び出しは「/」から始まるコマンド名で。似た名前の社内スキルと混ざります

配って終わりではなく、使った人の違和感が自動で溜まり、責任者がOKを出したものだけスキルに入る流れを作ります。

使う人：出力の最後に「手直しした箇所は？
　　　　①表現 ②構成 ③トーン ④過不足 ⑤反映漏れ ⑥その他 ⑦なし」
　　　→ 番号を返す → AIが「修正前／修正後／理由」を聞く
　　　→ AIがGoogleフォームに送信

責任者：スプレッドシートを週1で見て、反映案に「OK」とだけ書く
　　　　（違うときだけ一言）

管理者：OKの分だけカタログに反映 → 更新版ZIPを配る

設計のポイント

• 使う人の負担は番号1つ。「FBください」と毎回催促しない（使われなくなる最短ルート）
• AIが「反映判断メモ」を書く：「案件／修正前→修正後（理由）／採用するとスキルはこうなる」の型で。責任者はこの欄だけ読んで判断できる
• 反映案は範囲を絞る：「今後のすべての案件で〜」と書くと却下されます（案件ごとに判断は変わる）。「◯◯の記事の導入部では〜」のように、媒体・セクション・語のレベルまで絞る
• 反映は必ず責任者のOK後。先に入れない
• AIに「覚えて」と言われても、その場でファイルを書き換えない設計にする。実際に、ライターのAIがカタログを勝手に書き換える事故が起きました
• 新規の案件からも学ぶ：定期的に（最初は任意・安定したら月1）新しい記事のコメントと「AIの初稿がどう直されたか」を見て、候補を上位5件だけスプシに追加する

着手前に、あるものにチェックを付けてください。「修正履歴」と「判断した人」がないと、判断軸が作れません。

素材

• 過去記事の初稿と公開稿の両方（10件以上あると型が見える）
• 編集者のコメント・赤入れ（ドキュメントのコメント、Chatworkの指摘）
• 取材の文字起こし（入力の形式を決めるため。最低3件）
• 企画意図・依頼の形式（誰が・何のために・どこに載せる記事か）
• 執筆ガイド・表記ルール（あれば。参考扱い）

人

• 判断軸の持ち主（編集責任者）は誰か。複数人なら人ごとに分ける
• その人が普段使っているAIはあるか（記憶の出力元になる）
• 違和感を返してくれる「使う人」（ライター）は何人か
• 反映のOKを出す人は誰か（週1で5分見てもらえるか）

運用

• Googleフォーム＋スプレッドシートを作れるか（FB受け皿）
• 使う人はClaude Codeを触ったことがあるか（導入ハードルの見積もり）
• 更新版を配る経路（Chatworkのグループなど）

ライティング（告知文）との違いから、先に考えておくとよい点です。

1. コメントの位置情報を信じた → 実際の修正箇所とずれていた（30件中26件）。本文全文と突き合わせる
2. 本人の記憶が他人の判断を自分のものとして語った → 確定にする前に発言者を確認
3. ルールを足したら別の指摘が消えた → 新ルールには境界線を付ける
4. AIの指摘が責任者より厳しくなった → 「読者が困るか」の停止条件を入れ、過剰指摘率を測る
5. 型を機械的に当てた → 固定テンプレのない案件に一般ルールを適用。「崩す条件」「この案件の型が優先」を明記
6. 反映案を「全案件で〜」と書いた → 責任者に4件連続で却下。範囲を絞る
7. AIが利用者のファイルを勝手に書き換えた → 「FBは記録するだけ」を最重要ルールに
8. トークン入りコマンドで配布した → Claude Codeが拒否。ZIPに切り替え
9. 出力に内部の記号（章番号・タグ）を出した → 受け取り手には意味不明。理由は日本語で書く
10. 責任者の確認を「全項目に○×」で頼んだ → 負荷が高い。「違うものだけ一言、空欄は○」に変更

全部作らなくても動きます。この順で。

FBスキルは初稿スキルが動いてからで大丈夫です（カタログは共用できます）。日数はAIを使い慣れた人が1人で進める前提です。

• 設計の相談：おの（このPJの旗振り）
• 既存スキル・社内資料の確認：Libe Toolkit（/libe-toolkit）
• スキルの「育て方」の考え方：大ちゃんさん（目的・不満・情報の3問）

参考：ライティングAIスキルの全体像