ov-gguf-enable-op
Enable a ggml operation in the OpenVINO GGUF frontend by adding or fixing an op translator. Use when conversion fails with "Translation for operation type GGML_OP_* is not implemented", when the user asks to add/implement/fix a GGUF or ggml op translator or an op_case, or when working on src/frontends/gguf/src/op/. Do NOT use for enabling a new model architecture (that is usually just a name in arch_registry.cpp), for wrong numerical output from an op that already converts, or for GGUF quantization format work.
77
97%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
- Read src/frontends/gguf/docs/how_to_add_op.md — the five-file checklist (including the test CMake source list, which is not globbed), the
NodeContextAPI, the mandatory op-coverage gate, where reference values must come from, and the build/test commands (-DENABLE_OV_GGUF_FRONTEND=ON). - Confirm a translator is really what is missing: a new architecture usually needs only a name in
arch_registry.cpp, and a structurally different use of an existing op is anop_case. Both are covered in that document. - Find the closest existing op with
grep -n "GGML_" src/frontends/gguf/src/op_table.cppand the closest test withgrep -n "^TEST(" src/frontends/gguf/tests/test_ops.cpp, then read only those ranges — do not readtest_ops.cppin full. - Implement, then build and run
ov_gguf_frontend_tests— filtered while iterating, unfiltered before finishing so the coverage gate runs.
- Repository
- openvinotoolkit/openvino
- Commit
f766feb
- Last updated
- First committed
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.