feat(skills): parallelize loading + add path-conditional activation

[BingqingLyu]

Summary

Three commits on the new path-conditional-skill activation pipeline, in build order:

Commit	Type	What
99b9fe4de	perf	Replace three nested for-await loops in SkillManager (refreshCache, listSkillsAtLevel, loadSkillsFromDir) with Promise.all; cold-start I/O fans out at every layer of the skill discovery tree.
5432f5ddc	feat	Path-conditional skill activation. Skills with a paths: glob in frontmatter stay out of the model-facing <available_skills> listing until a tool call touches a matching file path, at which point they activate for the rest of the session. Mirrors the existing ConditionalRulesRegistry design.
160462344	fix	Two activation-pipeline bugs surfaced by /ultrareview. Detail in the Audit history section below.

Why

• Cold-start serialization. Three serial layers (level → provider dir → skill dir, each with its own stat/access/parse) meant cold start scaled as n_levels * n_provider_dirs * n_skills filesystem hops, all sequential.
• Per-turn token cost in large monorepos. The SkillTool description ships with every API call. With 100+ skills installed, the listing alone is ~600–1500 tokens of overhead the model rarely needs. Letting skills opt into lazy activation keeps the listing scoped to the current task instead of advertising the whole catalog.

Reviewer focus

• packages/core/src/skills/skill-manager.ts — parallel fold for listSkillsAtLevel preserves provider-dir precedence (.qwen > .agent > .cursor). The activation registry is rebuilt on refreshCache; eligibility is computed by walking levels in project > user > extension > bundled order, deduping by name, and dropping disableModelInvocation skills before splitting on paths (commit 3 fix).
• packages/core/src/skills/skill-activation.ts — new picomatch-based registry, project-root scoped (refuses paths outside the project root).
• packages/core/src/tools/skill.ts — refreshSkills now also computes pendingConditionalSkillNames; validateToolParams returns a distinct "gated by path-based activation" error so the model can tell not found from registered but not yet active. Critically, the model-invocable-commands dedup key uses allSkills (not availableSkills) to keep path-gated skills from leaking through <available_commands>.
• packages/core/src/core/coreToolScheduler.ts — file-path activation hook lives next to the existing ConditionalRulesRegistry hook and emits a <system-reminder> so the model learns why its tool listing just grew.

Audit history

This PR went through three rounds of automated review during development. The trail is preserved here because it explains why the diff has the shape it does:

1. In-development /review (qwen-code, gpt-5.5) — caught a defect in SkillTool.refreshSkills: the model-invocable-commands dedup key was sourced from availableSkills (already filtered) rather than allSkills, so a path-gated skill could leak into <available_commands> and bypass the activation contract. Folded into commit 2 with a regression test.
2. /ultrareview (Claude, multi-agent) — surfaced two more issues in the activation registry, both at the refreshCache site:
   • bug_001 (normal): cross-level shadow leaks paths. Same skill name at multiple levels with different paths: globs. listSkills() dedupes by precedence (project wins), but the registry was built from the raw concatenation. A path matching only the shadowed copy's glob still flipped the visible copy to "active" — model would see the skill appear from a file outside its declared paths.
   • bug_004 (nit): paths: + disable-model-invocation: true contradicts itself. Such a skill would enter the registry, fire the "now available" <system-reminder> on path match, then SkillTool would refuse the invocation because the disabled flag had filtered the skill out of both availableSkills and pendingConditionalSkillNames. Model gets a generic "not found" right after being told the skill exists.
   • Both fixed in commit 3 (160462344) with regression tests.
3. Post-fix /review (qwen-code, gpt-5.5) — flagged a Critical claiming bundled-skill tests were silently skipping due to an existsSync mock gap. False positive: the fs mock at skill-manager.test.ts:39-42 wraps actual.existsSync, and the bundled fixtures (packages/core/src/skills/bundled/review/SKILL.md) are real files on disk. Verified by re-running tests locally and observing 13/13 CI matrix combos green. Reply with evidence.

Validation

• Commands run:

  npm run lint                              # passed
  npm test                                  # 10,959 passed / 10 skipped / 0 failed across all workspaces
  npx vitest run packages/core/src/skills/ \
                 packages/core/src/tools/skill.test.ts \
                 packages/core/src/core/coreToolScheduler.test.ts
                                            # 200 passed across 5 files

  Full output captured via tmux; see the local-validation comment.
• Expected result: skill loading parallelizes; conditional skills with paths: stay hidden from the model-facing <available_skills> listing until a matching file is touched; user-invocation paths (/skill-name, /skills picker) are unaffected; bundled and unconditional skills behave exactly as before.
• Observed result: matches expectations. CI green across mac/ubuntu/windows × Node 20/22/24.
• Quickest reviewer verification path:

  gh pr checkout 3604
  npx vitest run packages/core/src/skills/ packages/core/src/tools/skill.test.ts

  Expected: 5 files, 131 tests pass.

Scope / Risk

• Main risk or tradeoff:
  • Activation state is intentionally scoped to a single registry instance; a watcher-driven refreshCache (e.g. user edits a skill file) wipes prior activations. Same semantics as ConditionalRulesRegistry. Documented in the new code.
  • Parallel parseSkillFileInternal calls write parseErrors concurrently. The Map's iteration order now reflects parse-finish order rather than on-disk order; the only consumer (tools/skill.ts:339) does not depend on order. Comment in loadSkillsFromDir notes the contract.
• Not covered / not validated: Bun runtime — no Bun-specific code path was added; PR doesn't change watcher behavior.
• Breaking changes / migration notes: None. paths: in skill frontmatter is purely additive: skills without it behave exactly as before. The new <system-reminder> only fires when a conditional skill activates, so existing skills produce no extra output.

Testing Matrix

	🍏	🪟	🐧
npm run	✅	✅	✅
npx	⚠️	⚠️	⚠️
Docker	⚠️	⚠️	⚠️
Podman	⚠️	N/A	N/A
Seatbelt	⚠️	N/A	N/A

Testing matrix notes:

• npm run row covered by CI (Test (macos/ubuntu/windows-latest, 20.x|22.x|24.x) — 9 jobs, all green).
• macOS additionally verified locally (npm test, npm run lint, full skill-area subset).
• Other rows rely on existing CI; no Docker/Podman/Seatbelt-specific code changed.

Linked Issues / Bugs

References item-28 of the qwen-code engine improvement report (parallel skill loading + path-conditional activation). No GitHub issue tracked.