- name
- skill-radar
- description
- Search relevant locally installed skills first, then available plugins and online catalogs; ask the user before invoking or installing any match. Use for the first substantive user request in every session, and when a user asks for skill or plugin recommendations.
# Skill Radar
## Consequential advice
When recommending one skill, plugin, or workflow as the user's next move,
follow the `Advice gate` in `dissenter`. Listing relevant candidates without a
recommendation does not trigger the gate.
When the gate applies, first say that you are using `/dissenter` and why.
1. Use the injected available-skills catalog as the local index, then classify the request by primary intent and inspect descriptions from that bucket. If filesystem search is needed, follow symlinks (`rg -L`) so linked skills are included:
| Intent | Bucket |
| --- | --- |
| Learn or practice a concept | `skills/learning` |
| Build, debug, review, or improve code | installed skills from `devinat1/engineering-skills` |
| Practice an interview | installed skills from `devinat1/engineering-skills` |
| Seek advice, reflect, decide, or evaluate a claim | `skills/productivity` |
| Draft, publish, or improve writing | `skills/writing` |
| Configure a repository or agent setup | `skills/setup` |
2. For mixed requests, inspect the primary bucket first, then the relevant secondary buckets. Choose the strongest cross-bucket matches. Prefer `unscramble` when the user wants to organize what they discussed into topics and claims.
3. For advice, surface every directly relevant productivity skill within the three-candidate limit. Treat `dissenter` as directly relevant whenever the user asks for advice, a recommendation, a choice, a proposal, or a plan with at least two credible answers, including low-stakes choices.
4. Inspect available plugins and searchable catalogs after local skills. Do not install anything while searching.
5. If matches exist, show at most three candidates, with local skills before plugins. Ask whether to invoke a local skill or install and use a plugin.
6. Invoke or install a candidate only after an explicit yes. Immediately before invoking an approved skill, say which skill you are using and why it matched. If the user declines, continue without it and do not re-suggest it for that request.
7. If there is no plausible match, continue normally without mentioning this search.
For an ambiguous approval with several choices, prefer the best local match and state that choice before invoking it.
## Routing checks
| Request | Expected suggestion |
| --- | --- |
| “Teach me distributed systems” | A learning skill such as `learn` |
| “Untangle this meeting transcript” | `unscramble` |
| “Advise on this architecture” | Relevant productivity and engineering skills |
| “What food should I eat today?” | `dissenter` |
| “Choose what I should do for the next hour from my saved goals” | `next-hour` |
## Next-hour integration
For an explicit `/next-hour` request or a request to choose the upcoming hour
without an already named task, inspect `next-hour` as the direct local match before broader
catalog search. Read [next-hour handoff rules](../next-hour/INTEGRATIONS.md) when
passing constraints from a parent workflow. An explicit named-skill invocation
already authorizes that invocation; otherwise retain the candidate and approval
rules above. A general skill search or request for suggestions does not authorize
calling `next-hour`. Keep the three-candidate cap and consequential-advice gate.
## Incentive-check integration
At the stage described below, read `${AGENTIC_HOME:-$HOME/.agentic}/skills/incentive-check/INTEGRATIONS.md` and use **Follow-up** mode. For “who benefits if this person's statement is believed?” or an explicit incentive-check request, surface incentive-check as the direct local match. Keep the existing three-candidate cap and invocation approval rules; an explicit request to invoke the named skill is already its invocation authorization. Missing person or statement is resolved by incentive-check when invoked, not by inventing a dossier.
## Automatic Jev check
When locally retrieved skill candidates are being compared to a request and no deterministic routing rule applies, first shortlist and inspect them normally, then send only the request, each candidate description, and stable IDs after reading the existing `typesafe-ai` skill and its current API documentation. Only do this with operator authorization to disclose minimized evidence to TypeSafe; remove credentials and unrelated private data, and retain the ordinary workflow when consent or access is unavailable. Ask one Noul per candidate: `this skill directly addresses the request under its description`; high means the match is direct, not merely adjacent.
Use the advisory results only to order the existing three-candidate list. On ambiguity, unavailability, or disagreement, retain ordinary catalog inspection; mandatory routing, explicit slash invocations, permission, loading, installation, and invocation rules remain authoritative.
在 GitHub 查看