Curating AI Skill Repositories
Given a target system's architecture (modules + requirements), produce a categorized table mapping capability needed → skill/methodology → concrete reference repo(s) → priority tier. Don't just list links — justify each pick against the specific module it serves.
| Module | Capability Needed | Reference Repo | Why This One |
|--------|-------------------|-----------------|--------------|
| Agent Orchestration | Multi-agent coordination | github.com/org/repo | Has planner/executor split matching our design |
Progress:
- Step 1: Decompose the target system into modules (e.g., agent layer, security layer, ML infra, governance, networking)
- Step 2: For each module, identify the 2-4 core capabilities required (not tools — capabilities, e.g. "policy enforcement" not "OPA")
- Step 3: Search/recall repos that concretely implement each capability — prefer ones with real architecture (not toy demos)
- Step 4: Verify each link is plausible and correctly attributed (org/repo name matches known project); flag any uncertain ones explicitly rather than inventing URLs
- Step 5: Tag each repo with relevance level (Critical / Relevant / Supporting) tied to why, not just topic match
- Step 6: Build a tiered adoption roadmap (Tier 1 = foundational architecture references, Tier 2 = component-level implementations, Tier 3 = nice-to-have/domain-specific)
- Step 7: Produce an integration map: which repos feed which module, and what concrete output/artifact that integration should produce
- Step 8: Close with an explicit "verify before use" caveat for any repo whose existence/activity you're not fully certain of
Example 1: Input: "I'm building a sovereign multi-agent OS with security, RAG, and ML infra layers — find me reference repos." Output: A 6-category table (Sovereign OS architecture, Agent frameworks, RAG systems, Security/guardrails, ML platform, Governance) each with repo links, one-line justification tied to the specific layer, plus a 3-tier priority roadmap and a cross-reference table showing which repos combine to produce each module's output.
Example 2: Input: "What's a reference implementation for policy-based AI governance?" Output: Point to a policy-engine style project (e.g., OPA-style architecture), explain the specific mechanism (rego-like policy evaluation, admission control) and how it maps to "constitutional governance" style requirements, rather than just naming the repo.
- Map to capability first, repo second — never let repo popularity substitute for architectural fit.
- Distinguish reference/inspiration repos (architecture to study) from production-ready libraries (code to actually depend on). Label which is which.
- Always give the reason a repo is relevant in terms of the requester's own module/vocabulary (e.g., "matches your planner/executor split"), not generic praise.
- Prioritize ruthlessly into tiers — a 40-item list is useless without a "start here" signal.
- When the target system uses unusual/invented terminology (e.g., "sovereign," "constitutional AI," "replay-safe"), translate it into standard technical capabilities (policy engines, idempotent execution, audit logging) before searching, and be explicit about that translation.
- Note licensing and maintenance status as a filter criterion when recommending anything for production adoption.
- Do not fabricate GitHub URLs or repo names. If uncertain whether a specific org/repo exists or is still active, say so explicitly ("verify this exists/is maintained before relying on it") rather than presenting it as confirmed.
- Don't pad lists with tangentially-topic-matched repos just to hit a count — every entry must justify its module relevance.
- Don't conflate "awesome-list" meta-repos with actual implementations; label meta-lists as indexes, not as solutions themselves.
- Avoid recommending unmaintained/abandoned repos as core dependencies — flag last-commit recency when it matters.
- Don't let flashy branding/naming (e.g., "sovereign," "autonomous") substitute for verifying actual technical substance in the repo's README/code.
- Never present a prioritized roadmap without tying each tier back to a concrete build milestone — priority lists without stakes are just trivia.