docs(ai-integrations): specify OCI and npx skill providers - #4780
johnmcollier wants to merge 1 commit into
Conversation
|
🤖 Review · Commit: |
|
PR Summary by QodoSpecify OCI and npx skill catalog providers
AI Description
Diagram
High-Level Assessment
Files changed (7)
|
|
🤖 Finished Review · ✅ Success · Started 7:04 PM UTC · Completed 7:10 PM UTC Commit: Runtime: claude · Model: opus → claude-opus-4-6 · Cost: $0.80 |
Code Review by Qodo
1. Skills can collide or change identity
|
rhdh-qodo-merge
Bot
added
the
documentation
|
Important The |
Review — approvePR: docs(ai-integrations): specify OCI and npx skill providers SummaryThis PR adds a complete OpenSpec change set — proposal, design, tasks, and three capability specifications — for two new catalog entity providers: an OCI skillimage provider (public Quay) and an npx-compatible skill registry provider. No code, configuration, runtime, or package changes are included. AnalysisCorrectness & internal consistency. The three spec files ( Security posture. The design proactively scopes v1 to publicly readable sources only (D6), specifies digest-pinned references (D2), enforces HTTPS-only artifact retrieval with same-origin and allowlist constraints, caps artifact size, and requires SHA-256 verification before entity emission. These are sound design principles for a provider consuming external registries. No credentials, secrets, or authentication flows are introduced. Scope & intent. The change is appropriately scoped to documentation. The PR description’s claim of “No implementation, package, configuration, or runtime changes” is verified — the diff contains only markdown and YAML specification files under the established Convention adherence. The file structure ( Minor observations (non-blocking):
VerdictApprove. This is a well-structured, internally consistent specification that follows the workspace’s established OpenSpec conventions. The security design is thoughtful for the scope. No blocking issues identified. Labels: PR adds OpenSpec specification documents to the ai-integrations workspace |
![fullsend-ai-review[bot]](https://avatars.githubusercontent.com/in/3478501?s=60&v=4){kind=small}
fullsend-ai-review
Bot
added
the
ready-for-merge
gabemontero
left a comment
gabemontero
left a comment
There was a problem hiding this comment.
feedback in part from comparing with what we did for model catalog, and what #4747 and fullsend coder did in following that pattern
|
|
||
| - Add a shared utility for provider identity, entity construction, annotation | ||
| normalization, and error isolation. | ||
| - Add an OCI provider that discovers public skillimage artifacts in a Quay |
There was a problem hiding this comment.
so one thing fullsend did as part of #4747 @johnmcollier is that if provided a backstage router that returns all the retrieved the skillimage.yaml and SKILLS.md content via an RHDH plugin router/REST endpoint
As I read this, I wonder if we continue that pattern with what will be the increasing number of external skill sources of truth (i.e. when we add RHOAI mlflow REST endpoints), and we just make sure that each skill provider provides a standard format of returned data, and then have one entity provider plugin that handles the creation of the AiResource entities.
Similar to the model catalog for ai model servers we are curating in the ai-integrations workspace.
| namespace and emits one `AiResource` per skill. | ||
| - Add an npx skills provider that consumes public npx-compatible Agent Skills | ||
| v0.2 discovery indexes, including RHESS. | ||
| - Emit upstream-compatible `AiResource` entities with `spec.type: skill`, |
There was a problem hiding this comment.
https://github.com/redhat-developer/rhdh-plugins/pull/4780/changes#r4041576396 pertains here too
curating this will also help us come up with a normalization notions around how each of the skills registries express thing, and understand commonalities wrt metadata and where each source has unique information
| returned content digest. | ||
| - [ ] 2.3 Identify OCTO skillimages and map manifest annotations to entities | ||
| without layer extraction. | ||
| - [ ] 2.4 Retain last-known-good entities for transient per-repository errors. |
There was a problem hiding this comment.
let's add the REST interface for the common AiResource entity producer to consume
| - [ ] 1.2 Implement stable source-based identity and normalized fallback | ||
| version `0.0.0+<short-content-digest>`. | ||
| - [ ] 1.3 Persist last-known-good source state and support delta mutations. | ||
| - [ ] 1.4 Add structured per-provider counters and contextual error logs. |
There was a problem hiding this comment.
let's add defining the superset of skill metadata provided by each of the skill registry sources
| each artifact before mapping known frontmatter fields. | ||
| - [ ] 3.3 Enforce source-origin, redirect, size, timeout, and concurrency | ||
| limits. | ||
| - [ ] 3.4 Retain last-known-good entities for transient per-skill errors. |
There was a problem hiding this comment.
let's add the REST interface for the common AiResource entity producer to consume
| `rhdh.io/ai-asset-category: skill`, `rhdh.io/ai-asset-version`, and | ||
| `rhdh.io/ai-asset-source` remain the RHDH AI Catalog contract. Providers set | ||
| `defaultOwner` and `defaultLifecycle` from configuration when source metadata | ||
| does not provide usable values. |
There was a problem hiding this comment.
as part of this, let's have a superset mapping of each of these skill registry sources to AiResource
this fuels the schema / format of what each skill registry source produces when the entity provider plugin asks for info
|
|
||
| ### Requirement: OCI skill entity emission | ||
|
|
||
| For an OCTO skillimage manifest, the provider SHALL emit one `AiResource` with |
There was a problem hiding this comment.
yeah let's remove the AiResource emission from here
|
quick f/up ... here is what the #4747 plugin rest endpoint returns when I query it after it has pulled down that sample OCTO skillimage based OCI skill image: |
2 participants
Summary
Scope
No implementation, package, configuration, or runtime changes are included.