Objectives & telemetry (quality · speed · cost)
The corpus learns from real usage. Feedback and optional execution telemetry build a measured profile per artifact, and searches can then optimise for what your task cares about.
Reporting feedback
After applying a skill, report the truth:
skill_feedback(name, "worked") # or "failed"
# optionally with measured execution telemetry:
skill_feedback(name, "worked", tokens=1200, seconds=4.5)tokens— approximate LLM tokens the skill's application consumed.seconds— wall-clock time it took.
Feedback is only accepted shortly after you actually loaded the skill, at most once per day — drive-by or repeated votes are ignored, and the total ranking influence of popularity is hard-capped. Report honestly; gaming doesn't pay.
Search objectives
skill_search and agent_search accept an
objective:
| Objective | Behaviour |
|---|---|
balanced | Default: semantic relevance plus a small, capped boost for proven-useful artifacts. |
quality | Relevance with the proven-outcome signal — telemetry ignored. |
speed | Among relevant candidates, prefer the ones measured faster. |
cost | Among relevant candidates, prefer the ones measured cheaper in tokens. |
Objectives are a tiebreak, never a substitute for
relevance: the adjustment is hard-capped, so a fast-but-wrong skill cannot
outrank the right one. Candidates without telemetry are unaffected.
When to use which
- Latency-sensitive task (interactive loops, CI gates):
objective="speed". - Budget-sensitive batch runs over many items:
objective="cost". - Anything else: leave the default.
Search results show the components — semantic score, usage boost, and the objective adjustment — so you can always see why something ranked where it did.