[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69B00R9BDFSQJJ5M8Q09WXY":3,"skill-same:01M69B00R9BDFSQJJ5M8Q09WXY":62},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":45,"ownerDescription":46,"updatedAt":47,"install":48,"resources":61},"01M69B00R9BDFSQJJ5M8Q09WXY","amplifier-philosophy",null,"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.","microsoft\u002Famplifier-bundle-skills","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69AZYFW50CECTV9VW6B34SE",12,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fmodules\u002Ftool-skills\u002Ftests\u002Ffixtures\u002Fskills\u002Famplifier-philosophy\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[24,25,26,27,28,29,30],"amplifier philosophy","design","kernel","linux","policy","design philosophy","architecture","2026-11-10 10:12:30",false,"---\nname: amplifier-philosophy\ndescription: 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.\nversion: 1.0.0\nlicense: MIT\nmetadata:\n  category: architecture\n  complexity: medium\n---\n\n# Amplifier Philosophy: The Linux Kernel Metaphor\n\n## Core Principle: Mechanism Not Policy\n\n**If two teams might want different behavior, it belongs in a module, not the kernel.**\n\nThe kernel provides mechanisms (mount, emit, dispatch). Modules provide policies (what to mount, when to emit, how to handle).\n\n## Architecture Patterns\n\n### Kernel (amplifier-core)\n\n**Keep it minimal and stable:**\n- Session management (`session_create`, `mount`, `unmount`)\n- Event emission (`emit`)\n- Hook registration\n- Context access\n\n**Never add to kernel:**\n- Provider selection\n- Tool routing\n- Plan generation\n- Default behaviors\n- File I\u002FO\n\n### Modules (Everything Else)\n\n**All capabilities as modules:**\n- **Providers**: LLM backends (Anthropic, OpenAI, Ollama)\n- **Tools**: Capabilities (filesystem, bash, web)\n- **Orchestrators**: Execution strategies\n- **Context Managers**: State management\n- **Hooks**: Lifecycle observers\n\n## Mount Point System\n\nThink of modules as **devices mounted at paths**:\n\n```\n\u002Fmnt\u002Fproviders\u002F{name}  - LLM backends\n\u002Fmnt\u002Ftools\u002F{name}      - Agent capabilities\n\u002Fmnt\u002Fhooks\u002F{event}     - Lifecycle observers\n\u002Fmnt\u002Fcontext           - Conversation state\n\u002Fmnt\u002Forchestrator      - Execution loop\n```\n\nEach mount point has a **stable connector** (Protocol interface).\n\n## Event-Driven Design\n\n**If it's important, emit an event:**\n\n- `session:start`, `session:end`\n- `prompt:submit`, `prompt:complete`\n- `provider:request`, `provider:response`\n- `tool:pre`, `tool:post`\n- `context:pre_compact`, `context:post_compact`\n\n**Hooks observe, never interfere:**\n- Logging hooks record events\n- Approval hooks check permissions\n- Cost tracking hooks monitor usage\n- Failures in hooks never stop execution\n\n## Module Development Checklist\n\nWhen creating a new module:\n\n1. ✅ **Implements Protocol only** - No kernel internals\n2. ✅ **Emits canonical events** - Observable lifecycle\n3. ✅ **Handles own failures** - Never crash kernel\n4. ✅ **Configuration via mount()** - No hard-coded defaults\n5. ✅ **Entry point registration** - Discoverable\n\n## Decision Framework\n\n### Is This Kernel Work?\n\nAsk: \"Would every team use this the exact same way?\"\n\n- **Yes** → Might be kernel (rare)\n- **No** → Definitely a module\n\n### Extract to Kernel?\n\nOnly after:\n- Two real implementations exist\n- Clear convergence on mechanism\n- No opinion baked in\n\n### Prefer Regeneration\n\n- **Don't patch modules** - Regenerate from spec\n- **Keep connectors stable** - Module internals can change\n- **Update spec, rebuild module** - Not line-by-line edits\n\n## Remember\n\n**Ruthless simplicity.** If two designs solve it, pick the one with fewer moving parts and clearer failure modes.\n\n**Modules compete at edges.** The kernel enables them, doesn't choose between them.\n\n**Observability is mandatory.** If it's not in the logs, it didn't happen.\n","# Amplifier Philosophy: The Linux Kernel Metaphor\n\n## Core Principle: Mechanism Not Policy\n\n**If two teams might want different behavior, it belongs in a module, not the kernel.**\n\nThe kernel provides mechanisms (mount, emit, dispatch). Modules provide policies (what to mount, when to emit, how to handle).\n\n## Architecture Patterns\n\n### Kernel (amplifier-core)\n\n**Keep it minimal and stable:**\n- Session management (`session_create`, `mount`, `unmount`)\n- Event emission (`emit`)\n- Hook registration\n- Context access\n\n**Never add to kernel:**\n- Provider selection\n- Tool routing\n- Plan generation\n- Default behaviors\n- File I\u002FO\n\n### Modules (Everything Else)\n\n**All capabilities as modules:**\n- **Providers**: LLM backends (Anthropic, OpenAI, Ollama)\n- **Tools**: Capabilities (filesystem, bash, web)\n- **Orchestrators**: Execution strategies\n- **Context Managers**: State management\n- **Hooks**: Lifecycle observers\n\n## Mount Point System\n\nThink of modules as **devices mounted at paths**:\n\n```\n\u002Fmnt\u002Fproviders\u002F{name}  - LLM backends\n\u002Fmnt\u002Ftools\u002F{name}      - Agent capabilities\n\u002Fmnt\u002Fhooks\u002F{event}     - Lifecycle observers\n\u002Fmnt\u002Fcontext           - Conversation state\n\u002Fmnt\u002Forchestrator      - Execution loop\n```\n\nEach mount point has a **stable connector** (Protocol interface).\n\n## Event-Driven Design\n\n**If it's important, emit an event:**\n\n- `session:start`, `session:end`\n- `prompt:submit`, `prompt:complete`\n- `provider:request`, `provider:response`\n- `tool:pre`, `tool:post`\n- `context:pre_compact`, `context:post_compact`\n\n**Hooks observe, never interfere:**\n- Logging hooks record events\n- Approval hooks check permissions\n- Cost tracking hooks monitor usage\n- Failures in hooks never stop execution\n\n## Module Development Checklist\n\nWhen creating a new module:\n\n1. ✅ **Implements Protocol only** - No kernel internals\n2. ✅ **Emits canonical events** - Observable lifecycle\n3. ✅ **Handles own failures** - Never crash kernel\n4. ✅ **Configuration via mount()** - No hard-coded defaults\n5. ✅ **Entry point registration** - Discoverable\n\n## Decision Framework\n\n### Is This Kernel Work?\n\nAsk: \"Would every team use this the exact same way?\"\n\n- **Yes** → Might be kernel (rare)\n- **No** → Definitely a module\n\n### Extract to Kernel?\n\nOnly after:\n- Two real implementations exist\n- Clear convergence on mechanism\n- No opinion baked in\n\n### Prefer Regeneration\n\n- **Don't patch modules** - Regenerate from spec\n- **Keep connectors stable** - Module internals can change\n- **Update spec, rebuild module** - Not line-by-line edits\n\n## Remember\n\n**Ruthless simplicity.** If two designs solve it, pick the one with fewer moving parts and clearer failure modes.\n\n**Modules compete at edges.** The kernel enables them, doesn't choose between them.\n\n**Observability is mandatory.** If it's not in the logs, it didn't happen.\n",{"name":5,"license":15,"version":36,"metadata":37,"description":7},"1.0.0",{"category":30,"complexity":38},"medium","main","2f58408a879535df36da5c92d2b073f49271ade4","modules\u002Ftool-skills\u002Ftests\u002Ffixtures\u002Fskills\u002Famplifier-philosophy",11,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 16:43:43",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add microsoft\u002Famplifier-bundle-skills --skill amplifier-philosophy",{"tool":54,"command":55},"bunx","bunx skills add microsoft\u002Famplifier-bundle-skills --skill amplifier-philosophy",{"tool":57,"command":58},"pnpm","pnpm dlx skills add microsoft\u002Famplifier-bundle-skills --skill amplifier-philosophy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fmodules\u002Ftool-skills\u002Ftests\u002Ffixtures\u002Fskills\u002Famplifier-philosophy\u002FSKILL.md",true,[],[63,73,83,96,107,119],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":31},"01M69B282M59QZNMM26JXA1QCV","verification-discipline","Use when verifying that completed work actually works. Auto-surface during \u002Fverify mode, post-implementation review, or before claiming a task is done. Teaches testing outcomes vs implementation, the unit\u002Fintegration\u002Fsmoke gradient, and what \"done\" actually means.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fverification-discipline\u002FSKILL.md",[],[70,71,72],"verification discipline","review","testing",{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":31},"01M69B263M6BFCVAV3SEESV7T0","user-advocate","User-need reviewer that speaks for the person who isn't in the room — the one who will actually live with what gets built. Hunts the gap between \"we can build this\" and \"they actually want this,\" in the patient, impatient voice of the absent user. Use at any checkpoint — brainstorm, design, plan, implement, debug, review — when a feature is being built because it's buildable rather than wanted, the recovery path is missing, or nobody can name the person this serves: \"do they actually want this, and can they live with it?\"","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fuser-advocate\u002FSKILL.md",[],[80,81,82,71,25],"user advocate","debug","implement",{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":94,"publishedAt":31},"01M69B23EQQM30TMZG7FPJW4F7","tester-breaker","Adversarial breaker that reviews code by trying to make it fail, not by confirming it works. Hunts the unhappy paths — malformed input, the empty string, the reversed range, the race condition — as a gleeful adversary who assumes everything is broken until a concrete attempt to break it comes up empty. Use at any checkpoint — brainstorm, design, plan, implement, debug, review — when the happy path is celebrated while the edges sit unexamined, \"looks fine\" stands in for \"I tried to break it and couldn't,\" or nobody has named the input that makes this fall over: \"how does this fail, and where are the edges?\"","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftester-breaker\u002FSKILL.md",[89],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[95,71,81,82,25],"tester breaker",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":31},"01M69B21AHBXP6EK60XYDP24PY","skills-assist","Authoritative consultant for all skills-related questions. Use when creating or modifying skills, understanding the Agent Skills spec, troubleshooting skill loading or invocation issues, leveraging enhanced format features (context fork, model_role, user-invocable), writing cross-harness portable skills, ensuring Claude Code Skills 2.0 compatibility, or deciding between skills vs agents.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fskills-assist\u002FSKILL.md",[],[103,104,105,106],"skills assist","claude code skills","spec","writing",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":116,"publishedAt":31},"01M69B1ZBHGE1PAX0E7ZDS8HQZ","skillify","Capture a repeatable process from the current session into a reusable Amplifier SKILL.md skill file. Use when the user wants to create a skill, save a workflow as a skill, turn a process into a reusable skill, or mentions \"skillify\", \"create skill\", \"make a skill\", \"save as skill\", \"capture workflow\", \"turn this into a skill\", \"new skill\", or wants to automate a repeatable process they just performed.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fskillify\u002FSKILL.md",[113],{"categoryNo":114,"categoryName":115,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[109,117,118],"create skill","workflow",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":126,"publishedAt":31},"01M69B1XCPQFAXS9RTS87CZ8EK","session-debug","Diagnose issues in the current Amplifier session — misconfigured tools, failing operations, unexpected behavior. Use when something isn't working right.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsession-debug\u002FSKILL.md",[125],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},[127,81,128],"session debug","diagnose"]