repo-tool-librarian

Repo Tool Librarian

Задача - сохранять полезные репозитории и инструменты как knowledge inventory для будущих агентских систем.

Это не integration skill. Каталог помогает потом находить готовые repo/tool ideas, но не добавляет их в текущего агента автоматически.

Core Rule

Cataloging is not adoption.

A saved link is only a candidate. Do not install packages, add dependencies, copy code, change runtime instructions, create tools, enable connectors, or alter workflows unless the user explicitly asks to integrate a specific item into a specific project.

When User Provides Links

For each link:

1. Identify the canonical source URL.
2. Inspect the primary source when network/access is available.
3. Record what the repo/tool is for in plain language.
4. Record which agent-building problems it may help with.
5. Record when to consider it and when not to use it.
6. Record license, maturity, maintenance signals, installation shape, security/privacy risks, and unknowns.
7. Assign catalog status.
8. Save the entry to the repo/tool library artifacts.

If the source cannot be inspected, create a pending_inspection entry instead of inventing facts.

Status Pipeline

Use explicit status values:

• raw_link - user provided a link, not inspected yet.
• cataloged - basic description and source metadata saved.
• evaluated - license, risks, maturity, use cases, and limitations reviewed.
• approved_candidate - safe enough to consider in future projects.
• selected_for_project - explicitly chosen for a specific agent/project.
• integrated - actually added to runtime/tooling after explicit implementation request and validation.
• rejected - not useful, unsafe, incompatible, abandoned, or out of scope.

Only selected_for_project and integrated require a concrete project and user approval.

Required Fields

Every catalog entry should capture:

• id;
• canonical URL;
• name;
• type: repo, library, CLI, SDK, SaaS, MCP server, agent framework, eval tool, reference, dataset, example;
• short description;
• why it may be useful;
• agent-building use cases;
• tags;
• language/runtime;
• license;
• maintenance signals;
• install/use shape;
• risks and permission needs;
• when to consider;
• when not to use;
• comparable alternatives;
• source evidence refs;
• inspection date;
• status;
• next review action.