$npx -y skills add opendatahub-io/ai-helpers --skill module-complianceCheck an ODH module operator repository for contract violations against the platform onboarding guide. Validates PlatformObject status, CRD structure, Helm chart content, webhook ownership, metadata conventions, and reconciler chain ordering. Use during code review or after scaff
| 1 | # ODH Module Compliance Check |
| 2 | |
| 3 | Validate a module operator repository against the ODH platform contract. |
| 4 | |
| 5 | ## Step 1: Identify the module root |
| 6 | |
| 7 | If `$ARGUMENTS` provides a path, use it. Otherwise use the current working |
| 8 | directory. |
| 9 | |
| 10 | Verify the directory contains a Go module by checking for `go.mod`. Read |
| 11 | `go.mod` and confirm it imports |
| 12 | `github.com/opendatahub-io/odh-platform-utilities` at version `v0.1.0` or |
| 13 | later. If the import is missing, record a **CRITICAL** finding immediately -- |
| 14 | the module must use the shared library, not the operator internal types. |
| 15 | |
| 16 | Locate the CRD types directory by searching for files matching |
| 17 | `api/**/types.go` or `api/**/*_types.go`. Locate the controller directory by |
| 18 | searching for files matching `internal/controller/**/*.go`. |
| 19 | |
| 20 | ## Step 2: Run compliance checks |
| 21 | |
| 22 | Load the full rule set from `${CLAUDE_SKILL_DIR}/references/contract.md`. |
| 23 | |
| 24 | For each rule, search the codebase using `Grep` and `Read` to determine |
| 25 | pass/fail. Collect results into a list with rule ID, status (PASS / FAIL / |
| 26 | WARN / SKIP), file path and line number for violations, and a short |
| 27 | explanation. |
| 28 | |
| 29 | Rules are grouped into these categories: |
| 30 | |
| 31 | 1. **API contract** -- PlatformObject interface, status fields, mandatory |
| 32 | conditions, singleton enforcement, API group and version. |
| 33 | 2. **Spec conventions** -- CommonSpec pattern, ManagementSpec, platform-managed |
| 34 | fields, ConfigMap minimality. |
| 35 | 3. **Controller patterns** -- Reconciler builder, GC action ordering, condition |
| 36 | manager setup, dependency handling, observedGeneration. |
| 37 | 4. **Helm chart** -- Controller-only manifests, no application resources. |
| 38 | 5. **Security & metadata** -- Webhook ownership, cert-manager TLS, metadata |
| 39 | labels/annotations, RBAC scoping. |
| 40 | 6. **Separation of concerns** -- No orchestrator logic, self-contained module. |
| 41 | |
| 42 | ## Step 3: Report findings |
| 43 | |
| 44 | Present results grouped by category. Use this format: |
| 45 | |
| 46 | ```text |
| 47 | ## Module Compliance Report: <module-name> |
| 48 | |
| 49 | ### API Contract |
| 50 | - [PASS] MC-01 PlatformObject interface implemented |
| 51 | - [FAIL] MC-02 Missing WithReleases implementation (api/v1alpha1/types.go:42) |
| 52 | → Add GetReleaseStatus() and SetReleaseStatus() methods |
| 53 | |
| 54 | ### Spec Conventions |
| 55 | ... |
| 56 | |
| 57 | ### Summary |
| 58 | Total: 18 rules checked |
| 59 | Passed: 15 |
| 60 | Failed: 2 |
| 61 | Warnings: 1 |
| 62 | ``` |
| 63 | |
| 64 | After the report, suggest running `/module-scaffold` if the repo is missing |
| 65 | fundamental structure, or provide specific fix instructions for each failure. |