菜单
設計・計画段階で自律的にリスクアセスメントを行うメタスキルです。 行動する前に自問自答し、浅い解決策を避け、根本的な問題を特定します。 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 | risk-assessment |
| description | 設計・計画段階で自律的にリスクアセスメントを行うメタスキルです。 行動する前に自問自答し、浅い解決策を避け、根本的な問題を特定します。 Trigger: 設計, 計画, 実装前, アーキテクチャ決定, リスク, 懸念 |
| user-invocable | false |
実装や行動に移る前に、自分自身に問いを投げかけ、深い思考を行う。
リスクを特定したら、以下の4戦略から選択する：
| 戦略 | 意味 | 適用場面 |
|---|---|---|
| 回避 | リスクを発生させる活動をやめる | 影響が致命的で代替手段がある |
| 軽減 | 発生確率や影響度を下げる | コストと効果のバランスが取れる |
| 転嫁 | 第三者に移転する | 専門性が必要、保険で対応可能 |
| 受容 | 認識した上で受け入れる | 影響が軽微、対策コストが見合わない |
プロジェクト固有の重要な意思決定は ./docs/adr にADRとして記録する。
ADRは時間経過で陳腐化しないストック情報とする。現在形で記述する。
| NG | OK |
|---|---|
| 〜した（過去形） | 〜する（現在形） |
| 現在〜している | 〜である |
| 今後〜する予定 | 〜する方針である |
| 最近〜が発生した | 〜という問題がある |
採用
VPC Endpoint + NLB構成はTeam Planでのみ利用可能である。
Public ALBを採用する。
| タイミング | 適用する問い |
|---|---|
| Plan Mode突入時 | 前提の検証、代替案の検討 |
| 実装開始前 | 深さの検証、設計判断 |
| PR作成前 | リスクの洗い出し → 対応戦略の選択 |
| エラー発生時 | なぜなぜ分析 |
| 重要な意思決定時 | ADRとして ./docs/adr に記録 |
| 振る舞い | 問題 | 代わりに |
|---|---|---|
| 言われたことをそのまま実行 | 前提が間違っている可能性 | 「本当に必要か」を問う |
| 症状だけ治す | 再発する | 根本原因まで掘り下げる |
| 一つの方法だけ提案 | 最適解でない可能性 | 代替案を検討する |
| 「連携」「統合」で終わる | 手段が目的化 | 具体的な価値を明示 |
