その他のスキル：コミュニケーションの圧縮、引き継ぎ、指導、Skillの記述、安全ガードレール

個別に展開しない理由

Matt の README では、スキルは3つのカテゴリに分類されています。

• Engineering：日常的に実際のコードを書くために使用
• Productivity：一般的なワークフローツール
• Misc：彼自身が予備として保持している小さなツール

これまでの記事では、メインラインのエンジニアリングスキルをカバーしてきました。この記事では、残りの「Productivity」と「Misc」をまとめて説明します。なぜなら、それらの多くは完全な開発プロセスではなく、特定のシナリオで非常に役立つ小さなスイッチだからです。

もし5つだけインストールするとしたら、私は依然として以下を優先することをお勧めします。

• /grill-me
• /grill-with-docs
• /to-prd + /to-issues
• /tdd
• /improve-codebase-architecture

しかし、メインラインがすでに稼働している場合は、以下のものが日常体験をよりスムーズにします。

Productivity Skills

caveman：コミュニケーションの極限圧縮

/caveman は「少トークンモード」です。エージェントに、挨拶、埋め合わせの言葉、過度な説明、曖昧なバッファリングを削除し、技術情報のみを残すように要求します。

これは以下に適しています：

• 高頻度でイテレーションしており、長い応答を読みたくない場合
• デバッグ時に事実、原因、次のステップのみが必要な場合
• 長いコンテキストがほぼ満杯で、出力を圧縮する必要がある場合
• AI にお世辞を言わせたくない場合

これは AI を失礼にするのではなく、より短い構文で完全な技術精度を維持させるものです。終了と言うまで継続的に有効であることに注意してください。

これを長期的なデフォルトではなく、一時的な設定として扱います。高リスク操作、安全警告、複雑な多段階の指示の場合、短すぎると誤読しやすくなります。

handoff：現在のセッションを次のエージェントに引き継ぐ

/handoff の目標は、現在のセッションを要約した引き継ぎドキュメントに圧縮し、現在のワークスペースを汚染するのではなく、システムのテンポラリディレクトリに保存することです。

これには以下が含まれます：

• 現在の目標
• 決定済み事項
• 主要なパスとファイル
• 残りのタスク
• 次のエージェントに呼び出すべきスキルに関する推奨事項
• 機密情報のマスキング

これは、長時間のタスクの中断、コンテキストのほぼ満杯、または別のエージェントに作業を継続させたい場合に特に適しています。

重要な点：PRD、issue、ADR、commit、diff にすでに存在する内容はコピーせず、パスまたは URL のみを引用してください。引き継ぎドキュメントの価値は、会話に散らばっている状態を補完することであり、プロジェクトドキュメントを再作成することではありません。

teach：現在のディレクトリを学習ワークスペースにする

/teach はこのセットの中で最も重いものです。現在のディレクトリを長期学習ワークスペースとして扱い、以下を維持します。

• MISSION.md：なぜこのトピックを学ぶのか
• RESOURCES.md：高品質なリソースリスト
• learning-records/*.md：学習記録、ADR のようなもの
• lessons/*.html：各セッションごとのインタラクティブなレッスン
• reference/*.html：クイックリファレンス資料
• NOTES.md：指導の好みと作業ノート

そのハイライトは、学習を単発の質問ではなく、長期的なシステムとして捉えることです。特に強調されているのは：

• ミッション先行：何を学ぶかよりも、なぜ学ぶかが重要
• リトリーバルプラクティス：想起練習によって長期記憶を構築する
• 間隔反復：短期的な流暢さに騙されない
• 高信頼性リソース：まず資料を探し、モデルの記憶に頼って話さない

単に「X について説明して」と質問するだけなら必要ありません。数週間かけて一つのトピックを学びたい場合は、これが非常に適しています。

write-a-skill：新しいスキルのためのスケルトンを作成する

/write-a-skill は、スキル構造自体の Matt による抽象化です。

スキルは少なくとも以下を持つ必要があります。

skill-name/
├── SKILL.md
├── REFERENCE.md
├── EXAMPLES.md
└── scripts/

もちろん、後半の3つは必須ではありません。内容が長すぎる場合、例に価値がある場合、または操作がスクリプト化可能な場合にのみ追加します。

最も重要な判断は、description がエージェントがスキルをロードするかどうかを決定する際に最初に目にする唯一の情報であるということです。したがって、description は「ドキュメントの処理を支援する」のような空虚な言葉で書くべきではなく、以下を説明する必要があります。

• 提供する能力
• いつトリガーされるか
• トリガーワードまたはコンテキストは何か

これは私が自分でスキルを書く経験とも一致しています。多くのスキルが機能しないのは、本文の書き方が悪いからではなく、description が広すぎるため、エージェントがそれをロードすべきかどうかを知らないからです。

Misc Skills

git-guardrails-claude-code：危険な git コマンドをブロックする

このスキルは、Claude Code に PreToolUse フックを装備し、Bash を実行する前に危険な git コマンドをインターセプトします。

デフォルトでブロックされるのは以下のコマンドです。

• git push
• git reset --hard
• git clean -f / git clean -fd
• git branch -D
• git checkout . / git restore .

その価値は非常に直接的です。エージェントがあなたの許可なしにプッシュしたり、ハードリセットしたり、追跡されていないファイルを削除したりするのを防ぎます。

AI に実際のレポジトリで作業させる頻繁な場合は、このスキルをインストールする価値があります。AI を信頼しないのではなく、高破壊的な操作をツールレベルでインターセプトし、プロンプトで祈るのではなく、それを行います。

setup-pre-commit：プロジェクトにコミット前チェックを追加する

/setup-pre-commit は以下を設定します。

• Husky pre-commit hook
• lint-staged + Prettier
• typecheck
• test

まずパッケージマネージャーを検出し、次にプロジェクトに既存のスクリプトに基づいて pre-commit で実行すべきものを決定します。typecheck または test がない場合、強制的に作成せず、省略して通知します。

このスキルの価値は設定自体ではなく、Matt の品質観にあります。AI にコードに問題がないと言わせるだけでなく、確定的なチェックを通過させるべきです。

migrate-to-shoehorn：テストで as を少なく書く

これは非常に Total TypeScript スタイルの小さなツールです。テスト内の TypeScript の as 型アサーションを @total-typescript/shoehorn に移行します。

典型的な置換：

これはテストコード専用であり、本番コードには使用されないことが明記されています。

このスキルは非常に狭いですが、Matt のエンジニアリングのセンスに合致しています。型システムのためにテストで20個の無意味なフィールドを作成したり、生の as を使用して型安全を完全に無効にしたりしないことです。

scaffold-exercises：コースリポジトリ用の演習ディレクトリを生成する

このスキルは明らかに Matt 自身のコース作成ワークフローから来ています。仕様に従って以下を作成します。

exercises/
└── 05-memory-skill-building/
    └── 05.02-short-term-memory/
        ├── explainer/
        ├── problem/
        └── solution/

各サブディレクトリには少なくとも空でない readme.md があり、必要に応じて main.ts があり、pnpm ai-hero-cli internal lint をパスする必要があります。

これはほとんどのエンジニアリングプロジェクトには役立ちませんが、コース、ブートキャンプ、練習リポジトリには非常に実用的です。さらに重要なのは、優れたスキルの特徴を示していることです。繰り返し、機械的で、詳細を見落としやすいフォーマット作業をエージェントに任せることです。

現時点でメインラインに含めるべきではないディレクトリ

アップストリームリポジトリには、deprecated/、in-progress/、personal/ もあります。

これらを正式な使用ガイドとして一時的に記述しないことをお勧めします。

将来的に記述する場合は、「Matt Pocock skills リポジトリの考古学」のような単独の記事として作成できます。安定した推奨事項に混在させるのではなく。

このツールのセットの共通点

これらのスキルは散らばっているように見えますが、その背後には同じ原則があります。

エージェントが漂流しやすいことを、小さく明確な作業パターンに変える。

• caveman はコミュニケーションの漂流を防ぐ
• handoff はコンテキストの損失を防ぐ
• teach は学習が単発の質問になるのを防ぐ
• write-a-skill はスキルの構造が手書きになるのを防ぐ
• git-guardrails は危険なコマンドを自己判断に頼るのを防ぐ
• setup-pre-commit は品質チェックを AI の自己申告に頼るのを防ぐ
• migrate-to-shoehorn はテストの型アサーションの制御不能になるのを防ぐ
• scaffold-exercises はコース構造の手動での項目漏れを防ぐ

これも Matt のこのセットで最も学ぶ価値のある点です。スキルは壮大である必要はありません。頻繁に発生する小さな偏差が、20行の指示で安定して修正できるなら、スキルとして記述する価値があります。

参考資料