菜单
ルール遵守と創造的な問題解決のバランスを取るためのフレームワーク。 Anthropic のエージェント設計に関する研究に基づく。 使用場面: - 複数の有効なアプローチがある複雑な判断に直面した場合 - 状況に対して指示が過度に規範的に感じられる場合 - ガイドラインを特定のコンテキストに適応させる必要がある場合 - 精度要件と革新的なソリューションのバランスを取る場合 Trigger phrases: think creatively, use judgment, adapt approach, better solution, flexibility
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/MysMon/Spec-Workflow-Toolkit --skill bounded-autonomy命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
設定ファイルとソースコードからプロジェクトの技術スタックを自動検出。 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
正在显示 SKILL.md
基于 SOC 职业分类
| 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 ルールには存在理由がある。
アクションが明確な場合に過度に考え込む。
例: 明白な実装に対する広範な検討。 改善: 明確なケースには行動し、不明確なケースに熟考する。