| name | project-red-hat-doc-alignment-review |
| metadata | {"author":"rhoai3-demo","version":"1.2.0","platform-family":"rhoai","platform-baseline":"repo","ocp-baseline":"repo","skill-group":"Project Structure"} |
| description | Review rhoai3-demo stage READMEs, Red Hat concept narratives, official documentation references, GitOps manifests, images, and RHOAI resources against Red Hat source material for the active product baseline. Use when creating or modifying README concept framing, European enterprise value claims, CRs, operator configuration, InferenceServices, ServingRuntimes, LlamaStack, Guardrails, Model Registry, DSPA, LMEvalJob, TrustyAI, Notebook, container images, model artifacts, or any RHOAI-managed resource. Also use when adding baseline-specific product claims or running periodic Red Hat source alignment audits. Do NOT use for general prose drafting, PLAN.md writing, or knowledge capture (use project-documentation-authoring); use this skill to verify the source grounding before merge.
|
Red Hat Source Alignment Review
Use this skill to verify that the demo story and implementation are grounded in
Red Hat sources. This is stricter than YAML validity and separate from prose
authoring: a manifest can render, and a README can read well, while still
relying on unsupported fields, stale product references, ungrounded enterprise
claims, or undocumented assumptions.
Workflow
- Read
docs/PLATFORM_BASELINE.md to identify the active RHOAI, OCP, and
related Red Hat documentation baselines.
- Read the changed README and companion GitOps manifests together.
- Check the README concept narrative:
- the first major section defines the concept being introduced
- it explains why a European-regulated enterprise architect, engineer, or
business owner should care
- it cites at least one relevant Red Hat article or blog from
/Users/adrina/Sandbox/rh-brain/Red Hat Brain
- Check the README technical mapping:
- every RHOAI, OCP, MicroShift, OpenShift Pipelines, or Red Hat AI component
introduced in the stage has an active-baseline official documentation link
- configuration guidance comes from official docs first, with rh-brain
articles used only for examples, implementation patterns, and narrative
support
- Check GitOps manifests:
- custom resource API versions, API tier support posture, top-level spec
fields, annotations, operator channels, image sources, and model artifacts
match official Red Hat documentation or verified installed schemas
- Red Hat product images and validated artifacts are preferred whenever the
demo claims Red Hat-supported posture
- operator-generated images, CSV
relatedImages, copied CSVs, and
operator-created Deployments are not treated as project-owned desired
state unless official product docs expose a supported override field
- Use
references/doc-alignment-checklist.md for the detailed review model.
- Use
rhoai-api-tiers when the change depends on RHOAI API stability,
Technology Preview, Developer Preview, or Tier 4 support posture.
- If a field or artifact cannot be verified from docs, flag it and propose a
schema or catalog verification command such as
oc explain, CRD inspection,
or image/catalog lookup.
- For prose rewrites, README structure, plans, or troubleshooting entries,
switch to
project-documentation-authoring.
Output Format
Stage: stage-YXX-slug
Files reviewed: N
Source-aligned:
- README.md: concept framing cites Red Hat article X and official docs Y
- file.yaml: apiVersion, fields, image, and artifact source match active docs
Misaligned:
- [NARRATIVE] README.md: concept claim has no rh-brain/Red Hat article source
- [API] file.yaml: expected documented API version X, found Y
- [FIELD] file.yaml: field foo is not documented for this CR version
- [IMAGE] file.yaml: image is not Red Hat product, validated, internal, or explicitly approved
- [DOC-REF] README.md: references stale product documentation
Summary: X aligned, Y misaligned
References
references/doc-alignment-checklist.md
