#skill-design (3)

AIに自分らしい文章を書かせるために「キャラクター抽出→適用」の2段階スキルを作った際の学び。

キャラクター抽出と用途は分離する

「あなたはどういう人か」と「この文章をどうしたいか」は別の関心事。抽出スキルに「どんなトーンで書きたい？」を混ぜると、人物像がブレる。キャラクター抽出は人格の構造化に徹し、用途は適用側のスキルで扱う。

プロファイルの保存場所はユーザーレベル

キャラクターはプロジェクト固有ではなく人に紐づく情報。プロジェクトメモリではなく ~/.dotfiles/profile/ のようなユーザーレベルのディレクトリに置くのが適切。

スキルファイルは短く書く

スキルは新規コンテキストで読み込まれるため、長いと本題のコンテキストが薄まる。質問リストと出力構造と注意事項だけあれば十分。詳細な手順はAI側の判断に委ねる。

命名は「voice」より「character」

文体だけでなく価値観・判断基準・口癖まで含めるなら「voice（声）」より「character（人格）」が正確。

問題

プロジェクトの .claude/rules/ に定義したルールは、ユーザーレベルのスキル（~/.claude/skills/）からは自動ロードされない。スキルを複数リポジトリで使いたい場合、ルールの参照方法を決める必要がある。

選択肢

方法	メリット	デメリット
ルールをスキル内にインライン	自己完結、どのプロジェクトでも動く	ルール変更時に2箇所更新
スキルからルールファイルをRead	ルールは1箇所管理	特定プロジェクトでしか動かない

判断基準

• そのスキルが特定プロジェクト専用か？ → プロジェクトの .claude/skills/ に置き、ルールはRead参照でOK
• 複数リポジトリで使う汎用スキルか？ → ~/.claude/skills/ に置き、ルールはインラインで埋め込む

ルールの更新頻度が低ければ、インラインの二重管理コストは無視できる程度。

技術ブログの公開前レビューをClaude Codeスキル化した際の設計知見

レビュー観点の優先順位

6観点を以下の順で評価するのが効果的だった：

1. セキュリティ・情報漏洩 — 最優先。1件でも公開ブロック
2. 事実の正確性 — 数値はgit logなどで裏取り可能なものは実際に検証する
3. ターゲット適合性 — 複数ターゲット（エンジニア/非エンジニア）がいる場合、セクション分けで対応
4. 構成・読みやすさ — プラットフォーム別の最適文字数を基準にする
5. ブランディング・採用効果 — 宣伝色と信頼性のバランス
6. プラットフォーム固有 — ハッシュタグ、アイキャッチ等

数値検証の重要性

ブログ内の「5日で34件」という記述を gh pr list で検証したら実際は32件だった。素材メモの段階で概数を使っていたものが、記事本文でそのまま「事実」として書かれてしまうパターン。

対策: レビュースキルに「git log / GitHub APIで裏取りできる数値は実際に確認する」をルール化した。

素材整理→体裁検討→執筆の3フェーズが有効

1. 素材整理: git履歴・ドキュメントから事実を正確にMDに書き出す（ファクトシート）
2. 体裁検討: ターゲット・プラットフォーム・切り口を決める
3. 執筆: 素材を元に書く

素材フェーズで数値を正確に記録しておくと、執筆時の事実誤認が減る。

S/A/B/C/D の総合評価スケール

レビュー結果を5段階で示すと、筆者が「どこまで直すべきか」の判断がしやすい：

• S: 公開OK（指摘なし）
• A: 公開OK（軽微な改善提案）
• B: 改善推奨（公開可だが品質向上余地あり）
• C: 要修正（指摘解消後に公開）
• D: 公開ブロック（セキュリティ・事実誤認）