Interview Bank

Agent Skills in 7 Days: Turn Experience Into Reusable Capability

D5 Hand-Building a Skill Runtime: Scanning, Frontmatter Parsing, Injecting the System Prompt, Reading the Body on Demand

• If you implemented skill support in your own agent, what happens in the discovery stage versus the activation stage, and why split them?如果让你自己给一个 Agent 实现 skill 支持，发现阶段和激活阶段各要做什么？为什么要分成两步？

  Common in ChinaCommon overseasIntermediate#agent-skills#runtime#progressive-disclosure

  How to reason about it · think before answering

  1. This tests whether progressive disclosure is a mechanism you could build, not a slogan. Repeating the three stage names is not enough; say what each stage reads and where it writes.
  2. Discovery: scan the conventional directories, find every folder containing SKILL.md, parse out name and description, and assemble a catalog injected into the system prompt. No body text enters here; each entry carries only name, description and location.
  3. Activation: once the model judges that a task matches a description, read that full SKILL.md into context, along with the skill directory path and a list of bundled resource files.
  4. The reason for the split is an asymmetry in cost: disclosure is paid every turn, activation is paid once. The system prompt is resent with every request, so each extra character in the catalog is multiplied by the number of turns.
  5. That asymmetry also explains the spec's hard limits: descriptions are capped and bodies are not, and descriptions must state trigger conditions rather than usage instructions, because the description is the part that keeps costing money.
  6. Expected follow-up: can the location field be dropped? No. The model needs it to know which file to read, and its parent directory is the base for every relative path in the body.

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

  1. 这题在考你有没有把渐进式加载当成一个可实现的机制，而不是一句口号。只复述「发现、激活、执行」三个词是不够的，要落到每一步读了什么、写进了哪里。
  2. 发现：扫描约定目录，把所有含 SKILL.md 的文件夹找出来，解析出名字与描述，拼成一份清单注入系统提示。**这一步正文一个字都不进来**，清单里只有名字、描述、位置三样。
  3. 激活：模型判断当前任务命中了某条描述，才去读那一份完整的 SKILL.md，把正文放进上下文，同时告诉它技能目录在哪、附带哪些资源文件。
  4. 分两步的理由是成本结构不对称，这是本题的核心句：**披露的成本每一轮都要付，激活的成本只付一次。** 系统提示随每次请求重发，清单每多一个字都要乘会话轮数；正文只在被激活的那一轮进上下文，之后作为历史消息留着。
  5. 由这条不对称性可以顺手解释规范里的硬约束：为什么描述有长度上限而正文没有，为什么描述必须写触发条件而不是使用说明——描述是每轮都在花钱的那一段。
  6. 可预期的追问是「位置这一项能不能省」。不能：模型要靠它知道去读哪个文件，而且它的父目录是正文里所有相对路径的解析基准。

  Key points

  • Discovery scans directories, parses name and description, and injects a catalog into the system prompt with no body text.
  • Activation reads the full SKILL.md and adds the skill directory plus a list of bundled resource filenames.
  • The split exists because disclosure is paid every turn while activation is paid once.
  • That asymmetry explains why descriptions are length-capped and must state triggers rather than usage.
  • The location field is required: it is both the read target and the base for relative paths.

  答题要点

  • 发现阶段扫描目录、解析名字与描述、拼成清单注入系统提示，正文不进来。
  • 激活阶段才读完整 SKILL.md，并附上技能目录与资源文件名清单。
  • 分两步的根据是披露每轮付费、激活只付一次这条不对称性。
  • 这条不对称性解释了描述为什么有长度上限、为什么要写触发条件而不是使用说明。
  • 清单里位置字段不能省，它既是读取目标也是相对路径的解析基准。
• When your runtime parses a SKILL.md that violates the spec, do you refuse to load it or degrade gracefully? And how do you handle a name collision across scopes?你的运行时解析到一份不合规范的 SKILL.md，是拒绝加载还是降级加载？另外，两个作用域里有同名 skill 时你怎么处理？

  Common in ChinaCommon overseasIntermediate#agent-skills#runtime#error-handling

  How to reason about it · think before answering

  1. Both halves share one stance: a runtime exists to get work done, not to validate. State that first.
  2. For loose loading, give a decidable boundary. The only hard rejection is a missing description: without it the skill has no trigger surface, can never be selected, and only wastes catalog tokens.
  3. Everything else warns and still loads: a name that differs from the directory, a name using capitals or underscores, an over-long description. These hurt quality but not usability.
  4. Cite the most common malformation as evidence: an unquoted colon inside a YAML value makes a strict parser reject the whole file. The right fallback order is full YAML parsing first, then a line-wise field reader that extracts only the scalar fields you know.
  5. For collisions, the direction matters less than the handling. The cross-client convention is project over user, while Claude Code orders enterprise, personal, then project. Both are defensible; pick one and stay consistent.
  6. The worst handling is silent discard. The user edits the project copy, nothing changes, and they suspect caching or a failed save rather than a same-named skill elsewhere. Always log a warning that prints both paths.
  7. Expected follow-up: does loose loading let bad skills in? These are different layers. Looseness is format tolerance; safety comes from source trust and tool permissions, not from schema validation.

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

  1. 两个小问共用一个立场：**运行时是给人干活的，不是校验器。** 先把这句说出来，后面两半都好答。
  2. 宽松加载这一半要给出可判定的边界，不能只说「尽量宽松」。**唯一的硬性淘汰是缺 description**——少了它这个 skill 在发现阶段没有触发面，永远不会被选中，留在清单里只是白占 token。
  3. 其余一律只告警仍然加载：名字与目录名不一致、名字用了大写或下划线、描述超过上限。它们影响质量，不影响能不能用。
  4. 举一个最常见的畸形做证据：YAML 值里没加引号的冒号会让正规解析器判整行非法，进而拒绝整个文件。正确的兜底顺序是先用完整 YAML 解析，失败了再退回按行取值，只抠出认识的那几个标量字段。
  5. 同名冲突这一半，方向不是重点，**处理方式才是**。跨客户端通行约定是项目级压过用户级，但 Claude Code 的顺序是企业级、个人级、项目级由高到低，两种都合理，关键是固定一种并保持一致。
  6. 最糟的做法是静默丢弃：用户改了项目里那份，行为一点没变，他会去怀疑缓存和保存，就是不会想到别处有个同名的。**必须留一条警告并把两个路径都打出来**，那条日志是排查这类问题的第一现场。
  7. 可预期的追问是「宽松会不会把坏 skill 放进来」。答案是这两件事的层次不同：宽松说的是格式容错，安全靠的是来源信任与工具权限，不能拿格式校验当安全边界。

  Key points

  • A runtime is not a validator; degrade by default.
  • The only hard rejection is a missing description, which leaves no trigger surface.
  • Name mismatches, invalid names and over-long descriptions warn but still load.
  • Parse with full YAML first, then fall back to line-wise field reading for unquoted colons.
  • Fix one collision priority, keep it consistent, and never discard silently: log both paths.

  答题要点

  • 立场是运行时不是校验器，默认降级加载。
  • 唯一硬性淘汰是缺 description，因为它没有触发面、永远不会被选中。
  • 名字不一致、名字不合规、描述超长都只记诊断仍然加载。
  • 解析顺序是先完整 YAML、失败再按行取值兜底，专治值里没加引号的冒号。
  • 同名冲突要固定一种优先级并保持一致，绝不静默丢弃，警告里要带上两个路径。