第17章：エージェントスキル活用

第10章のプロンプトは「その場の指示」、エージェントスキルは「Git管理する手順書パッケージ」。本資料ではSKILL.md本体の作成までは扱わず、導入用指示（1行）と試用判断までを記載する。一覧・メリデメの正本は第19章総評・一覧シート。

公開スキルの扱い: 人気順では採用しない。第19章をマスタとし、第13章のデータ分類・公開スキル採用前チェックを通過したものだけPoCで試用する。

17.0 品質ゲート向け：AI役割分担の検証例

本調査の前提は「AIに全部任せる」ではなく、工程内品質ゲートの副操縦士として使うこと（第1章・第00章）。ツール選定は PoC テーマごとに行い、第19章をマスタとして採否・KPI・中止条件を記録する。

参考事例として、実装とレビューを別モデルに分離し、ベンダー単一依存リスクを下げる構成がある（note: 役割分担の一例）。PoCでは「効果が測れるか」「第13章ガバナンスに抵触しないか」を先に確認する。

品質安定化 PoC で検証しやすい4役割（2026年時点の例）
役割	ツール例	品質ゲートでの役割	測る指標（第12章）
コックピット	Cursor	差分確認・画面検証・人間の採否判断	レビュー時間、利用者負担
メインエンジン	Claude Code	実装案・修正案の起草（採否は人間）	手戻り件数、バグ件数
補助監査	Codex 等	別モデルによる PR / 設計の一次チェック	AI指摘採用率、Critical指摘
高速工具	Composer 等	軽い確認（長セッションのコンテキスト汚染防止）	—（補助）

職種章 × PoCテーマ（第11章と接続）

調査章と PoC 主題の対応
章	PoCテーマ例	向くAI活用	参照
3 PG	PR前セルフレビュー / TDD	実装起草＋別モデルレビュー	3.7 · 第12章 P-1
4 SE	要件・設計レビュー	曖昧語・未決・意味逸脱の検出	4.0b · 第17章 B-1/B-2
5 QA	テスト観点生成	観点表の下書き（採否はQA）	5.0b · 第12章 Q-1
6 レビュー	PR前チェック	敵対的レビュー・観点の標準化	6.0b · 第6章 R-1
8 PM	週次・リスク整理	要約・open-items 抽出	第12章 · 第13章
11 PoC	3か月計画	テーマ絞り込み・中止条件	11.0b

公開スキルとの関係: 上記は役割の考え方。具体スキルは人気順で採用せず、第19章一覧→第13章チェック→PoC試用。すぐ使える同梱スキル: bonus_kit（ai-quality-pr-review · requirements-definition-gate 等8本）。

定着フェーズ: PoCで継続判定後、正本ドキュメントの常時運用が必要になった場合は dev_docs_guide を参照（本調査の範囲外）。

PMO AIPC — 社内ノウハウ蓄積地（Hermes + Ollama · MCP Server）

結論: Hermes は Cursor/Codex の代替ではなく、セキュアゾーンに置く記憶・整流レイヤーとして扱う。開発 PC 直置きの常時稼働 Hermes は blast radius が大きいため、個人検証に限定する。

推奨	PMO AIPC = Hermes + Ollama を内包した MCP Server。Skill・手順・レビュー観点・失敗パターンを非機密の範囲で蓄積する。
非推奨	開発 PC に Hermes daemon を常駐させ、ソース・鍵・顧客情報へ広くアクセスさせる構成。
未決	セキュアゾーンのネットワーク要件、MCP Server 実装方式、Ollama モデル標準。ADR 化待ち。

詳細な構成、メリット・デメリット、採用判定は第20章 Hermes / PMO AIPC に集約。

参考: Hermes Agent · Ollama × Hermes

17.0b Agent-native CI/CD — スキル変更の品質ゲート

Zylos Research（2026） · InfoQ Playbook が示す通り、エージェント挙動はプロンプト・ツール定義・モデル版の組合せで決まる。従来 CI だけでは静かな行動退行を検出しにくい。

段階導入する5ゲート（メリット大の順）
ゲート	効果	注意
プロンプト/スキルを Git IaC 化	変更追跡・差分レビューで標準化	HTML やチャットだけが正本になる運用は禁止
ゴールデン eval（25〜100件）	マージブロックで精度退行を防止	データセット陳腐化 — 本番トレースから更新
コストゲート（例 +15%）	品質向上の隠れコストを明示	閾値はチーム合意
シャドウ（dry-run ツール）	分布シフトを本番前に検出	外部 API 実呼び出し禁止
カナリア 5%→100%	影響限定・自動ロールバック	既に起きた副作用は設定戻しだけでは不十分

PoC との接続: bonus_kit のスキル更新 PR に、まずゴールデン eval + コスト計測を足すと費用対効果が高い。Hermes 等の常時稼働は第9章インフラ・第13章ガバナンス審査後。

Knowledge 索引（スキル）

スキル一覧は skills.yaml。採否は第19章 + 第13章 13.2d チェック後。Installs/Stars は品質根拠にしない。

手順: extract_knowledge_from_markdown.md

17.0c 既存ワークフローへの AI 役割設計

17.0（4役割）· 17.0b（Agent-native CI/CD）· 7.0d（CI/CD×AI接続）の上位レイヤ。PoC 前に「AIに何をさせ、何を人間が判断するか」をワークフロー単位で定義する。

CI/CD×AI 協調（第7章 7.0d（CI/CD×AI））が接続の仕方なら、本章はもう一段上の運用設計 — 既存ワークフロー・作業ルーティンの中で AI をどの役割として差し込むかを扱う。

AIを開発ワークフローや作業ルーティンの中で、
どのような役割として既存開発に馴染ませるか。

本質: AIに作業を丸投げするのではなく、品質定義・作業ルール・判断基準を AI が参照できる形に蒸留し、副操縦士として差し込む。

鉄則: 品質定義がない AI 活用は速いがブレる。品質定義がある AI 活用は速くて管理できる。

蒸留先 · ワークフロー10例 · 効果別パターン

AI向けプロジェクト知識の蒸留先
ドキュメント	主な対象	役割
`README.md`	人間・AI	概要 · 起動 · 基本構成
`ARCHITECTURE.md` / `docs/design/DESIGN.md`	人間・AI	設計思想 · レイヤー · 依存方向
`CONTRIBUTING.md` / `docs/sop/engineering.md`	人間・AI	ブランチ · PR · レビュールール
`TESTING.md` / `TestDesignDoc.md`	人間・AI	テスト方針 · 実行コマンド · 観点
`REVIEW_GUIDE.md`	人間・AI	レビュー観点 · 禁止パターン
`AGENTS.md`	AIエージェント	Commands · Rules · Done · 禁止事項
`CLAUDE.md`	Claude系	頻出コマンド · 作業方針（肥大化注意）
`.github/copilot-instructions.md`	Copilot	リポジトリ固有指示
Redmine / Jira	人間・AI	判断履歴 · 例外承認 · 対応経緯
CI/CD設定	人間・AI	客観的品質判定条件

dev_docs_guide では AGENTS.md + docs/sop/ + .agents/skills/ の3層が蒸留先の実装例（第4章）。複数AIツール間でルール分散しないよう、正本は Git · 派生は各ツール向け短い入口に留める。

既存ツール・ワークフローへの AI 組み込み（5例）
#	組み込み先	AIの役割	効果	メリット	懸念
2	AGENTS.md / Codex	作業手順 · 規約定義	中	setup/test/style を標準化	構造化と更新が必要
4	CI/CD + AIログ解析	失敗原因候補整理	大	調査初動が速い	原因推定の鵜呑み禁止
5	SonarQube AI Code Assurance	AI生成コードのQG	大	客観基準を強制	ゲート設計が甘いと形骸化
6	CodeRabbit / PR-Agent	PR初期レビュー · 要約	中	人間レビュー前の下読き	指摘過多でレビュー疲れ
9	Redmine/Jira AI要約追記	経緯整理 · 引き継ぎ	大	判断履歴が残る	事実と推測の混同

効果の大きさで見る導入パターン

効果	パターン	要点
大	CI失敗ログAI要約	CI=事実 · AI=翻訳 · 人間=判断。秘密情報マスク · 推測/事実の分離
大	Quality Gate（AI生成コード）	静的解析·セキュリティ·複雑度·重複を機械判定。閾値設計が必要
大	BTS·Doc·Git文脈込み	出力が現場期待に近づく。権限·情報境界の設計が必須
中	PR/MR AI一次レビュー	差分要約·テスト不足指摘。プロジェクトルール未整備だと一般論化
中	Copilot instructions / AGENTS.md	命名·依存方向·テスト実行を明示。古いルールは逆効果
中	BTS AI要約追記	価値は「作業」より「経緯整理」。要約責任者を明確に
小〜中	Web調査 · MVP報告	一次情報優先 · 実例/推測分離 · 効果大中小 · 懸念必須

PoC 着手順: ① 品質定義テンプレ（§8）を docs/sop/ai-usage.md にたたき台 → ② AGENTS.md に Commands/Rules/Done → ③ CI失敗要約 or PR一次レビューを1本 → ④ 週次KPI（第12章）。

AI向け品質定義テンプレート（作業前に最低限）

## このプロジェクトで重視する品質
- 正確性 / 保守性 / 可読性 / セキュリティ / 性能 / テスト容易性 / 運用容易性

## 設計思想
- レイヤー構造 · 依存方向 · 禁止依存 · 例外処理 · ログ方針

## コーディングルール
- 命名 · フォーマット · null扱い · DB/外部APIアクセス · エラー処理

## テスト方針
- 必須テスト · 変更時コマンド · 追加観点 · テスト不要条件

## AIに任せてよいこと / 任せないこと / 人間が確認すること
（ログ要約·PR要約 / 仕様最終判断·本番デプロイ / 影響範囲·セキュリティ）

starter_kit: docs/sop/ai-usage.md · AGENTS.md に落とし込む。詳細は正本 references/ai_role_design_for_existing_dev_workflow.md §8。

5層運用: ルール · スキル · アンカー（ADR/REQの判断構造）· 評価（CI/eval）· ログ（PR/BTS）。品質アンカーはPoC仮説として第2章を参照。

定着: dev_docs_guide 第4章 · 正本MD: references/ai_role_design_for_existing_dev_workflow.md

参考: Copilot repository instructions · Codex AGENTS.md · Atlassian Rovo Dev · AGENTS.md効果分析 (arXiv) · RovoDev Code Reviewer (arXiv)

研修 — スキルとクライアント層リスト

公開スキル監査（17.x）と独立に、IDE の permissions.json / CLI permissions.allow|deny をプロジェクト正本とする。スキルが「削除して」と書いても、端末リストが最後の防御層になる。

正本	編集者	レビュー
`.cursor/permissions.json`	PG + Sec 雛形	四半期 · 事故後即時
`.agents/skills/*/SKILL.md`	機能オーナー	13.2d 公開前チェック
GW `registry/mcp-servers.yaml`	Sec	MCP 申請フロー

上級編: LiteLLM MCP は Key/Team/Org の intersection。Cursor Enterprise はグループ併属で permissive 側が勝つ場合あり — 製品ごとに評価ロジックが異なる。

17.1 プロンプト vs スキル

観点	都度プロンプト	エージェントスキル（SKILL.md）
再現性	担当者・セッションでばらつく	同じ手順・観点表・出力形式をチームで共有
版管理	チャット履歴に埋もれる	Git PRでレビュー・差分追跡可能
コンテキスト効率	長い指示を毎回貼る	メタデータのみ常時ロード、必要時に全文展開（Progressive Disclosure）
自動起動	毎回明示が必要	タスク内容に応じてエージェントが関連スキルを選択可能
向かない用途	—	1行の簡単な指示、機密ルールの常時全件注入（Rules向き）

17.2 公開エコシステム：主要リポジトリ

リポジトリ	GitHub Stars（概算）	特徴	品質安定化での位置づけ
obra/superpowers	約22.7万	TDD・コードレビュー・デバッグ・計画実行の方法論スキル群	実装・レビュー工程の「型」を強制する代表例
anthropics/skills	約15.0万	公式サンプル。Webテスト、ドキュメント、MCP生成等	テスト自動化・成果物レビューの参照実装
addyosmani/agent-skills	約5.9万	本番品質向け24スキル（TDD、セキュリティ、増分実装等）	エンジニアリング実務に近いワークフロー
vercel-labs/skills	約2.2万	skills.sh CLI、スキル発見・インストール基盤	社内標準スキルの配布・更新に使える
supabase/agent-skills	約2.2千（リポ）	Postgres性能・RLS等のDBベストプラクティス	DB設計レビュー・性能指摘の補助

17.3 品質安定化向け：人気スキル一覧（skills.sh）

週次インストール数が多く、品質・テスト・レビュー・設計に直結するスキルを選定した。

スキル名	提供元	週次Installs（概算）	リポStars（概算）	主な用途	導入用指示（1行）
systematic-debugging	obra/superpowers	143K	227K	根本原因調査→仮説→修正の4段階デバッグ	再現環境＋ログを投入。3回失敗で設計見直し。本番は復旧優先を別途明文化
requesting-code-review	obra/superpowers	128K	227K	サブエージェントによるコードレビュー、重大度分類	PRテンプレにAI利用欄追加。Critical/Important採否を記録。第6章R-1と連動
test-driven-development	obra/superpowers	127K	227K	Red-Green-Refactor、テスト先行の強制	保守チケット1件に限定。失敗テスト先行→人間採否。第3章P-1 KPI計測
supabase-postgres-best-practices	supabase/agent-skills	231K	2.2K	SQL・索引・RLS・性能のルール集	設計書1章＋DDLを投入。EXPLAINは人間確認。Oracle/SQL Serverは別ルール
webapp-testing	anthropics/skills	95K	150K	PlaywrightによるWebアプリテスト手順	中機能1件でE2E下書き→QA採否→CI追加可否を判断。第5章Q-1と併用
verification-before-completion	obra/superpowers	（superpowers内）	227K	「完了」宣言前の検証ゲート	lint/test/手動確認を一覧化してから完了報告。最終「完了」は人間が宣言
vercel-react-best-practices	vercel-labs	301K	25K	React性能・再レンダー・バンドル最適化69ルール	性能チケット1件に適用。Lighthouse等の計測結果とセットで採否
skill-creator	anthropics/skills	（高ランク）	150K	社内標準スキルの作成・テスト	PoC成功したプロンプト1本のみSKILL化候補に。第17章B系と併用
test-driven-development	addyosmani/agent-skills	5K	59K	TDD＋ブラウザ検証連携、Prove-Itパターン	superpowers TDDと二重試用せず、Web＋ブラウザ検証案件で1本だけ試用

17.4 事例A：公開スキル詳細（メリット・デメリット）

A-1. obra/superpowers — test-driven-development

概要：実装前に失敗するテストを書き、失敗を確認してから最小実装。テストなしで書いたコードは削除させる設計。

インストール：

npx skills add https://github.com/obra/superpowers --skill test-driven-development

導入用指示：保守チケット1件に限定。実装前に失敗テスト→人間採否。第3章P-1 KPI計測。

メリット	デメリット・注意点
AIの「動きそう」実装をテストで縛れる	レガシーでテストが無いコードには初期コスト大
バグ修正時も再現テスト先行（Prove-It）	手順が厳格で、小さなUI変更でもオーバーヘッド感
チーム全体でTDD文化をエージェント経由で統一	英語ベースの指示。社内用語はスキル改変が必要
127K installs、コミュニティ実績が豊富	「強制」設計のため、PoC初期は反発があり得る

社内提案での言い方：「AIにコードを書かせる」ではなく「AIにテスト観点と失敗確認をさせ、人間が採否する」。

A-2. obra/superpowers — requesting-code-review

概要：タスク間・マージ前にコードレビューサブエージェントを起動。Critical / Important / Minor で指摘を分類。

npx skills add https://github.com/obra/superpowers --skill requesting-code-review

導入用指示：PRテンプレにAI利用欄を追加し、Critical/Importantの採否を記録。第6章R-1指標と連動。

メリット	デメリット・注意点
人間レビュー前の一次品質が上がる（第6章と整合）	業務仕様・ドメイン判断は人間必須
128K installs、PRレビュー文化と相性良い	サブエージェント利用はトークン・時間コスト増
計画書との整合チェックが可能	社内セキュリティでサブエージェントが制限される場合あり

A-3. obra/superpowers — systematic-debugging

概要：症状パッチ禁止。証拠収集→パターン分析→仮説検証→修正の4段階。3回失敗で設計見直しを促す。

npx skills add https://github.com/obra/superpowers --skill systematic-debugging

導入用指示：再現環境＋ログを投入。3回失敗で設計見直し。緊急本番は復旧優先を別途明文化。

メリット	デメリット・注意点
143K installs、障害・バグ調査の属人化を減らす	緊急本番障害では「まず復旧」優先の判断が別途必要
再発防止のテストケース追加まで含む設計	ログ・再現環境が無いと効果半減
AIの早とちり修正を抑止	手順が長く、軽微なtypo修正には過剰

A-4. anthropics/skills — webapp-testing

概要：Python PlaywrightでローカルWebアプリをテスト。サーバ起動ヘルパー、DOM reconnaissance→操作の2段階。

npx skills add https://github.com/anthropics/skills --skill webapp-testing

導入用指示：中機能1件でE2E下書き→QA採否→CI追加可否を判断。第5章Q-1と併用。

メリット	デメリット・注意点
95K installs、E2E観点の具体化に使える（第5章）	Python/Playwright前提。Java/.NETのみ案件は別スキル検討
公式実装でメンテ期待できる	生成スクリプトは人間レビュー・CI組込必須
動的SPA向けにnetworkidle待機を明示	社内テスト基盤（Selenium等）との二重管理リスク

A-5. supabase/agent-skills — supabase-postgres-best-practices

概要：Postgresのクエリ・索引・RLS・スキーマ設計を8カテゴリ・優先度付きルールでレビュー。

npx skills add https://github.com/supabase/agent-skills --skill supabase-postgres-best-practices

導入用指示：設計書1章＋DDLを投入。性能はEXPLAINを人間確認。Oracle/SQL Server案件は別ルール。

メリット	デメリット・注意点
231K installs、DB設計レビューの観点表として使える	Supabase/Postgres特化。Oracle/SQL Serverは別途
誤SQL vs 正SQLの対比例が豊富	基幹DBの社内命名規約はカスタム追記が必要
SEのDB設計書AIレビュー（第4章）と接続しやすい	性能数値は環境依存。EXPLAINは人間確認

A-6. addyosmani/agent-skills — パック全体

概要：24スキル構成。incremental-implementation、spec-driven-development、security-and-input-hardening等。本番品質向けの「ライフサイクル」設計。

npx skills add https://github.com/addyosmani/agent-skills --skill incremental-implementation
npx skills add https://github.com/addyosmani/agent-skills --skill test-driven-development

導入用指示：PoCは2本に絞る（例：incremental-implementation＋TDD）。新機能1本をスライス分割し各スライスでレビュー・テスト完了をゲート化。

メリット	デメリット・注意点
59K repo stars、エンジニア向け評判が高い	スキル数が多く、PoCは2〜3本に絞るべき
増分実装・セキュリティ境界が明文化	主にWeb/JS寄り。COBOL/レガシーは要カスタム
superpowersより「実装の切り方」に重点	日本語案件資料との用語ギャップ

17.5 事例B：社内PoC向けスキル（受託開発・品質ゲート）

以下は実プロジェクトで運用中のスキルパターンを匿名化した事例。公開スキルと併用すると、「業界標準の型＋社内固有のゲート」が両立する。

B-1. 要件定義ゲートスキル（社内PoC）

項目	内容
向く工程	要件定義レビュー、見積前、基本設計着手前
できること	曖昧語・未決・BLOCKER抽出、顧客確認事項と内部修正の分離、MODE-A〜Dで成熟度別レビュー
メリット	第4章プロンプトを標準化。出力形式が固定され、ゲート判定が可能
デメリット	合意索引・用語集が無いと推測リスク。人間のGO/NO-GOは必須
公開スキルとの差	汎用TDD/レビュー系は「コード向き」。本スキルは「要件・契約・見積境界」向き
導入用指示	要件1章をMODE-Bでレビュー。顧客確認事項と内部修正を分離記録。第4章S-1 KPI

B-2. 意味逸脱監査スキル（社内PoC）

項目	内容
向く工程	議事録→要件反映後、要件改訂前後、AI要約文の検証
できること	版間で主張強度・責任主体・条件・スコープの変化を検出
メリット	AI要約で「勝手に確定」「条件消失」を防ぐ（第13章リスク対策）
デメリット	比較元・先の2版以上が必要。初回セットアップに学習コスト
併用	要件定義ゲートスキルとセットで「横断＋版間」の二層レビュー
導入用指示	旧版＋新版を投入。主張強度・責任主体・スコープ差分を一覧→人間判定

B-3. 議事録・ドキュメント可読化スキル（社内PoC）

項目	内容
向く工程	PM/PL、ドキュメント管理、客先資料変換
できること	議事録下ごしらえ、Markdown同期、資料の可読化パイプライン
メリット	属人化した議事録・資料整形を再現可能に
デメリット	スクリプト・パス依存。環境差分の説明と機密マスキングルールが必要
導入用指示	1会議分でPREP→FINALIZE試行。客先資料は変換ルール＋マスク確認

17.6 スキル選定マトリクス（社内提案用）

優先課題	まず試す公開スキル	社内で足すスキル	測る指標
実装バグ・手戻り	test-driven-development（superpowers）	—	単体テスト数、バグ件数、手戻り
PRレビュー負荷	requesting-code-review	PRテンプレ＋AI利用証跡	レビュー指摘件数、レビュー時間
障害・バグ調査	systematic-debugging	過去障害ナレッジ参照	再発件数、調査時間
要件・設計の抜け	—（汎用スキルは弱い）	要件定義ゲート、意味逸脱監査	顧客確認件数、設計手戻り
DB設計品質	supabase-postgres-best-practices	社内DB命名・監査ルール追記	性能指摘、本番障害
E2E・画面テスト	webapp-testing	テスト観点生成プロンプト（第10章）	テストケース数、漏れ指摘
IaC・Terraform	terraform-best-practices、azure-validate	infra-change-review（第9.14）	checkov指摘、planレビュー時間、設定ミス
インフラ障害切り分け	systematic-debugging	第9.9障害プロンプト、過去障害票	一次切り分け時間、MTTR

17.7 導入パターンとガバナンス

配置場所

スコープ	パス例	用途
プロジェクト	`.agents/skills/` または `.cursor/skills/`	案件固有の要件ゲート、用語、テスト観点
個人	`~/.codex/skills/` 等	PoC個人試行（本番展開前）
組織	社内Git＋`npx skills add org/repo`	承認済みスキルのみ配布

社内ルール（第13章と整合）

公開スキルはそのまま本番利用しない。セキュリティ監査（skills.shの監査結果）と社内レビュー後に採用。
スキル内スクリプト実行は、ネットワーク・ファイルアクセス権限を確認する。
機密・個人情報を含む案件は、スキルに渡す資料範囲をガイドライン化。
効果測定（第12章）が取れないスキルは限定継続または中止。

注意：インストール数が多い＝社内そのまま安全、ではない。特に動画生成・ブラウザ自動操作系は品質PoCの対象外とし、まずレビュー・テスト・デバッグ系から始める。

17.8 PoCでの試用順（推奨）

Week 1-2：第10章プロンプトでセルフレビュー試行（スキルなしでも可）
Week 3-4：requesting-code-review または社内PRレビュー手順をスキル化
Month 2：test-driven-development を1機能に限定試用
Month 2-3：要件・設計案件で社内ゲートスキルを試用
Month 3：指標比較、継続スキル一覧を第15章に反映

17.9 インフラエンジニア向けスキル（詳細）

第9章と対になるスキル選定。開発向け（17.3〜17.4）と併記して提案資料に載せる。

スキル	Installs	Stars	メリット	デメリット	導入用指示（1行）
azure-validate	387K	1.2K	デプロイ前検証の手順固定、deployment-plan連携	Azure特化。計画書なしでは起動しない設計	非本番のみ。deployment-plan作成→validate通過までdeploy禁止
azure-deploy	388K	1.2K	validate後のみ実行、エラー回復手順あり	本番自動デプロイは変更管理とセット必須	validate通過＋人間承認後に非本番deploy。本番は変更管理フロー
terraform-best-practices	203+	33	37ルールでIaCレビュー観点を標準化	Stars少。Terramate視点のルール	IaC PR1件＋checkov/tflint必須。planレビュー時間を記録（I-1 KPI）
InsideOut	—	—	設計対話・コスト見積・ドリフト検知	クラウド中心。オンプレは第9章プロンプト主体	クラウド設計1件を対話レビュー。コスト・ドリフト判断は人間
systematic-debugging	143K	227K	障害切り分けの型。ログ調査に転用	緊急復旧優先時は手順短縮要	第9章9.9プロンプトと併用。模擬障害1回（I-3 KPI）
supabase-postgres-best-practices	231K	2.2K	DB設定・SQLレビュー	Postgres特化	DB設計・SQLレビュー1件。性能数値は環境依存、人間確認

インフラスキルは「監査官・レビュアー」として使う。VMware-AIops等の操作系スキルは、読取・下書きに限定し、本番変更は人間承認＋既存変更管理に従う（第9.15節）。

インフラBefore/After事例・1週間スターター：第9章 9.11〜9.12（KPIは第11章 11.3.2 と同一）

17.10 事務・エンゲージメント向けスキル

詳細・業務マップ・電話取次：第18章。以下は提案用サマリー。

スキル	Installs	用途	メリット	注意	導入用指示（1行）
xlsx（anthropics）	110K	勤怠・経費・台帳	式エラー検出、テンプレ維持	機密は閉域	マスク済CSV×Excelで第18.4照合。給与判断・客先自動送信禁止
pdf / docx	134K / 125K	契約・稟議・請求書	抽出・編集の標準実装	法判断不可	テンプレ1種。抽出結果は人間確認。外部送信前に必須チェック
copywriting	—	社内周知	トーン統一	禁句は社内ルールで	経費・周知文案。禁句表（18.11）でセルフチェック後に人間確定
summarize-meeting	—	議事録構造化	決定・宿題抽出	内容は人間確認	会議後トランスクリプト→決定/宿題/未決分離。顧客向けは必ず編集
attendance-worklog-reconciliation	社内	自社×客先照合	締め前不整合検出	マスク必須	xlsx導入＋第18.4プロンプト。A-1 KPI（差戻し・照合工数）
phone-intake-assistant	社内	電話取次メモ	聞き漏れ・文案	自動発信禁止	第18.5.3指示を標準手順に。層1から。PH-1 KPI
engagement-initiative-drafter	社内	意識調査施策	能動性を促す言い回し	人事が最終決定	匿名サーベイサマリー→施策3案→禁句チェック→1案を人間確定。E-1 KPI

公開スキルは「優れた個人技の結晶」。詳細一覧は第19章。