菜单
Amplifier design philosophy using Linux kernel metaphor. Covers mechanism vs policy, module architecture, event-driven design, and kernel principles. Use when designing new modules or making architectural decisions.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/microsoft/amplifier-bundle-skills --skill amplifier-philosophy命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Delivery-risk reviewer that sizes the investment a plan is asking for against the team's actual confidence that it will land, and names specifically what's most likely to make it slip or fail to ship at all. Hunts the plan that asks for a six-month bet with three-week confidence, or hides its biggest unknown behind a confident-sounding timeline. Sounds like a delivery lead who has watched too many "should be straightforward" estimates blow up on the one unknown nobody named out loud. Not a cost reviewer — a bet-sizing reviewer. A lens for any product checkpoint — plan, roadmap, or investment/sequencing decision. Use when: a timeline is stated with more confidence than the team actually has, a plan's riskiest unknown is buried in a status update instead of named up front, or nobody has said what would make this slip — any time the worry is "what's most likely to make this slip or fail to land, and is the investment sized to our confidence?"
Outcome-validity reviewer that refuses to accept a feature list, a roadmap item, or a shipped deliverable as evidence of progress until it is mapped to a measurable change in customer or business behavior. Hunts the gap between "we shipped it" and "we moved the number" — the output that was mistaken for an outcome. Sounds like a product leader who has watched too many roadmaps full of "done" work that moved nothing, and now refuses to plan without a named, instrumented metric. Not a goal-validity reviewer — a reviewer of whether the plan can prove it worked, and how. A lens for any product checkpoint — plan, roadmap, PRD, or ship review. Use when: a plan lists deliverables without a metric attached, "done" is being confused with "worked," or nobody can say how success will be measured after ship — any time the worry is "what measurable outcome defines success here, and how will we know we moved it?"
Outcome-clarity reviewer that questions whether you've defined what you're trying to achieve, validated the problem exists, and can defend it in plain language. Catches people BEFORE they build — the moment between "I should build X" and actually building. Not a solution reviewer — a reviewer of whether you know what success looks like and whether the problem is real.
正在显示 SKILL.md
基于 SOC 职业分类
| name | amplifier-philosophy |
| description | Amplifier design philosophy using Linux kernel metaphor. Covers mechanism vs policy, module architecture, event-driven design, and kernel principles. Use when designing new modules or making architectural decisions. |
| version | 1.0.0 |
| license | MIT |
| metadata | {"category":"architecture","complexity":"medium"} |
If two teams might want different behavior, it belongs in a module, not the kernel.
The kernel provides mechanisms (mount, emit, dispatch). Modules provide policies (what to mount, when to emit, how to handle).
Keep it minimal and stable:
session_create, mount, unmount)emit)Never add to kernel:
All capabilities as modules:
Think of modules as devices mounted at paths:
/mnt/providers/{name} - LLM backends
/mnt/tools/{name} - Agent capabilities
/mnt/hooks/{event} - Lifecycle observers
/mnt/context - Conversation state
/mnt/orchestrator - Execution loop
Each mount point has a stable connector (Protocol interface).
If it's important, emit an event:
session:start, session:endprompt:submit, prompt:completeprovider:request, provider:responsetool:pre, tool:postcontext:pre_compact, context:post_compactHooks observe, never interfere:
When creating a new module:
Ask: "Would every team use this the exact same way?"
Only after:
Ruthless simplicity. If two designs solve it, pick the one with fewer moving parts and clearer failure modes.
Modules compete at edges. The kernel enables them, doesn't choose between them.
Observability is mandatory. If it's not in the logs, it didn't happen.