菜单
ルール遵守と創造的な問題解決のバランスを取るためのフレームワーク。 Anthropic のエージェント設計に関する研究に基づく。 使用場面: - 複数の有効なアプローチがある複雑な判断に直面した場合 - 状況に対して指示が過度に規範的に感じられる場合 - ガイドラインを特定のコンテキストに適応させる必要がある場合 - 精度要件と革新的なソリューションのバランスを取る場合 Trigger phrases: think creatively, use judgment, adapt approach, better solution, flexibility
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
設定ファイルとソースコードからプロジェクトの技術スタックを自動検出。 Use when: 新規コードベースでの作業開始、言語/フレームワーク/ツールの特定。 Trigger phrases: detect stack, what framework, identify technology, project setup
REST、GraphQL、gRPC の API 設計パターン。 Use when: API の新規設計、OpenAPI 仕様作成、バージョニング/ページネーション設計。 Trigger phrases: API design, REST endpoint, GraphQL schema, OpenAPI, gRPC, pagination
エバリュエーター・オプティマイザーのフィードバックループによる反復改善。 Use when: 出力品質の反復改善、明確な評価基準がある複雑な出力の最適化。 Trigger phrases: iterate, refine, improve quality, feedback loop, evaluate and optimize
曖昧なリクエストを明確にするための構造化された要件インタビューフレームワーク。使用場面: - ユーザー要件が不明確または不完全な場合 - 新機能を開始し要件を収集する必要がある場合 - ユーザーのニーズ、制約、優先順位を理解する必要がある場合 - ビジネスリクエストを技術仕様に変換する場合 - ユーザーが詳細なしに「～したい」「～を追加して」と言う場合 Trigger phrases: gather requirements, clarify request, what do you need, interview user, requirements gathering, unclear request
すべてのユーザー向けコンテンツに日本語出力を強制する。 使用場面: - エージェント出力を日本語にする必要がある場合 - レスポンス全体の言語の一貫性を検証する場合 - 仕様書やドキュメントを日本語で生成する場合 Trigger phrases: Japanese, 日本語, language mode, output language
あらゆる技術スタックに適用可能なコアセキュリティ原則と実践。使用場面: - 認証、認可、アクセス制御の実装 - 機密データの取り扱い（パスワード、PII、シークレット、トークン） - ユーザー入力や API ペイロードのバリデーション - セキュリティ脆弱性のコードレビュー - 暗号化、ハッシュ化、暗号技術の使用 - OWASP Top 10 脆弱性への対応 Trigger phrases: security review, auth implementation, password handling, input validation, XSS, SQL injection, CSRF, secrets management, OWASP
| name | bounded-autonomy |
| description | ルール遵守と創造的な問題解決のバランスを取るためのフレームワーク。 Anthropic のエージェント設計に関する研究に基づく。 使用場面: - 複数の有効なアプローチがある複雑な判断に直面した場合 - 状況に対して指示が過度に規範的に感じられる場合 - ガイドラインを特定のコンテキストに適応させる必要がある場合 - 精度要件と革新的なソリューションのバランスを取る場合 Trigger phrases: think creatively, use judgment, adapt approach, better solution, flexibility |
| allowed-tools | Read, AskUserQuestion |
| model | inherit |
| user-invocable | false |
厳格なルール遵守と創造的な問題解決のバランスを取るための意思決定フレームワーク。
Claude Code Best Practices より:
"Claude often performs better with high level instructions to just think deeply about a task rather than step-by-step prescriptive guidance. The model's creativity in approaching problems may exceed a human's ability to prescribe the optimal thinking process."
要約: 指示の文字通りではなく、精神に従う。ゴールと制約は固定、方法は柔軟。
これらは絶対的な制約。どんなに良い理由があっても例外なし。
本ツールキットでの例:
識別キーワード: NEVER, ALWAYS, MUST, CRITICAL
デフォルトで従うが、明確な理由があればオーバーライド可能。
例:
オーバーライドパターン:
デフォルトルール: [X]
状況: [デフォルトが適さない理由]
代替案: [代わりに行うこと]
トレードオフ: [得るもの/失うもの]
代替案で進める理由: [推論]
考慮すべき提案。コンテキストに応じて自由に適応。
例:
厳格な遵守とより良いアプローチの選択に直面した場合:
┌─────────────────────────────────────────────────────────┐
│ 意思決定プロセス │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. ゴールを特定（成功とはどのような状態か） │
│ │
│ 2. L1 制約をすべてリスト（交渉不可） │
│ │
│ 3. アプローチを検討: │
│ - 規定されたアプローチ（あれば） │
│ - 代替アプローチ │
│ │
│ 4. 各アプローチについて検証: │
│ ✓ ゴールを達成するか？ │
│ ✓ すべての L1 制約を満たすか？ │
│ ✓ トレードオフは何か？ │
│ │
│ 5. ゴールを最もよく達成し、 │
│ すべての L1 制約を尊重するアプローチを選択 │
│ │
│ 6. 規定されたアプローチから逸脱する場合: │
│ → 理由を簡潔に説明 │
│ → L1 準拠を確認 │
│ → 実行 │
│ │
└─────────────────────────────────────────────────────────┘
複雑なソリューションを実装する前に検討:
## 振り返り
1. **ゴールの明確さ**: 成功とはどのような状態か？
2. **制約チェック**: 破ってはいけない L1 ルールは何か？
3. **アプローチ評価**: 規定されたアプローチはここで最適か？
4. **代替案**: 他にどのようなアプローチが有効か？
5. **トレードオフ**: 各アプローチで何を得て何を失うか？
6. **決定**: どのアプローチがゴールに最も役立つか？
アプローチを適応する場合:
良い例:
標準的なアプローチは X を推奨していますが、[コンテキスト] を考慮し、
[理由] により Y を代わりに使用します。
これは [制約] を満たしつつ、[ゴール] をより良く達成します。
悪い例:
X の代わりに Y を行います。
（理由なし、制約確認なし）
SDD の plan→review→implement ワークフローは構造を提供する。各フェーズ内で:
| フェーズ | 固定（L1/L2） | 柔軟（L3） |
|---|---|---|
計画（/spec-plan） | 要件を理解し、コードベースを探索 | 情報収集方法、調査するファイル |
レビュー（/spec-review） | ユーザー承認を取得 | レビューの深さ、質問の焦点 |
実装（/spec-implement） | 仕様に従い、品質チェック | コーディングパターン、エージェント選択 |
コンテキストがより良いアプローチを示唆しているのに機械的にステップに従う。
例: 一行のタイポ修正に完全な plan→review→implement を実行。
改善: /quick-impl と判断を使用。
「自分の方がよく知っている」として L1 ルールを無視する。
例: コードが「安全に見える」のでセキュリティレビューをスキップ。 許容されない: L1 ルールには存在理由がある。
アクションが明確な場合に過度に考え込む。
例: 明白な実装に対する広範な検討。 改善: 明確なケースには行動し、不明確なケースに熟考する。