Compare ONNX skill contracts and guidance against current Quark ONNX documentation and source entry points. Use when maintainers need to verify that ONNX install docs, custom-op registry, QConfig fields, preset and calibration lists, AutoSearchPro presets, deployment-target gates, or example-script invocations still match upstream Quark ONNX reality. Trigger for "check ONNX doc drift", "are ONNX skills still accurate", "verify against Quark ONNX docs", "fact-check quark-onnx-* skills", or after a Quark release when upstream ONNX documentation may have changed.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Compare ONNX skill contracts and guidance against current Quark ONNX documentation and source entry points. Use when maintainers need to verify that ONNX install docs, custom-op registry, QConfig fields, preset and calibration lists, AutoSearchPro presets, deployment-target gates, or example-script invocations still match upstream Quark ONNX reality. Trigger for "check ONNX doc drift", "are ONNX skills still accurate", "verify against Quark ONNX docs", "fact-check quark-onnx-* skills", or after a Quark release when upstream ONNX documentation may have changed.
Provide a lightweight ONNX-side governance check focused on documentation accuracy. While
quark-onnx-skill-sync audits source-code changes broadly and applies the actual updates, this
skill focuses specifically on whether the ONNX skills' user-facing guidance — preset names,
calibration methods, custom-op names, QConfig field names, AutoSearchPro presets, ORT install
matrices, example-script invocations — still matches what Quark's own ONNX docs and source say.
Think of this as a fact-checker for the quark-onnx-* skill family.
Inputs
Quark upstream ONNX docs and source code (read-only)
Current ONNX skill SKILL.md files under .claude/skills-impl/{l1-atomic,l2-workflows,l3-recipes}/onnx/
ONNX-side shared schemas under .claude/skills-impl/shared/contracts/
Outputs: validation_report.md
Lists where current ONNX skill guidance has drifted from upstream Quark ONNX docs and source.
# ONNX Documentation Drift Report## What to Check### 1. Quantization Presets Still Exist
Skills reference specific preset names in their decision tables. Verify each is still defined in
`quark/onnx/quantization/config/custom_config.py`:
**Critical presets to verify** (referenced by `quark-onnx-quant-plan`, `quark-onnx-ptq-workflow`,
`quark-onnx-autosearch-pro`):
-`XINT8` (and the `EnableNPUCnn=True` companion flag)
-`A8W8`, `A16W8`-`BF16`, `BFP16`-`MX*` family (e.g. `MXINT8`, `MXFP8_E4M3`, `MXFP8_E5M2`, `MXFP4`, `MXFP6_E3M2`, )
Weights-only INT4 path (e.g. )
Check that (and ) still contain every
calibration method named in :
Verify that still exposes every algorithm config
class referenced by the skills:
,
, ,
, ,
The surface is copied into skill decision tables, generated scripts, and the workflow
example. Verify every field is still present in / :
, ,
,
,
Skills reference Quark ONNX custom ops by name in error messages, debug guidance, and the
opset domain check used by . Verify each is still
registered in :
family
The domain string
Check that the recipe's preset names still exist in
:
, , ,
Compare 's ORT package/version matrix with:
(the authoritative matrix)
installation instructions
(GPU/EP guidance)
core ONNX deps (, , )
Verify the supported tuples cited by the skill still match.
Common EP names that must be consistent: , ,
, .
lists a deployment-target compatibility table (CPU / CUDA / ROCm /
AMD NPU CNN / AMD NPU Transformer). Verify the gating logic still matches what
accepts (e.g. BFP16 forbidden on NPU CNN, XINT8 + ).
Verify that the JSON schemas in match what the ONNX
workflow actually produces:
— matches the ONNX with ?
— includes ONNX-specific fields used by (preset, calibrationconfig, EnableNPUCnn, usedatanodes)?
— matches 's manifest (generated script path, exact command, resolved )?
Check that the example invocation in and the
walkthrough in still agree on:
the field names used in the worked example,
the argument order,
the imports from ,
the calibration data reader pattern from .
Verify the rule cited by and
the workflow still matches what / enforce.
— report findings but do not modify skills. Modifications go through
.
— preset names, calibration-method names, custom-op names, QConfig
field names, ORT versions, and example-script signatures matter most because users will copy-paste
them into scripts the workflow will run.
— a skill that recommends a deleted preset, calibration method,
custom op, or QConfig field will cause immediate user failures at script generation or runtime.
— a new preset, calibration method, or AutoSearchPro preset
that is not yet documented in skills is a coverage gap, not an error.
— never touch skills. Cross-cut findings (e.g. a shared
field) are surfaced but deferred to the torch maintainer.
Quantization presets: 11 checked, 10 match, 1 new (not in skills)
Calibration methods: 6 checked, 6 match
Algorithm configs: 8 checked, 7 match, 1 drift
QConfig fields: 8 checked, 8 match
Custom-op registry: 4 checked, 4 match
AutoSearchPro presets: 4 checked, 4 match
ORT install matrix: 5 rows checked, 4 match, 1 drift
Deployment-target gates: 5 checked, 5 match
in skills → now in (case change)
: Generated scripts in and will
fail at (ImportError)
: Update the import + plan tables in and
SKILL.md, then re-validate the YOLOv8 worked example
Skills recommend
now pins
: Copy-paste install commands in will downgrade users on a
freshly installed environment
: Update the ROCm row in 's ORT install matrix
added to
: Users asking about MXFP6 won't see it in 's preset table
: Add row to the preset table; consider whether AutoSearchPro should expose
a matching
now accepts a mapping
: Skill mentions but not the new parameter
: Optional — extend calibration row when a real user request lands
Select scope: Full check or focused on specific ONNX skills / facts (e.g. only AutoSearchPro presets)?
Run checks: Compare ONNX skill content against upstream source and docs using the grep-driven extraction patterns above.
Classify findings: Critical (broken guidance), warning (outdated), info (gap in coverage).
Report: Produce the drift report as validation_report.md.
Hand off: If fixes are needed, route to quark-onnx-skill-sync for the actual updates — never patch skills from this check.
Recovery
If upstream ONNX docs are inaccessible, report which checks could not be performed and which ONNX skills are therefore unverified.
If quark/onnx/operators/custom_ops/build_custom_ops.py cannot be parsed (e.g. moved or renamed), mark quark-onnx-install and quark-onnx-debug as potentially affected even when no string drift is observed — custom-op load failures are runtime-only.
If drift is detected, hand off to quark-onnx-skill-sync with the specific findings so it can apply targeted fixes; do not edit skills from this check.
If a finding spans both backends (e.g. a shared/contracts/ schema change), report it but defer cross-cut fixes to the torch maintainer rather than editing torch skills from here.
