菜单
技術選定や競合分析を行う際に自律的にギャップ分析を行うメタスキルです。 複数の軸で類似概念を調査し、現行システムとのギャップを洗い出し、 なぜそのギャップが生じているのかを自問して戦略を立案します。 Trigger: 技術選定, 競合分析, 改善提案, ギャップ分析
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
agentops のオフライン記憶整理 (consolidation) 機能。会話 transcript は読まず、 既存の memory entry を「精緻化のみ」する。新しい記憶が獲得されたセッションでだけ Stop hook から自動発火する (fingerprint trigger gate)。手動実行は /dream。 Trigger: dreaming, memory consolidation, 記憶整理, refine memory, dream, memory dedup, /dream
AI 生成(vibecoding)成果物に潜む「それっぽい虚偽」を、固定された検査カタログ(検査ID・手順・ 合格基準つき)で系統的に検出する監査規格。主張面を列挙し、各主張面に対応する検査を 機械的に適用し、カバレッジマトリクスに全セルの実施状態を記録する。 内部整合(テスト全パス・schema valid・CI green)は証拠として認めない。 Trigger: 虚偽検出, ハリボテ検出, vibecoding 監査, 本物か確認, それっぽい嘘, fabrication audit, AI生成コード 検証, 捏造チェック.
Builds a harness: a meta-skill that defines specialist agents and generates the skills they use. Trigger when the user (1) asks to 'build/set up/construct a harness', (2) asks for 'harness design' or 'harness engineering', (3) wants a harness-based automation system for a new domain/project, (4) wants to restructure or extend an existing harness, or (5) asks to inspect, audit, sync, or maintain an existing harness (agents/skills drift, status check).
dev tool / OSS が「刺さるか(PMF)」をエンジニアリング観点で監査するオーケストレーター。 3 specialist agent (ttfv-auditor / trust-calibrator / wedge-scoper) をチームで起動し、 初回体験(TTFV)・出力の信頼(false-positive economics)・scope の鋭さ(wedge over engine)を 並行監査して、合成 PMF readiness スコアと優先度付き改善提案を1つのレポートに統合する。 Trigger: PMF 監査, PMF audit, dev tool 採用, なぜ自分のOSSが採用されない, ローンチ前監査, TTFV, time to first value, false positive, 誤検知, 信頼設計, wedge, scope 設計, this tool isn't getting adopted, audit my OSS before launch, 再監査, re-audit, 改善後の再評価. CLI/library/dev tool/security tool の repo を渡された採用観点の監査依頼で発火する。 単なるコードレビューやバグ探し、一般的な品質監査では発火しない(それらは別 skill)。
security / correctness tool(linter, scanner, verifier)の出力が信頼を獲得・維持できる設計かを 監査する方法論。false-positive economics、Indeterminate verdict、audit-first rollout、 suppression の使い勝手、FP feedback loop を採点する。trust-calibrator agent が使用。 Trigger: 信頼設計 監査, false positive 監査, FP economics, verdict 設計, audit-first, suppression, linter 疲労.
dev tool / OSS の Time-to-First-Value(見知らぬ人が install してから本物の価値に触れるまでの秒数)を 監査する方法論。初回ファネルを step 単位で復元し、引数ゼロで動くか・失敗パスが次の手を示すか・ 価値を借りているかを採点する。ttfv-auditor agent が使用。 Trigger: TTFV 監査, 初回体験 監査, time to first value, onboarding friction, first-run, 採用ファネル.
| name | gap-analysis |
| description | 技術選定や競合分析を行う際に自律的にギャップ分析を行うメタスキルです。 複数の軸で類似概念を調査し、現行システムとのギャップを洗い出し、 なぜそのギャップが生じているのかを自問して戦略を立案します。 Trigger: 技術選定, 競合分析, 改善提案, ギャップ分析 |
| user-invocable | false |
表面的な比較ではなく、ギャップの根本原因を理解し、付け焼き刃ではない本質的な改善戦略を立案する。
単一の軸ではなく、複数の観点から対象を捉える。
状況: 認証基盤のギャップ分析 分析軸を網羅的に洗い出す： - 機能軸: 認証方式、MFA対応、SSO連携 - 品質軸: 可用性、レイテンシ、スケーラビリティ - 運用軸: 監視、ログ、障害対応 - セキュリティ軸: 暗号化、監査、コンプライアンス - コスト軸: 初期費用、運用費用、スケール時コスト ## 分析軸| 軸 | 観点 | 重要度 |
|---|---|---|
| 機能 | 何ができるか | 高 |
| 品質 | どれだけ信頼できるか | 高 |
| 運用 | どれだけ管理しやすいか | 中 |
| セキュリティ | どれだけ安全か | 高 |
| コスト | どれだけ費用対効果があるか | 中 |
各軸において、業界標準や先行事例を調査する。
状況: 現行のEC2ベース認証基盤とマネージドサービスの比較 この機能に関連する類似概念は何か： - Amazon Cognito: AWSマネージド認証 - Auth0: SaaS型認証プラットフォーム - Keycloak: OSS認証サーバー - Firebase Auth: Googleマネージド認証それぞれがどのようにこの問題を解決しているか調査する。
| 概念 | アプローチ | 強み | 弱み |
|---|---|---|---|
| Cognito | AWSマネージド | AWS統合、スケーラビリティ | カスタマイズ制限 |
| Auth0 | SaaS | 機能豊富、SDK充実 | コスト高、ベンダーロック |
| Keycloak | OSS自前運用 | 柔軟性、コスト | 運用負荷 |
| Firebase Auth | Googleマネージド | 導入容易 | AWS連携が弱い |
業界標準: OAuth 2.0 / OIDC、SAML 2.0 先行事例: Netflix（自前基盤）、Spotify（Auth0採用）
現行システムと類似概念との差分を特定する。
状況: 現行EC2認証基盤とCognitoのギャップ ## ギャップマトリクス| 機能 | 現行 | Cognito | ギャップ |
|---|---|---|---|
| カスタム認証フロー | ◎ 完全自由 | △ 制限あり | +柔軟性 |
| 既存DB統合 | ◎ 直接接続 | △ Lambda必要 | +シンプル |
| 監査ログ形式 | ◎ 自社標準 | △ CloudTrail形式 | +統一性 |
| 機能 | 現行 | Cognito | ギャップ |
|---|---|---|---|
| 可用性 | △ 99.9% | ◎ 99.99% | -0.09% |
| MFA対応 | △ TOTP のみ | ◎ 多方式 | -3方式 |
| スケーラビリティ | △ 手動 | ◎ 自動 | -自動化 |
なぜそのギャップが生じているのかを掘り下げる。
状況: MFA対応のギャップがある 問題: MFA方式がTOTPのみ ↓ なぜ？ 他の方式を実装していないから ↓ なぜ？ 開発リソースを他に優先したから ↓ なぜ？ ビジネス要件としてTOTPで十分だったから ↓ 根本原因 **要件定義時のスコープ決定**: 当時のユーザー規模ではTOTPで十分と判断したこれはギャップではなく、当時の合理的判断の結果である。
| 層 | 問い | 回答 |
|---|---|---|
| 表層 | なぜTOTPのみ？ | 他を実装していないから |
| 中層 | なぜ実装していない？ | リソースを他に優先したから |
| 深層 | なぜ優先しなかった？ | 当時の要件で十分だったから |
| 根本 | スコープ決定 | 当時の規模に最適化した設計 |
結論: 規模拡大に伴い「埋めるべきギャップ」に変化
| 層 | 問い | 回答 |
|---|---|---|
| 表層 | なぜ99.9%止まり？ | 単一AZ構成だから |
| 中層 | なぜ単一AZ？ | コスト最適化のため |
| 深層 | なぜコスト優先？ | スタートアップ期の制約 |
| 根本 | リソース制約 | 成長段階に応じた投資判断 |
結論: 事業成長に伴いマルチAZ化を検討すべき
根本原因に基づき、付け焼き刃ではない戦略を策定する。
状況: ギャップ分析結果から戦略を立案 ギャップの分類: 1. 意図的トレードオフ → 受容、ただし再評価 2. 成長による陳腐化 → 対応検討 3. リソース制約 → 優先順位付け戦略の選択肢:
現行の強みを維持しながら、マネージドサービスの利点を取り込む。
| ギャップ | 根本原因 | 戦略 | 対応 |
|---|---|---|---|
| MFA方式 | スコープ決定 | 転嫁 | Cognito MFAを部分導入 |
| 可用性 | リソース制約 | 軽減 | マルチAZ化を実施 |
| カスタム認証 | 意図的設計 | 受容 | 現行維持、強みとして活用 |
優先度: 高
優先度: 中
優先度: 低
なぜこの戦略か？
# [対象] ギャップ分析
## 1. 分析軸
| 軸 | 観点 | 重要度 |
|----|------|--------|
| | | |
## 2. 類似概念調査
| 概念 | アプローチ | 強み | 弱み |
|------|-----------|------|------|
| | | | |
## 3. ギャップマトリクス
### 優れている点
| 項目 | 現行 | 競合/標準 | 差分 |
|------|------|----------|------|
| | | | |
### 劣っている点
| 項目 | 現行 | 競合/標準 | 差分 |
|------|------|----------|------|
| | | | |
## 4. 根本原因分析
### ギャップ: [名前]
| 層 | 問い | 回答 |
|----|------|------|
| 表層 | | |
| 中層 | | |
| 深層 | | |
| 根本 | | |
**結論**: [埋めるべき/受け入れる]
## 5. 戦略立案
### 方針: [一言で]
### ギャップ別対応
| ギャップ | 根本原因 | 戦略 | 対応 |
|----------|---------|------|------|
| | | 回避/軽減/転嫁/受容 | |
### アクション
- 優先度 高:
- 優先度 中:
- 優先度 低:
### 戦略の根拠
**なぜこの戦略か？**
-
ギャップを特定したら、以下を必ず自問する：
| 振る舞い | 問題 | 代わりに |
|---|---|---|
| 全ギャップを埋めようとする | 差別化喪失、リソース浪費 | 優先順位を付ける |
| 表面的な機能追加 | 根本解決にならない | なぜなぜ分析で原因特定 |
| 競合の模倣 | 二番煎じ | 独自の強みを伸ばす |
| ギャップを隠す | 信頼喪失 | 透明に説明し代替案提示 |
ギャップ分析に基づく重要な意思決定は ./docs/adr に記録する。
# ADR-XXXX: [ギャップ]への対応方針
## ステータス
採用
## コンテキスト
ギャップ分析により、[対象]において[ギャップ]が特定された。
## 根本原因
[なぜなぜ分析の結果]
## 決定
[戦略: 回避/軽減/転嫁/受容]を選択する。
## 理由
- [根本原因に基づく理由]
- [トレードオフの考慮]
## 結果
- 期待される効果:
- 受け入れるリスク: