Use this skill when the user is debugging any DOCA symptom — a build that won't compile, a link step that can't resolve a doca_* symbol, a runtime call returning DOCA_ERROR_*, a silent service or tool, or a stack trace / valgrind / core dump — and needs the layered ladder (install → version → build → link → runtime → program → driver), verbosity controls (--sdk-log-level, DOCA_LOG_LEVEL, the doca-{lib}-trace flavor), container-debug constraints, or how to capture state for a Developer Forum post
SkillScore86Maintained
Automatic
◆Coding pack
Last verified 8/12/2026
What it changes
Passed 18 of 21 test cases with the skill, and 6 of 21 without it.
Without skill27%
With skill86%
Checks it passed that the model alone missed
Identifies Layer 3 as Build in the layered debug ladder.
Identifies Layer 2 as Version in the layered debug ladder.
Identifies Layer 6 as Program in the layered debug ladder.
and 11 more in the full report
14 fixed5 passed either way2 still failing1 broke
Pass-rate lift
+59 pp
Tokens
+83%
Agent turns
0%
Response time
-35%
Model gemini-3.6-flashMeasured 8/12/2026v119 of 22 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 13
Prompt
Instead of re-compiling source code to change log verbosity, what command-line argument supported by standard DOCA sample applications controls the SDK log level at launch?
What was checked, without and with the skill
Checked
Without skill
With skill
Identifies --sdk-log-level as the command-line argument for DOCA SDK log verbosity.
Missed
Passed
case-17 · gemini-3.6-flash · 8/12/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md91 linessingle file
DOCA debug
Where to start: This skill is the canonical layered-ladder
reference both doca-setup ## debug
and doca-programming-guide ## debug
escalate to. If the symptom does not fit cleanly in env-class or
program-class, start at TASKS.md ## debug — the
full layered ladder lives there.
Example questions this skill answers well
The CLASSES of debug questions this skill is built to answer, each
with one worked example.
"My DOCA build / link / runtime / program failed — which layer is
it?" — worked example: "ld says undefined reference to doca_flow_init — which layer?" Answered by the canonical layered
ladder in TASKS.md ## debug (layer 4 = Link).
"How do I turn up verbosity for any DOCA library or tool?" —
worked example: "My DOCA Flow program is silent — where do I get
more log output?" Answered by the trace-flavor / log-level surface
in CAPABILITIES.md ## Observability
the run-with-verbosity workflow in
TASKS.md ## run.
"How do I capture state for a forum question or bug report?" —
worked example: "I'd like to file a forum question with reproducible
context — what should I include?" Answered by the
capture-a-reproducible-state workflow in
TASKS.md ## test.
"What does this DOCA tool's output mean / which tool answers
this?" — worked example: "doca_caps returned nothing for RDMA
— does that mean unsupported?" Answered by the
tool-vs-capability decision tree in
CAPABILITIES.md ## Capabilities and modes
cross-link to doca-caps.
"I'm debugging inside the NGC container — what's
observable?" — worked example: "hugepages is empty inside the
container; is that a real problem or a container thing?"
Answered by the container-specific debug constraints in
CAPABILITIES.md ## Safety policy