Yige
8f7953948f
## 中文 补齐已有 owner 与已锁定上游内容可证明的许可证、技能类型和收录版本。保留 Anthropic Source Available 和其他附加条件，不把所有内容统一标为 MIT，不提升 listing-only 的安装准入。 README 保留最新的双语结构及以 manifest 为准的数量口径，增加静态目录不存访问量、下载量、评分或 Stars 的边界。 发布兼容性：**本 PR 不包含**两支团队新增的本地化字段，也不包含微信支付 `latestVersion: 1.0`；旧客户端会拒绝这些新字段，另以待发布 PR 保留，等匹配客户端发布后再合并。 验证：47 项目录校验测试、19 项 i18n 测试、5 项合集生成测试通过；完整目录/i18n/翻译新鲜度检查通过，6 个固定来源合集的生成检查通过，2 个浮动来源按既有规则明确跳过。发现并修复了生成器在 Windows 使用反斜杠造成的误报：输出改为 POSIX 路径，比较规则不放宽、不重写合集数据。 ## English Fill only license, type and listed-release facts supported by existing owners or pinned upstream content. Preserve custom license restrictions and acquisition eligibility. Keep the current bilingual README and manifest-derived inventory; do not author usage analytics. This PR deliberately excludes localized team fields and the two-part WeChat Pay version that older clients reject. Those changes remain pending a compatible client release. Validation passes: 47 catalog-validator tests, 19 i18n tests, five collection-generator tests, complete catalog and translation checks, and generated inventory checks for six pinned collections. Two mutable sources remain explicitly skipped. Fix Windows-generated path separators without weakening comparison or changing declared children.
6.5 KiB
license, name, description, version, type, risk_level, status, disable-model-invocation, tags, metadata, market
| license | name | description | version | type | risk_level | status | disable-model-invocation | tags | metadata | market | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MIT | discover-agent | 根据用户需求推荐最匹配的智能体，展示候选列表并引导选择。Use when 用户描述需求但不确定该找哪个智能体帮忙，或想浏览可用的智能体。 | 2.7.0 | procedural | low | enabled | true |
|
|
|
discover-agent skill
L0: One-Sentence Summary
Match and recommend the most suitable Agent among registered Agents based on the user's need description.
L1: Overview
Procedural skill: understand the need → retrieve with ManageAgent(action='list') → semantic match scoring → rank and present → guide selection; on no match, hand off to create-agent automatically. Applies when the user doesn't know which Agent to pick, wants to browse available Agents, is a new user getting oriented, or is unhappy with the current Agent and wants an alternative. Its value is what the tool can't give: semantic need matching (not keyword search), candidate ranking and presentation, and the create hand-off on no match. list / get are read-only, approval-free.
L2: Detailed Spec
Flow: need understanding → retrieval → match evaluation → ranking → presentation → guided selection.
Stage 1: Need Understanding
Trigger (any): user says "find me a… / is there a… / who can help me…", describes a task without naming an Agent, "which Agents are there", or the system detects a need that mismatches the current Agent. Extract dimensions from the description: domain (legal/finance/tech/education), task_type (consult/review/analyze/create), keywords (contract/report/code/paper…), urgency (routine/urgent).
Stage 2: Retrieval
ManageAgent(action='list') fetches all registered Agents (returns a compact list with name / id / status / description). list/get are read-only ManageAgent operations and can be called directly; they do not require loading create, update, clone, or delete skills first. Filtering: by default show non-offline Agents; offline ones appear only as a fallback when there's no better candidate; exclude internal system Agents (e.g. DesireCore itself) unless the user explicitly asks.
Stage 3: Match Evaluation
Judge match with LLM semantic understanding (not a formula): relevance of description / persona to the need, association of skills to the task type, domain fit, status availability (online preferred). Presentation tiers: strong match → mark "recommended", partial → "possibly relevant", no clear relation → don't show.
Stage 4: Ranking
Descending by overall score; ties broken by online status; show the most relevant ones — you decide how many by relevance.
Stage 5: Presentation
- With matches: list candidates, each with name, description, key skills, status, and match score; ask the user to choose or refine the need. E.g. "1. Legal Advisor (92%) — contract review and legal risk assessment; skills: contract review / risk assessment / legal research; online".
- No match: report that none were found and offer three options — retry with a more specific description / create a new specialized Agent (hand off to create-agent) / browse all.
- Browse mode (user wants to see all): list name + description grouped by online / offline, and ask whether to view details of any.
Stage 6: Guided Selection
- Chose an Agent → switch to that Agent's conversation, passing the user's need context (source / target / user_intent).
- Wants more detail →
ManageAgent(action='get', id)for details (name / description / status / version / skill count / tool count / Git status); present the key info in natural language or a table and ask whether to chat. - Unhappy with candidates → guide the user to refine the need or suggest creating a new Agent.
- Chose "create new" → invoke the create-agent skill, passing the gathered requirements.
Collaboration and Error Handling
- Collaboration: on no match, hand off to create-agent (pass the need as initial info); on a successful match, optionally create a task and assign it to the target Agent.
- Errors: tool call fails → report error and suggest retry; empty Agent list → guide the user to create the first Agent; overly vague need → ask follow-ups and offer domain options;
getreturns "Agent not found: " → fall back tolistto reconfirm available Agents; recommended Agent in an abnormal state → mark the status and suggest picking an online one. list/getare read-only, approval-free, and risk-free; always done viaManageAgent.