Interview Bank

Agent Skills in 7 Days: Turn Experience Into Reusable Capability

D6 Organizing and Distributing: Plugins and Marketplaces, Versioning and Team Sharing, and the Division of Labor Between Function Calling, MCP, and Skills

• A team needs to share more than a dozen skills. How would you organize and distribute them?一个团队要共享十几个 skill，你会怎么组织和分发？

  Common in ChinaCommon overseasIntermediate#agent-skills#distribution#team-governance

  How to reason about it · think before answering

  1. This tests governance, not commands. The interviewer wants your criteria for splitting packages and choosing a distribution path.
  2. Organization first. The criterion is whether they are adopted and retired together. Skills orbiting the same team convention belong in one package; a team convention and your personal habit do not, because bundling forces people to take the half they did not want. A dozen skills usually becomes three or four packages.
  3. Name two hard rules. The package name is the namespace, so skills are prefixed as package colon skill, which is where collisions are resolved; pick the name once. And component directories must sit at the plugin root, never inside the manifest directory, which is the documented top mistake.
  4. Then the three distribution paths with criteria. Ship with the repository: commit the skills alongside code, zero infrastructure, reviewed through the existing pull request flow, but scoped to that repository. Choose it for conventions tied to one codebase.
  5. Use a marketplace: a repository plus a catalog JSON, added once per person, then installed on demand with automatic updates. One place to maintain, real versions and upgrade notes, at the cost of getting everyone to add it. Private simply means a private repository; there is no central server.
  6. Organization-managed distribution: pushed centrally and not easily disabled, with guaranteed coverage and auditability, but heavy process and slow iteration. Reserve it for rules that must be enforced, such as security and compliance.
  7. Close by noting the three combine: compliance centrally managed, cross-repository conventions via a marketplace, project quirks with the repository.
  8. Expected follow-up: will a dozen skills blow up the catalog? Discovery cost scales with total description length, so governance means auditing description length and mutual exclusivity, not capping the count.

  分析过程 · 先想清楚再作答

  1. 这题考工程治理，不是考命令。面试官想听的是你按什么切包、按什么选分发路径，而不是背几条安装命令。
  2. 先讲组织。判据是**它们是否一起被采纳、一起被淘汰**：都围着同一套团队规范转、谁装了都得装全套，那就是一个包；一个是团队规范一个是你的个人习惯，凑在一起只会逼别人接受不想要的那半边。十几个 skill 通常应该切成三四个包，不是一个巨包也不是十几个碎包。
  3. 包的两条硬规矩要点出来：**包名就是命名空间**，包里的技能会被前缀成「包名冒号技能名」，撞名问题在这一层解决，所以包名要一次想好；组件目录必须在插件根下，不能塞进放清单的那个目录里，这是官方标出来的最常见错误。
  4. 再讲分发，给三条路径和各自的判据。随仓库走：直接放进项目目录跟着代码提交，零基础设施、评审走原来的流程，但只对这个仓库成立——**只跟某一个代码库有关的规范就选它**。
  5. 走市场：一个仓库加一份清单 JSON，成员各自添加一次，之后按需安装并自动收更新。一处维护多处生效、有版本、有升级说明，代价是要推动每个人添加一次。跨仓库的团队规范选它。**私有就是把市场仓库设成私有，没有中心服务器这回事。**
  6. 走组织托管：管理侧统一下发，不能随便关掉，覆盖率有保证、可审计，但流程重迭代慢，只有必须强制且不装就出事的规范才值得，比如安全合规那几条。
  7. 最后说三条不互斥，稳定组合是安全合规走托管、跨仓库规范走市场、项目独有的怪癖随仓库走。
  8. 可预期的追问是「十几个 skill 会不会把目录撑爆」。答案是发现阶段的开销只和描述总长有关，所以治理重点是**审描述的长度与互斥性**，而不是限制数量。

  Key points

  • Split by whether skills are adopted and retired together; a dozen usually becomes three or four packages.
  • The package name is the namespace where collisions are resolved, and component directories live at the plugin root.
  • Repository-scoped conventions ship with the repository: no infrastructure, no cross-repository reuse.
  • Cross-repository conventions go through a marketplace, which is just a repository plus a catalog JSON; private repo means private marketplace.
  • Mandatory compliance rules go through organization-managed distribution, and the three paths combine.

  答题要点

  • 切包的判据是它们是否一起被采纳、一起被淘汰，十几个通常切成三四个包。
  • 包名就是命名空间，撞名在这一层解决；组件目录必须在插件根下。
  • 只跟一个仓库有关的规范随仓库走，零基础设施但不跨仓库复用。
  • 跨仓库的团队规范走市场，市场就是一个仓库加一份清单 JSON，私有仓库即私有市场。
  • 必须强制的合规规范走组织托管，三条路径可以组合使用。
• Should a skill package be versioned, and what goes wrong most often on upgrade?skill 包要不要做版本管理？升级时最容易出什么问题？

  Common in ChinaCommon overseasDeep dive#agent-skills#versioning#distribution

  How to reason about it · think before answering

  1. It looks procedural but really asks what a skill's interface is. Answer that and the rest follows.
  2. Should you version? Internally you can be loose; for public distribution you must pin a version. With a version, users update only when it changes. Without one, git sources use the resolved commit, so every push updates everyone, which is tolerable inside a team and out of control outside it.
  3. Add an easily missed detail: do not set the version in both the plugin manifest and the marketplace catalog. The plugin manifest wins, and a mismatch leaves a state you cannot explain.
  4. Then the criterion. What requires a bump is not whether a file changed but whether user-visible behavior changes. A changed description, changed body steps, or changed script flags all require a bump; typos and comments do not. It is the same as releasing a library, except the interface is not a function signature.
  5. The scoring point: a skill's interface is its description and body. Everyone remembers to bump for script changes but treats a slightly sharper description as cosmetic. The description is the only trigger surface: widen it and the skill starts stealing tasks, narrow it and it silently stops firing. Every description change is a behavior change and belongs in the upgrade notes.
  6. Give two concrete upgrade traps. Renaming the package changes the namespace, so every skill's invocation name changes and any hard-coded reference breaks. Moving a skill between packages looks to users like a capability disappearing, so the upgrade notes must spell out the migration.
  7. Expected follow-up: how do you know an upgrade did not break things? Run the day-three trigger tests as a regression, comparing hit rates on the same labeled queries before and after.

  分析过程 · 先想清楚再作答

  1. 这题看着像流程题，实际考的是「skill 的接口到底是什么」。想清楚这一点，答案自然出来。
  2. 先答要不要：对内可以宽松，**对外发布必须写死版本**。写了版本，用户只在这个值变化时才收到更新，这是可控的；不写的话 Git 来源会拿提交哈希当版本，你每推一次内容用户就更一次，团队内部尚可，对外就是失控。
  3. 补一条容易忽略的细节：版本不要在包清单和市场清单两处都写，包自己的清单优先级更高，两边不一致会得到一个你自己都解释不清的状态。
  4. 接着答判据。什么改动要升版本？不是「改没改文件」，而是「**用户的行为会不会因此变化**」。描述改了、正文步骤改了、脚本参数改了都要升；修错别字、补注释不用。这跟给库发版一个道理，只不过这里的接口不是函数签名。
  5. 本题的拿分点在这里：**skill 的接口是描述与正文**。大家都记得改脚本要升版本，却常觉得「我就是把描述改得更准了一点」不算变更。但描述是唯一的触发面，改宽了会开始抢别的任务，改窄了会突然不触发。**描述的每一次改动都是行为变更**，都要在升级说明里单独写一行。
  6. 再给两个升级期的具体坑。一是改包名：包名是命名空间，改名等于把包里所有技能的调用名全改了，用户那边所有写死调用名的地方一起断。二是拆包与合包：一个 skill 从 A 包挪到 B 包，对用户来说是「装了 A 的人突然少了一个能力」，必须在升级说明里显式写迁移步骤。
  7. 可预期的追问是「怎么知道升级没升坏」。答案是把第三天那套触发测试当回归跑：改描述前后各跑一次同一组正负例，比触发率而不是凭感觉。

  Key points

  • Loose internally, pinned for public release; without a version, git sources update on every commit.
  • Never set the version in both the plugin manifest and the marketplace catalog; the plugin manifest wins.
  • Bump when user-visible behavior changes, not when a file changes.
  • A skill's interface is its description and body, and every description change is a behavior change.
  • Renaming the package rewrites every invocation name, moving a skill across packages needs migration notes, and trigger tests serve as upgrade regression.

  答题要点

  • 对内可宽松，对外发布必须写死版本；不写版本时 Git 来源按提交更新，等于失控。
  • 版本不要在包清单与市场清单两处都写，包清单优先。
  • 升不升版本看用户行为会不会变，不看改没改文件。
  • skill 的接口是描述与正文，描述的每一次改动都是行为变更，最容易被漏掉。
  • 改包名会改掉全部调用名，跨包挪动 skill 要写迁移步骤；用触发测试做升级回归。