[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-nvidia-doca-flow-tune":3,"mdc-cbmjot-key":34,"related-repo-nvidia-doca-flow-tune":1973,"related-org-nvidia-doca-flow-tune":2077},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":23,"repoUrl":24,"updatedAt":25,"license":26,"forks":27,"topics":28,"repo":29,"sourceUrl":32,"mdContent":33},"doca-flow-tune","tune DOCA Flow pipelines","Use this skill when the user is tuning a live or captured `doca-flow` pipeline with `doca_flow_tune` — snapshotting pipe \u002F counter \u002F KPI state, picking a tuning axis (rule placement, resource hints \u002F table sizing, HW-offload mode) and a matching measurement (rule-install rate, lookup latency, hardware-counter delta), running offline or online (read-only or state-changing) modes, reading the dumper CSV \u002F analyze JSON \u002F visualize mermaid, or applying a recommendation back into the Flow program. Trigger even when the user does not explicitly mention \"doca_flow_tune\" — typical implicit phrasings include \"Flow rule-install rate is low on BlueField\", \"table sizing looks wrong for this pipe\", \"tune visualize step is empty\", \"before\u002Fafter counters don't move\", or \"which doca-flow knob does this recommendation hit\". Refuse and route elsewhere for measuring baseline numbers (doca-flow-perf, doca-flow-dpa-perf), writing the doca-flow application, DOCA install, or streaming Flow telemetry — those belong to other skills.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},"nvidia","NVIDIA","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fnvidia.png",[12,16,19,20],{"name":13,"slug":14,"type":15},"Performance","performance","tag",{"name":17,"slug":18,"type":15},"Networking","networking",{"name":9,"slug":8,"type":15},{"name":21,"slug":22,"type":15},"Engineering","engineering",2473,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills","2026-07-20T06:24:29.858945","Apache-2.0",281,[],{"repoUrl":24,"stars":23,"forks":27,"topics":30,"description":31},[],"AI agent skills published by NVIDIA","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills\u002Ftree\u002FHEAD\u002Fskills\u002Fdoca-flow-tune","---\nlicense: Apache-2.0\nname: doca-flow-tune\ndescription: >\n  Use this skill when the user is tuning a live or captured\n  `doca-flow` pipeline with `doca_flow_tune` — snapshotting\n  pipe \u002F counter \u002F KPI state, picking a tuning axis (rule\n  placement, resource hints \u002F table sizing, HW-offload mode)\n  and a matching measurement (rule-install rate, lookup latency,\n  hardware-counter delta), running offline or online (read-only\n  or state-changing) modes, reading the dumper CSV \u002F analyze\n  JSON \u002F visualize mermaid, or applying a recommendation back\n  into the Flow program. Trigger even when the user does\n  not explicitly mention \"doca_flow_tune\" — typical implicit\n  phrasings include \"Flow rule-install rate is low on\n  BlueField\", \"table sizing looks wrong for this pipe\", \"tune\n  visualize step is empty\", \"before\u002Fafter\n  counters don't move\", or \"which doca-flow knob does this\n  recommendation hit\". Refuse and route elsewhere for measuring\n  baseline numbers (doca-flow-perf, doca-flow-dpa-perf), writing\n  the doca-flow application, DOCA install, or streaming Flow\n  telemetry — those belong to other skills.\nmetadata:\n  kind: tool\ncompatibility: >\n  Requires DOCA SDK installed at \u002Fopt\u002Fmellanox\u002Fdoca on Linux\n  (Ubuntu 22.04\u002F24.04 or RHEL\u002FSLES) with a BlueField DPU or\n  ConnectX NIC attached, plus a running or captured `doca-flow`\n  application to observe. Reads the user's local install via\n  `pkg-config doca-flow` and the shipped `flow_tune_cfg*.json`\n  templates and `scripts\u002F` directory under \u002Fopt\u002Fmellanox\u002Fdoca.\n---\n\n# DOCA Flow Tune (`doca_flow_tune`)\n\n> **Subcommand surface correction (Run-12, verified Run-13\n> against doca\u002Ftools\u002Fflow_tune\u002Fsrc\u002Ftune\u002Fcommon\u002Ftune_config.cpp).**\n> `doca_flow_tune` is a single binary whose **role on a given\n> invocation is determined by which of five top-level\n> subcommands** the user picks — `dump`, `monitor`, `web`,\n> `analyze`, `visualize` (case-insensitive on the CLI;\n> uppercased in this skill for readability). All five names\n> are registered via `doca_argp_cmd_set_name(...)` in\n> `tune_config.cpp` (lines 1799 \u002F 1860 \u002F 1896 \u002F 2074 \u002F 2111);\n> `analyze` further accepts `import` \u002F `export` \u002F `packet_trace`\n> \u002F `sim_timing` sub-subcommands. The `dump` \u002F `monitor` \u002F `web`\n> subcommands run the binary in **server-attached online mode**\n> against a live `doca-flow` application reached over a Unix-\n> domain socket whose path lives in `network.server_uds` of the\n> shipped `flow_tune_cfg*.json`; the `analyze` \u002F `visualize`\n> subcommands run in **offline \u002F captured-snapshot mode** against\n> JSON \u002F CSV files the online modes previously dropped into the\n> configured `outputs_directory`. The rest of this skill (and\n> [`CAPABILITIES.md`](CAPABILITIES.md) \u002F [`TASKS.md`](TASKS.md))\n> uses the legacy *\"server role \u002F online mode \u002F offline mode\"*\n> framing — that framing is internally consistent with the\n> subcommand surface here: *server role* = a server-attached\n> online subcommand (`dump`\u002F`monitor`\u002F`web`); *online mode* =\n> any of `dump`\u002F`monitor`\u002F`web`; *offline mode* =\n> `analyze`\u002F`visualize`. Treat the subcommand name as the\n> primary handle; treat *server\u002Fonline\u002Foffline* as the\n> downstream behavioral consequence of the subcommand pick.\n\n**Where to start:** This is a tool skill for invoking `doca_flow_tune`,\nthe unified DOCA Flow tuning tool. Open [`TASKS.md`](TASKS.md) and\nstart at [`## configure`](TASKS.md#configure) to commit to the\nthree-axis decision (target Flow pipeline × tuning axis ×\nmeasurement) and pick offline vs online vs server-attach mode, then\n[`## run`](TASKS.md#run) for the snapshot → analyze → visualize\nloop, then [`## test`](TASKS.md#test) for the smoke-before-bulk\noverlay that gates any state-changing application of a tuning\nrecommendation back into the Flow application's code. Open\n[`CAPABILITIES.md`](CAPABILITIES.md) when the question is *what\nstate `doca_flow_tune` can observe and recommend on*, *how its\nserver \u002F client roles fit inside the single artifact*, *which DOCA\nversion the tool ships in*, or *how to interpret the dumper \u002F monitor\n\u002F analyze \u002F visualize outputs without fooling yourself*. If DOCA is\nnot installed, route to\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) first; if the user has\nno running `doca-flow` application yet, route to\n[`doca-flow`](..\u002F..\u002Flibs\u002Fdoca-flow\u002FSKILL.md) — flow-tune does not\ncreate pipes, it observes and recommends on top of pipes the\nlibrary already created.\n\n## Example questions this skill answers well\n\nThe CLASSES of `doca_flow_tune` questions this skill is built to\nanswer, each with one worked example. The class is the load-bearing\npiece; the worked example is one instance.\n\n- **\"Should I reach for `doca-flow-tune` or `doca-flow-perf` for\n  this question?\"** — worked example: *\"my doca-flow service runs\n  on a BlueField-3 and I think the rule-install rate is below what\n  the device can sustain; do I measure first or tune first?\"*.\n  Answered by the *tune vs perf* boundary in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  and the routing into\n  [`doca-flow-perf`](..\u002Fdoca-flow-perf\u002FSKILL.md) for baselines vs\n  this skill for optimization on top of a measured baseline.\n- **\"Capture a snapshot of a live `doca-flow` pipeline's hardware\n  and software counters without touching the dataplane.\"** — worked\n  example: *\"I want a side-effect-free dumper \u002F monitor run against\n  the running Flow ports for an operations-rate profile\"*. Answered\n  by the snapshot flow in\n  [`TASKS.md ## run`](TASKS.md#run) plus the read-only-by-default\n  posture in\n  [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy).\n- **\"Pick the right tuning axis — rule placement, resource hints,\n  or hardware-offload mode — for the question I actually have.\"**\n  — worked example: *\"my Flow pipe's rule-install rate is low; is\n  this a placement question or a table-sizing question?\"*. Answered\n  by the three-axis configuration in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the configure walk in\n  [`TASKS.md ## configure`](TASKS.md#configure).\n- **\"How do `doca_flow_tune`'s server role and client \u002F consumer\n  role fit together inside the single artifact?\"** — worked\n  example: *\"I keep reading about a Flow Tune server and a Flow\n  Tune client; which binary am I running?\"*. Answered by the\n  *one binary, two roles* breakdown in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  and the corresponding routing in\n  [`TASKS.md ## configure`](TASKS.md#configure).\n- **\"How do I take a recommended parameter change from flow-tune\n  back into my doca-flow application without breaking the\n  dataplane?\"** — worked example: *\"the analyze step suggests a\n  different table sizing for my pipe; how do I apply it?\"*.\n  Answered by the *recommendation → minimum-diff modification of\n  the Flow program* loop in\n  [`TASKS.md ## modify`](TASKS.md#modify) and the\n  smoke-before-bulk rule in\n  [`TASKS.md ## test`](TASKS.md#test).\n- **\"`doca_flow_tune` reports nothing \u002F disagrees with the Flow\n  app \u002F cannot attach — what does that mean?\"** — worked example:\n  *\"the tool runs but the visualize step produces an empty\n  mermaid diagram\"*. Answered by the layered error taxonomy in\n  [`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)\n  + [`TASKS.md ## debug`](TASKS.md#debug).\n\n## Audience\n\nThis skill serves **external operators, performance engineers,\nDOCA Flow application developers, and AI agents who need to\nunderstand, characterize, or improve a running `doca-flow`\npipeline's behavior on the user's actual install and device**.\nConcretely:\n\n- A platform operator running a `doca-flow` service on BlueField\n  who wants a read-only snapshot of which pipes exist and how\n  their hardware \u002F software counters are progressing before\n  recommending any change.\n- A performance engineer who already has a `doca-flow-perf`\n  baseline number and wants to turn the *measurement* into an\n  *optimization* — pick a tuning axis and identify which knob in\n  the doca-flow program is the lever for it.\n- A DOCA Flow application developer who wants the offline analyze\n  + visualize loop to understand a pipe layout without\n  re-instrumenting the Flow program.\n- An AI agent driving the *\"is this Flow pipeline behaving as\n  expected, and would a non-mutating tuning hint help\"* triage\n  step before recommending any code change to the Flow program.\n\nIt is **not** for users debugging the `doca_flow_tune` source code,\n**not** a substitute for the live public DOCA Flow Tune guide on\n`docs.nvidia.com`, **not** the right place to learn the\n`doca-flow` API (that audience belongs in\n[`doca-flow`](..\u002F..\u002Flibs\u002Fdoca-flow\u002FSKILL.md)), and **not** the\nright place for baseline *measurement* methodology — that belongs\nto [`doca-flow-perf`](..\u002Fdoca-flow-perf\u002FSKILL.md).\n\n`doca_flow_tune` is shipped as a **single tool** (one binary plus\nits companion analyzer \u002F visualizer scripts and JSON config\ntemplates) — the historical *server* and *client* roles live\ninside this one artifact, not in two separate executables. The\nskill uses the same `kind: tool` three-file shape as the rest\nof the bundle so the agent's task-verb contract\n(`configure \u002F build \u002F modify \u002F run \u002F test \u002F debug`) is uniform\nacross libraries, services, and tools.\n\n## Language scope\n\nThis skill governs invocation, output interpretation, and\nrecommendation-to-code-change routing for the C \u002F C++ DOCA Flow\napplication that `doca_flow_tune` observes. The tool itself is\nnot a programming target — there is no public API the agent is\nsupposed to link against; what the agent and the user do with the\ntool is *configure JSON, run, read the outputs, propose minimum-\ndiff changes to the surrounding `doca-flow` program in the\nprogram's own language*. For the `doca-flow` API the\nrecommendations route back into, see\n[`doca-flow CAPABILITIES.md`](..\u002F..\u002Flibs\u002Fdoca-flow\u002FCAPABILITIES.md);\nfor cross-language application patterns, see\n[`doca-programming-guide`](..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md).\n\n## When to load this skill\n\nLoad this skill when the user is — or the agent needs to — invoke\n`doca_flow_tune` against a running or planned `doca-flow`\napplication (on host or BlueField Arm, or inside the public NGC\nDOCA container with the matching Flow trace-build flavor) to\ncharacterize, dump, visualize, analyze, or tune that pipeline.\nConcretely:\n\n- Picking *which* role of `doca_flow_tune` to engage (offline\n  analyze \u002F visualize on a captured config + state, online\n  dumper \u002F monitor against the live Flow app, or attach-to-app\n  server-role usage when the Flow application links the\n  documented tune server entry points).\n- Picking *which* tuning axis to ask about (rule placement,\n  resource hints \u002F table sizing, or hardware-offload-mode) for a\n  candidate workload.\n- Picking *which* measurement axis to compare against (rule-install\n  rate, lookup latency, hardware-counter delta) — the three are\n  not interchangeable and the chosen axis should be the same one a\n  prior `doca-flow-perf` baseline named.\n- Capturing a documented before \u002F after pair around a proposed\n  Flow-program change (the documented JSON config file path, the\n  command line, the DOCA version, the device, the as-deployed\n  environment, the full unredacted dumper \u002F analyzer \u002F visualizer\n  output).\n- Diagnosing why a tune session produced empty output, a\n  visualize step rendered a degenerate diagram, or an analyze\n  recommendation does not match what the live counters say.\n\nDo **not** load this skill for general DOCA orientation, Flow\nprogram API work, install, or pure measurement methodology.\nFor those, route to\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md),\n[`doca-flow`](..\u002F..\u002Flibs\u002Fdoca-flow\u002FSKILL.md),\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md), or\n[`doca-flow-perf`](..\u002Fdoca-flow-perf\u002FSKILL.md).\n\n## What this skill provides\n\nThis is a **thin loader**. Substantive material lives in two\ncompanion files:\n\n- `CAPABILITIES.md` — what `doca_flow_tune` observes and\n  recommends on: the unified-artifact decomposition (server role\n  + client \u002F consumer role inside one binary), the three-axis\n  configuration model (tuning axis × measurement × scope: which\n  pipe \u002F port \u002F app), the documented offline \u002F online \u002F attach\n  modes, the JSON configuration-file shape (the publicly-shipped\n  `flow_tune_cfg_public.json` template plus its hardware-only and\n  software-only variants), the dumper \u002F monitor \u002F analyze \u002F\n  visualize output surfaces, the version overlay (this tool rides\n  the `doca-flow` library version it observes; the canonical\n  rules live in [`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md)),\n  the layered error taxonomy\n  (config-syntax \u002F attach-failed \u002F pipe-not-found \u002F\n  measurement-unsound \u002F recommendation-unactionable \u002F version \u002F\n  cross-cutting), the observability posture (the tool *is* an\n  observability primitive for the Flow pipeline), and the safety\n  policy that makes any mutating application of a recommendation\n  high-stakes because the recommendation lands in live Flow state.\n- `TASKS.md` — step-by-step workflows for the in-scope task verbs:\n  `install` (route to setup; the binary is shipped),\n  `configure` (the three-axis decision + JSON config + mode pick),\n  `build` (route to install; the binary is shipped), `modify`\n  (apply a recommendation back to the Flow program via minimum-\n  diff), `run` (the snapshot → analyze → visualize flow), `test`\n  (the eval loop — warm-up, steady-state, before \u002F after pair,\n  client \u002F server \u002F Flow version match), `debug` (walk the error\n  taxonomy layer by layer), `use` (the agent-side workflow for\n  consuming flow-tune output), plus a `Deferred task verbs` block\n  and a `Command appendix`.\n\nThe skill assumes a host where DOCA is already installed (or the\npublic NGC DOCA container is running) and a `doca-flow`\napplication is already created and validated per the\n[`doca-flow`](..\u002F..\u002Flibs\u002Fdoca-flow\u002FSKILL.md) skill. Without those\npreconditions, the tune session has nothing to observe.\n\n## What this skill deliberately does not ship\n\nThis skill is **agent guidance**, not a samples or scripts bundle.\nTo keep the boundary clean, it deliberately does not contain —\nand pull requests should not add:\n\n- **Verbatim flag inventories, subcommand names, JSON config field\n  names, or default endpoint paths quoted as the contract.** The\n  public DOCA Flow Tune guide on `docs.nvidia.com` (reached via\n  [`doca-public-knowledge-map ## DOCA tools`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md#doca-tools))\n  and the installed `--help` on the user's version are the joint\n  source of truth; the shipped `flow_tune_cfg*.json` templates on\n  the user's install are the second source for the JSON schema.\n  Copying them here pins the skill to one release and silently\n  rots when the tool evolves.\n- **Pre-baked example output (dumper CSV columns, analyzer JSON\n  field names, visualizer mermaid output).** Output is install-,\n  device-, firmware-, NUMA-, Flow-pipe-, and DOCA-version-specific;\n  a captured example pinned to one platform misleads operators on\n  a different platform \u002F version.\n- **Wrappers, parsers, or scripts** in any language that consume\n  flow-tune output. The output formats are documented and the\n  shipped `scripts\u002F` directory on the user's install contains\n  vendor-provided helpers (e.g. `flow_json_diff.py`,\n  `flow_mermaid_diff.py`, `hw_counters_csv_analyzer.py`); if a\n  user wants to script against the outputs, the right answer is\n  *\"read the shipped scripts on your installed version\"*.\n- **Pre-baked tuning recommendations.** Recommendations from this\n  tool are install-, device-, firmware-, and workload-specific;\n  shipping one for *\"hairpin pipes\"* or *\"NAT pipes\"* misleads\n  operators applying it to a different pipe. The agent always\n  re-derives the recommendation from the user's actual session.\n- **A `samples\u002F`, `templates\u002F`, or `reference\u002F` subtree.** Mock or\n  incomplete tuning recipes in this skill's tree are misleading;\n  operators read them as production-grade.\n\n## Loading order\n\n1. Read this `SKILL.md` first to confirm the user's question is\n   in scope (the user actually wants to invoke `doca_flow_tune`\n   against a `doca-flow` pipeline, not measure baseline perf or\n   learn the Flow API).\n2. **For what `doca_flow_tune` observes, the one-binary \u002F two-role\n   decomposition, the three-axis model, the version overlay, the\n   error taxonomy, observability surface, and safety posture,\n   see [CAPABILITIES.md](CAPABILITIES.md).**\n3. **For the documented invocations and the snapshot → analyze →\n   visualize → propose → smoke workflow — `install`, `configure`,\n   `build`, `modify`, `run`, `test`, `debug`, `use` — see\n   [TASKS.md](TASKS.md).**\n\n## Related skills\n\n- [`doca-flow`](..\u002F..\u002Flibs\u002Fdoca-flow\u002FSKILL.md) — the **base\n  library** whose pipeline this tool observes and tunes. The\n  pipe \u002F entry \u002F rule surface flow-tune reports on is created by\n  `doca-flow` program code; recommendations route back into that\n  program via the universal modify-a-sample workflow.\n- [`doca-flow-perf`](..\u002Fdoca-flow-perf\u002FSKILL.md) — the sibling\n  *measurement* tool. The rule is: `doca-flow-perf` measures\n  baselines; `doca-flow-tune` recommends optimizations on top.\n  An agent that reaches for tune without a baseline number from\n  perf is optimizing in the dark; an agent that reaches for perf\n  without a question is benchmarking for the sake of it.\n- [`doca-flow-dpa-perf`](..\u002Fdoca-flow-dpa-perf\u002FSKILL.md) — the\n  DPA-offloaded variant of Flow perf. Relevant when the Flow\n  pipeline the user is tuning runs through a DPA-offload path;\n  the baseline comes from there, not from host-side\n  `doca-flow-perf`.\n- [`doca-flow-grpc-server`](..\u002Fdoca-flow-grpc-server\u002FSKILL.md) —\n  the remote-control gRPC surface for `doca-flow`. Programmatic\n  Flow rule management lives there; flow-tune's recommendations\n  may be applied through that surface when the operator's\n  control plane is remote.\n- [`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\n  — routing to the public DOCA Flow Tune page on `docs.nvidia.com`\n  and the rest of the public DOCA documentation set.\n- [`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) — the canonical\n  version-detection chain, four-way match, NGC semantics, and\n  headers-win-over-docs rule. The\n  [`## Version compatibility`](CAPABILITIES.md#version-compatibility)\n  overlay in this skill is a thin extension on top.\n- [`doca-debug`](..\u002F..\u002Fdoca-debug\u002FSKILL.md) — the cross-cutting\n  debug ladder. Flow-tune surfaces *its own* error taxonomy; when\n  the cause turns out to be below DOCA (driver, firmware, NUMA),\n  the tune taxonomy hands off to `doca-debug`.\n- [`doca-structured-tools-contract`](..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md)\n  — the bundle's detect → prefer → fall back → report contract.\n  The Command appendix in [`TASKS.md`](TASKS.md) honors it.\n- [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) — env preparation,\n  install verification, hugepages, NUMA, and the *I have no\n  install yet* path with the public NGC DOCA container.\n- [`doca-hardware-safety`](..\u002F..\u002Fdoca-hardware-safety\u002FSKILL.md) —\n  the cross-cutting hardware-safety meta-policy this skill's\n  `## Safety policy` overlays.\n",{"data":35,"body":39},{"license":26,"name":4,"description":6,"metadata":36,"compatibility":38},{"kind":37},"tool","Requires DOCA SDK installed at \u002Fopt\u002Fmellanox\u002Fdoca on Linux (Ubuntu 22.04\u002F24.04 or RHEL\u002FSLES) with a BlueField DPU or ConnectX NIC attached, plus a running or captured `doca-flow` application to observe. Reads the user's local install via `pkg-config doca-flow` and the shipped `flow_tune_cfg*.json` templates and `scripts\u002F` directory under \u002Fopt\u002Fmellanox\u002Fdoca.\n",{"type":40,"children":41},"root",[42,60,368,504,511,523,824,830,849,915,991,1038,1044,1100,1106,1125,1184,1234,1240,1252,1403,1425,1431,1443,1601,1607,1720,1726],{"type":43,"tag":44,"props":45,"children":47},"element","h1",{"id":46},"doca-flow-tune-doca_flow_tune",[48,51,58],{"type":49,"value":50},"text","DOCA Flow Tune (",{"type":43,"tag":52,"props":53,"children":55},"code",{"className":54},[],[56],{"type":49,"value":57},"doca_flow_tune",{"type":49,"value":59},")",{"type":43,"tag":61,"props":62,"children":63},"blockquote",{},[64],{"type":43,"tag":65,"props":66,"children":67},"p",{},[68,74,79,81,86,88,94,96,102,103,109,111,117,118,124,126,132,134,140,142,147,149,155,157,163,164,170,172,178,180,185,186,191,192,197,199,204,206,212,214,220,222,228,230,235,236,241,243,248,250,256,258,268,269,278,280,286,288,293,295,300,302,307,308,313,315,320,322,327,328,333,334,339,341,346,348,353,354,359,361,366],{"type":43,"tag":69,"props":70,"children":71},"strong",{},[72],{"type":49,"value":73},"Subcommand surface correction (Run-12, verified Run-13\nagainst doca\u002Ftools\u002Fflow_tune\u002Fsrc\u002Ftune\u002Fcommon\u002Ftune_config.cpp).",{"type":43,"tag":52,"props":75,"children":77},{"className":76},[],[78],{"type":49,"value":57},{"type":49,"value":80}," is a single binary whose ",{"type":43,"tag":69,"props":82,"children":83},{},[84],{"type":49,"value":85},"role on a given\ninvocation is determined by which of five top-level\nsubcommands",{"type":49,"value":87}," the user picks — ",{"type":43,"tag":52,"props":89,"children":91},{"className":90},[],[92],{"type":49,"value":93},"dump",{"type":49,"value":95},", ",{"type":43,"tag":52,"props":97,"children":99},{"className":98},[],[100],{"type":49,"value":101},"monitor",{"type":49,"value":95},{"type":43,"tag":52,"props":104,"children":106},{"className":105},[],[107],{"type":49,"value":108},"web",{"type":49,"value":110},",\n",{"type":43,"tag":52,"props":112,"children":114},{"className":113},[],[115],{"type":49,"value":116},"analyze",{"type":49,"value":95},{"type":43,"tag":52,"props":119,"children":121},{"className":120},[],[122],{"type":49,"value":123},"visualize",{"type":49,"value":125}," (case-insensitive on the CLI;\nuppercased in this skill for readability). All five names\nare registered via ",{"type":43,"tag":52,"props":127,"children":129},{"className":128},[],[130],{"type":49,"value":131},"doca_argp_cmd_set_name(...)",{"type":49,"value":133}," in\n",{"type":43,"tag":52,"props":135,"children":137},{"className":136},[],[138],{"type":49,"value":139},"tune_config.cpp",{"type":49,"value":141}," (lines 1799 \u002F 1860 \u002F 1896 \u002F 2074 \u002F 2111);\n",{"type":43,"tag":52,"props":143,"children":145},{"className":144},[],[146],{"type":49,"value":116},{"type":49,"value":148}," further accepts ",{"type":43,"tag":52,"props":150,"children":152},{"className":151},[],[153],{"type":49,"value":154},"import",{"type":49,"value":156}," \u002F ",{"type":43,"tag":52,"props":158,"children":160},{"className":159},[],[161],{"type":49,"value":162},"export",{"type":49,"value":156},{"type":43,"tag":52,"props":165,"children":167},{"className":166},[],[168],{"type":49,"value":169},"packet_trace",{"type":49,"value":171},"\n\u002F ",{"type":43,"tag":52,"props":173,"children":175},{"className":174},[],[176],{"type":49,"value":177},"sim_timing",{"type":49,"value":179}," sub-subcommands. The ",{"type":43,"tag":52,"props":181,"children":183},{"className":182},[],[184],{"type":49,"value":93},{"type":49,"value":156},{"type":43,"tag":52,"props":187,"children":189},{"className":188},[],[190],{"type":49,"value":101},{"type":49,"value":156},{"type":43,"tag":52,"props":193,"children":195},{"className":194},[],[196],{"type":49,"value":108},{"type":49,"value":198},"\nsubcommands run the binary in ",{"type":43,"tag":69,"props":200,"children":201},{},[202],{"type":49,"value":203},"server-attached online mode",{"type":49,"value":205},"\nagainst a live ",{"type":43,"tag":52,"props":207,"children":209},{"className":208},[],[210],{"type":49,"value":211},"doca-flow",{"type":49,"value":213}," application reached over a Unix-\ndomain socket whose path lives in ",{"type":43,"tag":52,"props":215,"children":217},{"className":216},[],[218],{"type":49,"value":219},"network.server_uds",{"type":49,"value":221}," of the\nshipped ",{"type":43,"tag":52,"props":223,"children":225},{"className":224},[],[226],{"type":49,"value":227},"flow_tune_cfg*.json",{"type":49,"value":229},"; the ",{"type":43,"tag":52,"props":231,"children":233},{"className":232},[],[234],{"type":49,"value":116},{"type":49,"value":156},{"type":43,"tag":52,"props":237,"children":239},{"className":238},[],[240],{"type":49,"value":123},{"type":49,"value":242},"\nsubcommands run in ",{"type":43,"tag":69,"props":244,"children":245},{},[246],{"type":49,"value":247},"offline \u002F captured-snapshot mode",{"type":49,"value":249}," against\nJSON \u002F CSV files the online modes previously dropped into the\nconfigured ",{"type":43,"tag":52,"props":251,"children":253},{"className":252},[],[254],{"type":49,"value":255},"outputs_directory",{"type":49,"value":257},". The rest of this skill (and\n",{"type":43,"tag":259,"props":260,"children":262},"a",{"href":261},"CAPABILITIES.md",[263],{"type":43,"tag":52,"props":264,"children":266},{"className":265},[],[267],{"type":49,"value":261},{"type":49,"value":156},{"type":43,"tag":259,"props":270,"children":272},{"href":271},"TASKS.md",[273],{"type":43,"tag":52,"props":274,"children":276},{"className":275},[],[277],{"type":49,"value":271},{"type":49,"value":279},")\nuses the legacy ",{"type":43,"tag":281,"props":282,"children":283},"em",{},[284],{"type":49,"value":285},"\"server role \u002F online mode \u002F offline mode\"",{"type":49,"value":287},"\nframing — that framing is internally consistent with the\nsubcommand surface here: ",{"type":43,"tag":281,"props":289,"children":290},{},[291],{"type":49,"value":292},"server role",{"type":49,"value":294}," = a server-attached\nonline subcommand (",{"type":43,"tag":52,"props":296,"children":298},{"className":297},[],[299],{"type":49,"value":93},{"type":49,"value":301},"\u002F",{"type":43,"tag":52,"props":303,"children":305},{"className":304},[],[306],{"type":49,"value":101},{"type":49,"value":301},{"type":43,"tag":52,"props":309,"children":311},{"className":310},[],[312],{"type":49,"value":108},{"type":49,"value":314},"); ",{"type":43,"tag":281,"props":316,"children":317},{},[318],{"type":49,"value":319},"online mode",{"type":49,"value":321}," =\nany of ",{"type":43,"tag":52,"props":323,"children":325},{"className":324},[],[326],{"type":49,"value":93},{"type":49,"value":301},{"type":43,"tag":52,"props":329,"children":331},{"className":330},[],[332],{"type":49,"value":101},{"type":49,"value":301},{"type":43,"tag":52,"props":335,"children":337},{"className":336},[],[338],{"type":49,"value":108},{"type":49,"value":340},"; ",{"type":43,"tag":281,"props":342,"children":343},{},[344],{"type":49,"value":345},"offline mode",{"type":49,"value":347}," =\n",{"type":43,"tag":52,"props":349,"children":351},{"className":350},[],[352],{"type":49,"value":116},{"type":49,"value":301},{"type":43,"tag":52,"props":355,"children":357},{"className":356},[],[358],{"type":49,"value":123},{"type":49,"value":360},". Treat the subcommand name as the\nprimary handle; treat ",{"type":43,"tag":281,"props":362,"children":363},{},[364],{"type":49,"value":365},"server\u002Fonline\u002Foffline",{"type":49,"value":367}," as the\ndownstream behavioral consequence of the subcommand pick.",{"type":43,"tag":65,"props":369,"children":370},{},[371,376,378,383,385,393,395,405,407,417,419,429,431,439,441,453,454,459,460,465,467,472,474,484,486,491,493,502],{"type":43,"tag":69,"props":372,"children":373},{},[374],{"type":49,"value":375},"Where to start:",{"type":49,"value":377}," This is a tool skill for invoking ",{"type":43,"tag":52,"props":379,"children":381},{"className":380},[],[382],{"type":49,"value":57},{"type":49,"value":384},",\nthe unified DOCA Flow tuning tool. Open ",{"type":43,"tag":259,"props":386,"children":387},{"href":271},[388],{"type":43,"tag":52,"props":389,"children":391},{"className":390},[],[392],{"type":49,"value":271},{"type":49,"value":394}," and\nstart at ",{"type":43,"tag":259,"props":396,"children":398},{"href":397},"TASKS.md#configure",[399],{"type":43,"tag":52,"props":400,"children":402},{"className":401},[],[403],{"type":49,"value":404},"## configure",{"type":49,"value":406}," to commit to the\nthree-axis decision (target Flow pipeline × tuning axis ×\nmeasurement) and pick offline vs online vs server-attach mode, then\n",{"type":43,"tag":259,"props":408,"children":410},{"href":409},"TASKS.md#run",[411],{"type":43,"tag":52,"props":412,"children":414},{"className":413},[],[415],{"type":49,"value":416},"## run",{"type":49,"value":418}," for the snapshot → analyze → visualize\nloop, then ",{"type":43,"tag":259,"props":420,"children":422},{"href":421},"TASKS.md#test",[423],{"type":43,"tag":52,"props":424,"children":426},{"className":425},[],[427],{"type":49,"value":428},"## test",{"type":49,"value":430}," for the smoke-before-bulk\noverlay that gates any state-changing application of a tuning\nrecommendation back into the Flow application's code. Open\n",{"type":43,"tag":259,"props":432,"children":433},{"href":261},[434],{"type":43,"tag":52,"props":435,"children":437},{"className":436},[],[438],{"type":49,"value":261},{"type":49,"value":440}," when the question is ",{"type":43,"tag":281,"props":442,"children":443},{},[444,446,451],{"type":49,"value":445},"what\nstate ",{"type":43,"tag":52,"props":447,"children":449},{"className":448},[],[450],{"type":49,"value":57},{"type":49,"value":452}," can observe and recommend on",{"type":49,"value":95},{"type":43,"tag":281,"props":455,"children":456},{},[457],{"type":49,"value":458},"how its\nserver \u002F client roles fit inside the single artifact",{"type":49,"value":95},{"type":43,"tag":281,"props":461,"children":462},{},[463],{"type":49,"value":464},"which DOCA\nversion the tool ships in",{"type":49,"value":466},", or ",{"type":43,"tag":281,"props":468,"children":469},{},[470],{"type":49,"value":471},"how to interpret the dumper \u002F monitor\n\u002F analyze \u002F visualize outputs without fooling yourself",{"type":49,"value":473},". If DOCA is\nnot installed, route to\n",{"type":43,"tag":259,"props":475,"children":477},{"href":476},"..\u002F..\u002Fdoca-setup\u002FSKILL.md",[478],{"type":43,"tag":52,"props":479,"children":481},{"className":480},[],[482],{"type":49,"value":483},"doca-setup",{"type":49,"value":485}," first; if the user has\nno running ",{"type":43,"tag":52,"props":487,"children":489},{"className":488},[],[490],{"type":49,"value":211},{"type":49,"value":492}," application yet, route to\n",{"type":43,"tag":259,"props":494,"children":496},{"href":495},"..\u002F..\u002Flibs\u002Fdoca-flow\u002FSKILL.md",[497],{"type":43,"tag":52,"props":498,"children":500},{"className":499},[],[501],{"type":49,"value":211},{"type":49,"value":503}," — flow-tune does not\ncreate pipes, it observes and recommends on top of pipes the\nlibrary already created.",{"type":43,"tag":505,"props":506,"children":508},"h2",{"id":507},"example-questions-this-skill-answers-well",[509],{"type":49,"value":510},"Example questions this skill answers well",{"type":43,"tag":65,"props":512,"children":513},{},[514,516,521],{"type":49,"value":515},"The CLASSES of ",{"type":43,"tag":52,"props":517,"children":519},{"className":518},[],[520],{"type":49,"value":57},{"type":49,"value":522}," questions this skill is built to\nanswer, each with one worked example. The class is the load-bearing\npiece; the worked example is one instance.",{"type":43,"tag":524,"props":525,"children":526},"ul",{},[527,590,637,680,729,773],{"type":43,"tag":528,"props":529,"children":530},"li",{},[531,551,553,558,560,565,567,577,579,588],{"type":43,"tag":69,"props":532,"children":533},{},[534,536,541,543,549],{"type":49,"value":535},"\"Should I reach for ",{"type":43,"tag":52,"props":537,"children":539},{"className":538},[],[540],{"type":49,"value":4},{"type":49,"value":542}," or ",{"type":43,"tag":52,"props":544,"children":546},{"className":545},[],[547],{"type":49,"value":548},"doca-flow-perf",{"type":49,"value":550}," for\nthis question?\"",{"type":49,"value":552}," — worked example: ",{"type":43,"tag":281,"props":554,"children":555},{},[556],{"type":49,"value":557},"\"my doca-flow service runs\non a BlueField-3 and I think the rule-install rate is below what\nthe device can sustain; do I measure first or tune first?\"",{"type":49,"value":559},".\nAnswered by the ",{"type":43,"tag":281,"props":561,"children":562},{},[563],{"type":49,"value":564},"tune vs perf",{"type":49,"value":566}," boundary in\n",{"type":43,"tag":259,"props":568,"children":570},{"href":569},"CAPABILITIES.md#capabilities-and-modes",[571],{"type":43,"tag":52,"props":572,"children":574},{"className":573},[],[575],{"type":49,"value":576},"CAPABILITIES.md ## Capabilities and modes",{"type":49,"value":578},"\nand the routing into\n",{"type":43,"tag":259,"props":580,"children":582},{"href":581},"..\u002Fdoca-flow-perf\u002FSKILL.md",[583],{"type":43,"tag":52,"props":584,"children":586},{"className":585},[],[587],{"type":49,"value":548},{"type":49,"value":589}," for baselines vs\nthis skill for optimization on top of a measured baseline.",{"type":43,"tag":528,"props":591,"children":592},{},[593,605,607,612,614,623,625,635],{"type":43,"tag":69,"props":594,"children":595},{},[596,598,603],{"type":49,"value":597},"\"Capture a snapshot of a live ",{"type":43,"tag":52,"props":599,"children":601},{"className":600},[],[602],{"type":49,"value":211},{"type":49,"value":604}," pipeline's hardware\nand software counters without touching the dataplane.\"",{"type":49,"value":606}," — worked\nexample: ",{"type":43,"tag":281,"props":608,"children":609},{},[610],{"type":49,"value":611},"\"I want a side-effect-free dumper \u002F monitor run against\nthe running Flow ports for an operations-rate profile\"",{"type":49,"value":613},". Answered\nby the snapshot flow in\n",{"type":43,"tag":259,"props":615,"children":616},{"href":409},[617],{"type":43,"tag":52,"props":618,"children":620},{"className":619},[],[621],{"type":49,"value":622},"TASKS.md ## run",{"type":49,"value":624}," plus the read-only-by-default\nposture in\n",{"type":43,"tag":259,"props":626,"children":628},{"href":627},"CAPABILITIES.md#safety-policy",[629],{"type":43,"tag":52,"props":630,"children":632},{"className":631},[],[633],{"type":49,"value":634},"CAPABILITIES.md ## Safety policy",{"type":49,"value":636},".",{"type":43,"tag":528,"props":638,"children":639},{},[640,645,647,652,654,662],{"type":43,"tag":69,"props":641,"children":642},{},[643],{"type":49,"value":644},"\"Pick the right tuning axis — rule placement, resource hints,\nor hardware-offload mode — for the question I actually have.\"",{"type":49,"value":646},"\n— worked example: ",{"type":43,"tag":281,"props":648,"children":649},{},[650],{"type":49,"value":651},"\"my Flow pipe's rule-install rate is low; is\nthis a placement question or a table-sizing question?\"",{"type":49,"value":653},". Answered\nby the three-axis configuration in\n",{"type":43,"tag":259,"props":655,"children":656},{"href":569},[657],{"type":43,"tag":52,"props":658,"children":660},{"className":659},[],[661],{"type":49,"value":576},{"type":43,"tag":524,"props":663,"children":664},{},[665],{"type":43,"tag":528,"props":666,"children":667},{},[668,670,679],{"type":49,"value":669},"the configure walk in\n",{"type":43,"tag":259,"props":671,"children":672},{"href":397},[673],{"type":43,"tag":52,"props":674,"children":676},{"className":675},[],[677],{"type":49,"value":678},"TASKS.md ## configure",{"type":49,"value":636},{"type":43,"tag":528,"props":681,"children":682},{},[683,695,696,701,703,708,710,718,720,728],{"type":43,"tag":69,"props":684,"children":685},{},[686,688,693],{"type":49,"value":687},"\"How do ",{"type":43,"tag":52,"props":689,"children":691},{"className":690},[],[692],{"type":49,"value":57},{"type":49,"value":694},"'s server role and client \u002F consumer\nrole fit together inside the single artifact?\"",{"type":49,"value":606},{"type":43,"tag":281,"props":697,"children":698},{},[699],{"type":49,"value":700},"\"I keep reading about a Flow Tune server and a Flow\nTune client; which binary am I running?\"",{"type":49,"value":702},". Answered by the\n",{"type":43,"tag":281,"props":704,"children":705},{},[706],{"type":49,"value":707},"one binary, two roles",{"type":49,"value":709}," breakdown in\n",{"type":43,"tag":259,"props":711,"children":712},{"href":569},[713],{"type":43,"tag":52,"props":714,"children":716},{"className":715},[],[717],{"type":49,"value":576},{"type":49,"value":719},"\nand the corresponding routing in\n",{"type":43,"tag":259,"props":721,"children":722},{"href":397},[723],{"type":43,"tag":52,"props":724,"children":726},{"className":725},[],[727],{"type":49,"value":678},{"type":49,"value":636},{"type":43,"tag":528,"props":730,"children":731},{},[732,737,738,743,744,749,751,761,763,772],{"type":43,"tag":69,"props":733,"children":734},{},[735],{"type":49,"value":736},"\"How do I take a recommended parameter change from flow-tune\nback into my doca-flow application without breaking the\ndataplane?\"",{"type":49,"value":552},{"type":43,"tag":281,"props":739,"children":740},{},[741],{"type":49,"value":742},"\"the analyze step suggests a\ndifferent table sizing for my pipe; how do I apply it?\"",{"type":49,"value":559},{"type":43,"tag":281,"props":745,"children":746},{},[747],{"type":49,"value":748},"recommendation → minimum-diff modification of\nthe Flow program",{"type":49,"value":750}," loop in\n",{"type":43,"tag":259,"props":752,"children":754},{"href":753},"TASKS.md#modify",[755],{"type":43,"tag":52,"props":756,"children":758},{"className":757},[],[759],{"type":49,"value":760},"TASKS.md ## modify",{"type":49,"value":762}," and the\nsmoke-before-bulk rule in\n",{"type":43,"tag":259,"props":764,"children":765},{"href":421},[766],{"type":43,"tag":52,"props":767,"children":769},{"className":768},[],[770],{"type":49,"value":771},"TASKS.md ## test",{"type":49,"value":636},{"type":43,"tag":528,"props":774,"children":775},{},[776,788,790,795,797,807],{"type":43,"tag":69,"props":777,"children":778},{},[779,781,786],{"type":49,"value":780},"\"",{"type":43,"tag":52,"props":782,"children":784},{"className":783},[],[785],{"type":49,"value":57},{"type":49,"value":787}," reports nothing \u002F disagrees with the Flow\napp \u002F cannot attach — what does that mean?\"",{"type":49,"value":789}," — worked example:\n",{"type":43,"tag":281,"props":791,"children":792},{},[793],{"type":49,"value":794},"\"the tool runs but the visualize step produces an empty\nmermaid diagram\"",{"type":49,"value":796},". Answered by the layered error taxonomy in\n",{"type":43,"tag":259,"props":798,"children":800},{"href":799},"CAPABILITIES.md#error-taxonomy",[801],{"type":43,"tag":52,"props":802,"children":804},{"className":803},[],[805],{"type":49,"value":806},"CAPABILITIES.md ## Error taxonomy",{"type":43,"tag":524,"props":808,"children":809},{},[810],{"type":43,"tag":528,"props":811,"children":812},{},[813,823],{"type":43,"tag":259,"props":814,"children":816},{"href":815},"TASKS.md#debug",[817],{"type":43,"tag":52,"props":818,"children":820},{"className":819},[],[821],{"type":49,"value":822},"TASKS.md ## debug",{"type":49,"value":636},{"type":43,"tag":505,"props":825,"children":827},{"id":826},"audience",[828],{"type":49,"value":829},"Audience",{"type":43,"tag":65,"props":831,"children":832},{},[833,835,847],{"type":49,"value":834},"This skill serves ",{"type":43,"tag":69,"props":836,"children":837},{},[838,840,845],{"type":49,"value":839},"external operators, performance engineers,\nDOCA Flow application developers, and AI agents who need to\nunderstand, characterize, or improve a running ",{"type":43,"tag":52,"props":841,"children":843},{"className":842},[],[844],{"type":49,"value":211},{"type":49,"value":846},"\npipeline's behavior on the user's actual install and device",{"type":49,"value":848},".\nConcretely:",{"type":43,"tag":524,"props":850,"children":851},{},[852,864,890,903],{"type":43,"tag":528,"props":853,"children":854},{},[855,857,862],{"type":49,"value":856},"A platform operator running a ",{"type":43,"tag":52,"props":858,"children":860},{"className":859},[],[861],{"type":49,"value":211},{"type":49,"value":863}," service on BlueField\nwho wants a read-only snapshot of which pipes exist and how\ntheir hardware \u002F software counters are progressing before\nrecommending any change.",{"type":43,"tag":528,"props":865,"children":866},{},[867,869,874,876,881,883,888],{"type":49,"value":868},"A performance engineer who already has a ",{"type":43,"tag":52,"props":870,"children":872},{"className":871},[],[873],{"type":49,"value":548},{"type":49,"value":875},"\nbaseline number and wants to turn the ",{"type":43,"tag":281,"props":877,"children":878},{},[879],{"type":49,"value":880},"measurement",{"type":49,"value":882}," into an\n",{"type":43,"tag":281,"props":884,"children":885},{},[886],{"type":49,"value":887},"optimization",{"type":49,"value":889}," — pick a tuning axis and identify which knob in\nthe doca-flow program is the lever for it.",{"type":43,"tag":528,"props":891,"children":892},{},[893,895],{"type":49,"value":894},"A DOCA Flow application developer who wants the offline analyze\n",{"type":43,"tag":524,"props":896,"children":897},{},[898],{"type":43,"tag":528,"props":899,"children":900},{},[901],{"type":49,"value":902},"visualize loop to understand a pipe layout without\nre-instrumenting the Flow program.",{"type":43,"tag":528,"props":904,"children":905},{},[906,908,913],{"type":49,"value":907},"An AI agent driving the ",{"type":43,"tag":281,"props":909,"children":910},{},[911],{"type":49,"value":912},"\"is this Flow pipeline behaving as\nexpected, and would a non-mutating tuning hint help\"",{"type":49,"value":914}," triage\nstep before recommending any code change to the Flow program.",{"type":43,"tag":65,"props":916,"children":917},{},[918,920,925,927,932,934,938,940,946,947,951,953,958,960,968,970,974,976,980,982,990],{"type":49,"value":919},"It is ",{"type":43,"tag":69,"props":921,"children":922},{},[923],{"type":49,"value":924},"not",{"type":49,"value":926}," for users debugging the ",{"type":43,"tag":52,"props":928,"children":930},{"className":929},[],[931],{"type":49,"value":57},{"type":49,"value":933}," source code,\n",{"type":43,"tag":69,"props":935,"children":936},{},[937],{"type":49,"value":924},{"type":49,"value":939}," a substitute for the live public DOCA Flow Tune guide on\n",{"type":43,"tag":52,"props":941,"children":943},{"className":942},[],[944],{"type":49,"value":945},"docs.nvidia.com",{"type":49,"value":95},{"type":43,"tag":69,"props":948,"children":949},{},[950],{"type":49,"value":924},{"type":49,"value":952}," the right place to learn the\n",{"type":43,"tag":52,"props":954,"children":956},{"className":955},[],[957],{"type":49,"value":211},{"type":49,"value":959}," API (that audience belongs in\n",{"type":43,"tag":259,"props":961,"children":962},{"href":495},[963],{"type":43,"tag":52,"props":964,"children":966},{"className":965},[],[967],{"type":49,"value":211},{"type":49,"value":969},"), and ",{"type":43,"tag":69,"props":971,"children":972},{},[973],{"type":49,"value":924},{"type":49,"value":975}," the\nright place for baseline ",{"type":43,"tag":281,"props":977,"children":978},{},[979],{"type":49,"value":880},{"type":49,"value":981}," methodology — that belongs\nto ",{"type":43,"tag":259,"props":983,"children":984},{"href":581},[985],{"type":43,"tag":52,"props":986,"children":988},{"className":987},[],[989],{"type":49,"value":548},{"type":49,"value":636},{"type":43,"tag":65,"props":992,"children":993},{},[994,999,1001,1006,1008,1013,1015,1020,1022,1028,1030,1036],{"type":43,"tag":52,"props":995,"children":997},{"className":996},[],[998],{"type":49,"value":57},{"type":49,"value":1000}," is shipped as a ",{"type":43,"tag":69,"props":1002,"children":1003},{},[1004],{"type":49,"value":1005},"single tool",{"type":49,"value":1007}," (one binary plus\nits companion analyzer \u002F visualizer scripts and JSON config\ntemplates) — the historical ",{"type":43,"tag":281,"props":1009,"children":1010},{},[1011],{"type":49,"value":1012},"server",{"type":49,"value":1014}," and ",{"type":43,"tag":281,"props":1016,"children":1017},{},[1018],{"type":49,"value":1019},"client",{"type":49,"value":1021}," roles live\ninside this one artifact, not in two separate executables. The\nskill uses the same ",{"type":43,"tag":52,"props":1023,"children":1025},{"className":1024},[],[1026],{"type":49,"value":1027},"kind: tool",{"type":49,"value":1029}," three-file shape as the rest\nof the bundle so the agent's task-verb contract\n(",{"type":43,"tag":52,"props":1031,"children":1033},{"className":1032},[],[1034],{"type":49,"value":1035},"configure \u002F build \u002F modify \u002F run \u002F test \u002F debug",{"type":49,"value":1037},") is uniform\nacross libraries, services, and tools.",{"type":43,"tag":505,"props":1039,"children":1041},{"id":1040},"language-scope",[1042],{"type":49,"value":1043},"Language scope",{"type":43,"tag":65,"props":1045,"children":1046},{},[1047,1049,1054,1056,1068,1070,1075,1077,1087,1089,1099],{"type":49,"value":1048},"This skill governs invocation, output interpretation, and\nrecommendation-to-code-change routing for the C \u002F C++ DOCA Flow\napplication that ",{"type":43,"tag":52,"props":1050,"children":1052},{"className":1051},[],[1053],{"type":49,"value":57},{"type":49,"value":1055}," observes. The tool itself is\nnot a programming target — there is no public API the agent is\nsupposed to link against; what the agent and the user do with the\ntool is ",{"type":43,"tag":281,"props":1057,"children":1058},{},[1059,1061,1066],{"type":49,"value":1060},"configure JSON, run, read the outputs, propose minimum-\ndiff changes to the surrounding ",{"type":43,"tag":52,"props":1062,"children":1064},{"className":1063},[],[1065],{"type":49,"value":211},{"type":49,"value":1067}," program in the\nprogram's own language",{"type":49,"value":1069},". For the ",{"type":43,"tag":52,"props":1071,"children":1073},{"className":1072},[],[1074],{"type":49,"value":211},{"type":49,"value":1076}," API the\nrecommendations route back into, see\n",{"type":43,"tag":259,"props":1078,"children":1080},{"href":1079},"..\u002F..\u002Flibs\u002Fdoca-flow\u002FCAPABILITIES.md",[1081],{"type":43,"tag":52,"props":1082,"children":1084},{"className":1083},[],[1085],{"type":49,"value":1086},"doca-flow CAPABILITIES.md",{"type":49,"value":1088},";\nfor cross-language application patterns, see\n",{"type":43,"tag":259,"props":1090,"children":1092},{"href":1091},"..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md",[1093],{"type":43,"tag":52,"props":1094,"children":1096},{"className":1095},[],[1097],{"type":49,"value":1098},"doca-programming-guide",{"type":49,"value":636},{"type":43,"tag":505,"props":1101,"children":1103},{"id":1102},"when-to-load-this-skill",[1104],{"type":49,"value":1105},"When to load this skill",{"type":43,"tag":65,"props":1107,"children":1108},{},[1109,1111,1116,1118,1123],{"type":49,"value":1110},"Load this skill when the user is — or the agent needs to — invoke\n",{"type":43,"tag":52,"props":1112,"children":1114},{"className":1113},[],[1115],{"type":49,"value":57},{"type":49,"value":1117}," against a running or planned ",{"type":43,"tag":52,"props":1119,"children":1121},{"className":1120},[],[1122],{"type":49,"value":211},{"type":49,"value":1124},"\napplication (on host or BlueField Arm, or inside the public NGC\nDOCA container with the matching Flow trace-build flavor) to\ncharacterize, dump, visualize, analyze, or tune that pipeline.\nConcretely:",{"type":43,"tag":524,"props":1126,"children":1127},{},[1128,1147,1157,1174,1179],{"type":43,"tag":528,"props":1129,"children":1130},{},[1131,1133,1138,1140,1145],{"type":49,"value":1132},"Picking ",{"type":43,"tag":281,"props":1134,"children":1135},{},[1136],{"type":49,"value":1137},"which",{"type":49,"value":1139}," role of ",{"type":43,"tag":52,"props":1141,"children":1143},{"className":1142},[],[1144],{"type":49,"value":57},{"type":49,"value":1146}," to engage (offline\nanalyze \u002F visualize on a captured config + state, online\ndumper \u002F monitor against the live Flow app, or attach-to-app\nserver-role usage when the Flow application links the\ndocumented tune server entry points).",{"type":43,"tag":528,"props":1148,"children":1149},{},[1150,1151,1155],{"type":49,"value":1132},{"type":43,"tag":281,"props":1152,"children":1153},{},[1154],{"type":49,"value":1137},{"type":49,"value":1156}," tuning axis to ask about (rule placement,\nresource hints \u002F table sizing, or hardware-offload-mode) for a\ncandidate workload.",{"type":43,"tag":528,"props":1158,"children":1159},{},[1160,1161,1165,1167,1172],{"type":49,"value":1132},{"type":43,"tag":281,"props":1162,"children":1163},{},[1164],{"type":49,"value":1137},{"type":49,"value":1166}," measurement axis to compare against (rule-install\nrate, lookup latency, hardware-counter delta) — the three are\nnot interchangeable and the chosen axis should be the same one a\nprior ",{"type":43,"tag":52,"props":1168,"children":1170},{"className":1169},[],[1171],{"type":49,"value":548},{"type":49,"value":1173}," baseline named.",{"type":43,"tag":528,"props":1175,"children":1176},{},[1177],{"type":49,"value":1178},"Capturing a documented before \u002F after pair around a proposed\nFlow-program change (the documented JSON config file path, the\ncommand line, the DOCA version, the device, the as-deployed\nenvironment, the full unredacted dumper \u002F analyzer \u002F visualizer\noutput).",{"type":43,"tag":528,"props":1180,"children":1181},{},[1182],{"type":49,"value":1183},"Diagnosing why a tune session produced empty output, a\nvisualize step rendered a degenerate diagram, or an analyze\nrecommendation does not match what the live counters say.",{"type":43,"tag":65,"props":1185,"children":1186},{},[1187,1189,1193,1195,1205,1206,1214,1215,1223,1225,1233],{"type":49,"value":1188},"Do ",{"type":43,"tag":69,"props":1190,"children":1191},{},[1192],{"type":49,"value":924},{"type":49,"value":1194}," load this skill for general DOCA orientation, Flow\nprogram API work, install, or pure measurement methodology.\nFor those, route to\n",{"type":43,"tag":259,"props":1196,"children":1198},{"href":1197},"..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md",[1199],{"type":43,"tag":52,"props":1200,"children":1202},{"className":1201},[],[1203],{"type":49,"value":1204},"doca-public-knowledge-map",{"type":49,"value":110},{"type":43,"tag":259,"props":1207,"children":1208},{"href":495},[1209],{"type":43,"tag":52,"props":1210,"children":1212},{"className":1211},[],[1213],{"type":49,"value":211},{"type":49,"value":110},{"type":43,"tag":259,"props":1216,"children":1217},{"href":476},[1218],{"type":43,"tag":52,"props":1219,"children":1221},{"className":1220},[],[1222],{"type":49,"value":483},{"type":49,"value":1224},", or\n",{"type":43,"tag":259,"props":1226,"children":1227},{"href":581},[1228],{"type":43,"tag":52,"props":1229,"children":1231},{"className":1230},[],[1232],{"type":49,"value":548},{"type":49,"value":636},{"type":43,"tag":505,"props":1235,"children":1237},{"id":1236},"what-this-skill-provides",[1238],{"type":49,"value":1239},"What this skill provides",{"type":43,"tag":65,"props":1241,"children":1242},{},[1243,1245,1250],{"type":49,"value":1244},"This is a ",{"type":43,"tag":69,"props":1246,"children":1247},{},[1248],{"type":49,"value":1249},"thin loader",{"type":49,"value":1251},". Substantive material lives in two\ncompanion files:",{"type":43,"tag":524,"props":1253,"children":1254},{},[1255,1314],{"type":43,"tag":528,"props":1256,"children":1257},{},[1258,1263,1265,1270,1272],{"type":43,"tag":52,"props":1259,"children":1261},{"className":1260},[],[1262],{"type":49,"value":261},{"type":49,"value":1264}," — what ",{"type":43,"tag":52,"props":1266,"children":1268},{"className":1267},[],[1269],{"type":49,"value":57},{"type":49,"value":1271}," observes and\nrecommends on: the unified-artifact decomposition (server role\n",{"type":43,"tag":524,"props":1273,"children":1274},{},[1275],{"type":43,"tag":528,"props":1276,"children":1277},{},[1278,1280,1286,1288,1293,1295,1305,1307,1312],{"type":49,"value":1279},"client \u002F consumer role inside one binary), the three-axis\nconfiguration model (tuning axis × measurement × scope: which\npipe \u002F port \u002F app), the documented offline \u002F online \u002F attach\nmodes, the JSON configuration-file shape (the publicly-shipped\n",{"type":43,"tag":52,"props":1281,"children":1283},{"className":1282},[],[1284],{"type":49,"value":1285},"flow_tune_cfg_public.json",{"type":49,"value":1287}," template plus its hardware-only and\nsoftware-only variants), the dumper \u002F monitor \u002F analyze \u002F\nvisualize output surfaces, the version overlay (this tool rides\nthe ",{"type":43,"tag":52,"props":1289,"children":1291},{"className":1290},[],[1292],{"type":49,"value":211},{"type":49,"value":1294}," library version it observes; the canonical\nrules live in ",{"type":43,"tag":259,"props":1296,"children":1298},{"href":1297},"..\u002F..\u002Fdoca-version\u002FSKILL.md",[1299],{"type":43,"tag":52,"props":1300,"children":1302},{"className":1301},[],[1303],{"type":49,"value":1304},"doca-version",{"type":49,"value":1306},"),\nthe layered error taxonomy\n(config-syntax \u002F attach-failed \u002F pipe-not-found \u002F\nmeasurement-unsound \u002F recommendation-unactionable \u002F version \u002F\ncross-cutting), the observability posture (the tool ",{"type":43,"tag":281,"props":1308,"children":1309},{},[1310],{"type":49,"value":1311},"is",{"type":49,"value":1313}," an\nobservability primitive for the Flow pipeline), and the safety\npolicy that makes any mutating application of a recommendation\nhigh-stakes because the recommendation lands in live Flow state.",{"type":43,"tag":528,"props":1315,"children":1316},{},[1317,1322,1324,1330,1332,1338,1340,1346,1348,1354,1356,1362,1364,1370,1372,1378,1380,1386,1388,1394,1396,1402],{"type":43,"tag":52,"props":1318,"children":1320},{"className":1319},[],[1321],{"type":49,"value":271},{"type":49,"value":1323}," — step-by-step workflows for the in-scope task verbs:\n",{"type":43,"tag":52,"props":1325,"children":1327},{"className":1326},[],[1328],{"type":49,"value":1329},"install",{"type":49,"value":1331}," (route to setup; the binary is shipped),\n",{"type":43,"tag":52,"props":1333,"children":1335},{"className":1334},[],[1336],{"type":49,"value":1337},"configure",{"type":49,"value":1339}," (the three-axis decision + JSON config + mode pick),\n",{"type":43,"tag":52,"props":1341,"children":1343},{"className":1342},[],[1344],{"type":49,"value":1345},"build",{"type":49,"value":1347}," (route to install; the binary is shipped), ",{"type":43,"tag":52,"props":1349,"children":1351},{"className":1350},[],[1352],{"type":49,"value":1353},"modify",{"type":49,"value":1355},"\n(apply a recommendation back to the Flow program via minimum-\ndiff), ",{"type":43,"tag":52,"props":1357,"children":1359},{"className":1358},[],[1360],{"type":49,"value":1361},"run",{"type":49,"value":1363}," (the snapshot → analyze → visualize flow), ",{"type":43,"tag":52,"props":1365,"children":1367},{"className":1366},[],[1368],{"type":49,"value":1369},"test",{"type":49,"value":1371},"\n(the eval loop — warm-up, steady-state, before \u002F after pair,\nclient \u002F server \u002F Flow version match), ",{"type":43,"tag":52,"props":1373,"children":1375},{"className":1374},[],[1376],{"type":49,"value":1377},"debug",{"type":49,"value":1379}," (walk the error\ntaxonomy layer by layer), ",{"type":43,"tag":52,"props":1381,"children":1383},{"className":1382},[],[1384],{"type":49,"value":1385},"use",{"type":49,"value":1387}," (the agent-side workflow for\nconsuming flow-tune output), plus a ",{"type":43,"tag":52,"props":1389,"children":1391},{"className":1390},[],[1392],{"type":49,"value":1393},"Deferred task verbs",{"type":49,"value":1395}," block\nand a ",{"type":43,"tag":52,"props":1397,"children":1399},{"className":1398},[],[1400],{"type":49,"value":1401},"Command appendix",{"type":49,"value":636},{"type":43,"tag":65,"props":1404,"children":1405},{},[1406,1408,1413,1415,1423],{"type":49,"value":1407},"The skill assumes a host where DOCA is already installed (or the\npublic NGC DOCA container is running) and a ",{"type":43,"tag":52,"props":1409,"children":1411},{"className":1410},[],[1412],{"type":49,"value":211},{"type":49,"value":1414},"\napplication is already created and validated per the\n",{"type":43,"tag":259,"props":1416,"children":1417},{"href":495},[1418],{"type":43,"tag":52,"props":1419,"children":1421},{"className":1420},[],[1422],{"type":49,"value":211},{"type":49,"value":1424}," skill. Without those\npreconditions, the tune session has nothing to observe.",{"type":43,"tag":505,"props":1426,"children":1428},{"id":1427},"what-this-skill-deliberately-does-not-ship",[1429],{"type":49,"value":1430},"What this skill deliberately does not ship",{"type":43,"tag":65,"props":1432,"children":1433},{},[1434,1436,1441],{"type":49,"value":1435},"This skill is ",{"type":43,"tag":69,"props":1437,"children":1438},{},[1439],{"type":49,"value":1440},"agent guidance",{"type":49,"value":1442},", not a samples or scripts bundle.\nTo keep the boundary clean, it deliberately does not contain —\nand pull requests should not add:",{"type":43,"tag":524,"props":1444,"children":1445},{},[1446,1490,1500,1546,1569],{"type":43,"tag":528,"props":1447,"children":1448},{},[1449,1454,1456,1461,1463,1473,1475,1481,1483,1488],{"type":43,"tag":69,"props":1450,"children":1451},{},[1452],{"type":49,"value":1453},"Verbatim flag inventories, subcommand names, JSON config field\nnames, or default endpoint paths quoted as the contract.",{"type":49,"value":1455}," The\npublic DOCA Flow Tune guide on ",{"type":43,"tag":52,"props":1457,"children":1459},{"className":1458},[],[1460],{"type":49,"value":945},{"type":49,"value":1462}," (reached via\n",{"type":43,"tag":259,"props":1464,"children":1466},{"href":1465},"..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md#doca-tools",[1467],{"type":43,"tag":52,"props":1468,"children":1470},{"className":1469},[],[1471],{"type":49,"value":1472},"doca-public-knowledge-map ## DOCA tools",{"type":49,"value":1474},")\nand the installed ",{"type":43,"tag":52,"props":1476,"children":1478},{"className":1477},[],[1479],{"type":49,"value":1480},"--help",{"type":49,"value":1482}," on the user's version are the joint\nsource of truth; the shipped ",{"type":43,"tag":52,"props":1484,"children":1486},{"className":1485},[],[1487],{"type":49,"value":227},{"type":49,"value":1489}," templates on\nthe user's install are the second source for the JSON schema.\nCopying them here pins the skill to one release and silently\nrots when the tool evolves.",{"type":43,"tag":528,"props":1491,"children":1492},{},[1493,1498],{"type":43,"tag":69,"props":1494,"children":1495},{},[1496],{"type":49,"value":1497},"Pre-baked example output (dumper CSV columns, analyzer JSON\nfield names, visualizer mermaid output).",{"type":49,"value":1499}," Output is install-,\ndevice-, firmware-, NUMA-, Flow-pipe-, and DOCA-version-specific;\na captured example pinned to one platform misleads operators on\na different platform \u002F version.",{"type":43,"tag":528,"props":1501,"children":1502},{},[1503,1508,1510,1516,1518,1524,1525,1531,1532,1538,1540,1545],{"type":43,"tag":69,"props":1504,"children":1505},{},[1506],{"type":49,"value":1507},"Wrappers, parsers, or scripts",{"type":49,"value":1509}," in any language that consume\nflow-tune output. The output formats are documented and the\nshipped ",{"type":43,"tag":52,"props":1511,"children":1513},{"className":1512},[],[1514],{"type":49,"value":1515},"scripts\u002F",{"type":49,"value":1517}," directory on the user's install contains\nvendor-provided helpers (e.g. ",{"type":43,"tag":52,"props":1519,"children":1521},{"className":1520},[],[1522],{"type":49,"value":1523},"flow_json_diff.py",{"type":49,"value":110},{"type":43,"tag":52,"props":1526,"children":1528},{"className":1527},[],[1529],{"type":49,"value":1530},"flow_mermaid_diff.py",{"type":49,"value":95},{"type":43,"tag":52,"props":1533,"children":1535},{"className":1534},[],[1536],{"type":49,"value":1537},"hw_counters_csv_analyzer.py",{"type":49,"value":1539},"); if a\nuser wants to script against the outputs, the right answer is\n",{"type":43,"tag":281,"props":1541,"children":1542},{},[1543],{"type":49,"value":1544},"\"read the shipped scripts on your installed version\"",{"type":49,"value":636},{"type":43,"tag":528,"props":1547,"children":1548},{},[1549,1554,1556,1561,1562,1567],{"type":43,"tag":69,"props":1550,"children":1551},{},[1552],{"type":49,"value":1553},"Pre-baked tuning recommendations.",{"type":49,"value":1555}," Recommendations from this\ntool are install-, device-, firmware-, and workload-specific;\nshipping one for ",{"type":43,"tag":281,"props":1557,"children":1558},{},[1559],{"type":49,"value":1560},"\"hairpin pipes\"",{"type":49,"value":542},{"type":43,"tag":281,"props":1563,"children":1564},{},[1565],{"type":49,"value":1566},"\"NAT pipes\"",{"type":49,"value":1568}," misleads\noperators applying it to a different pipe. The agent always\nre-derives the recommendation from the user's actual session.",{"type":43,"tag":528,"props":1570,"children":1571},{},[1572,1599],{"type":43,"tag":69,"props":1573,"children":1574},{},[1575,1577,1583,1584,1590,1591,1597],{"type":49,"value":1576},"A ",{"type":43,"tag":52,"props":1578,"children":1580},{"className":1579},[],[1581],{"type":49,"value":1582},"samples\u002F",{"type":49,"value":95},{"type":43,"tag":52,"props":1585,"children":1587},{"className":1586},[],[1588],{"type":49,"value":1589},"templates\u002F",{"type":49,"value":466},{"type":43,"tag":52,"props":1592,"children":1594},{"className":1593},[],[1595],{"type":49,"value":1596},"reference\u002F",{"type":49,"value":1598}," subtree.",{"type":49,"value":1600}," Mock or\nincomplete tuning recipes in this skill's tree are misleading;\noperators read them as production-grade.",{"type":43,"tag":505,"props":1602,"children":1604},{"id":1603},"loading-order",[1605],{"type":49,"value":1606},"Loading order",{"type":43,"tag":1608,"props":1609,"children":1610},"ol",{},[1611,1638,1658],{"type":43,"tag":528,"props":1612,"children":1613},{},[1614,1616,1622,1624,1629,1631,1636],{"type":49,"value":1615},"Read this ",{"type":43,"tag":52,"props":1617,"children":1619},{"className":1618},[],[1620],{"type":49,"value":1621},"SKILL.md",{"type":49,"value":1623}," first to confirm the user's question is\nin scope (the user actually wants to invoke ",{"type":43,"tag":52,"props":1625,"children":1627},{"className":1626},[],[1628],{"type":49,"value":57},{"type":49,"value":1630},"\nagainst a ",{"type":43,"tag":52,"props":1632,"children":1634},{"className":1633},[],[1635],{"type":49,"value":211},{"type":49,"value":1637}," pipeline, not measure baseline perf or\nlearn the Flow API).",{"type":43,"tag":528,"props":1639,"children":1640},{},[1641],{"type":43,"tag":69,"props":1642,"children":1643},{},[1644,1646,1651,1653,1657],{"type":49,"value":1645},"For what ",{"type":43,"tag":52,"props":1647,"children":1649},{"className":1648},[],[1650],{"type":49,"value":57},{"type":49,"value":1652}," observes, the one-binary \u002F two-role\ndecomposition, the three-axis model, the version overlay, the\nerror taxonomy, observability surface, and safety posture,\nsee ",{"type":43,"tag":259,"props":1654,"children":1655},{"href":261},[1656],{"type":49,"value":261},{"type":49,"value":636},{"type":43,"tag":528,"props":1659,"children":1660},{},[1661],{"type":43,"tag":69,"props":1662,"children":1663},{},[1664,1666,1671,1672,1677,1678,1683,1684,1689,1690,1695,1696,1701,1702,1707,1708,1713,1715,1719],{"type":49,"value":1665},"For the documented invocations and the snapshot → analyze →\nvisualize → propose → smoke workflow — ",{"type":43,"tag":52,"props":1667,"children":1669},{"className":1668},[],[1670],{"type":49,"value":1329},{"type":49,"value":95},{"type":43,"tag":52,"props":1673,"children":1675},{"className":1674},[],[1676],{"type":49,"value":1337},{"type":49,"value":110},{"type":43,"tag":52,"props":1679,"children":1681},{"className":1680},[],[1682],{"type":49,"value":1345},{"type":49,"value":95},{"type":43,"tag":52,"props":1685,"children":1687},{"className":1686},[],[1688],{"type":49,"value":1353},{"type":49,"value":95},{"type":43,"tag":52,"props":1691,"children":1693},{"className":1692},[],[1694],{"type":49,"value":1361},{"type":49,"value":95},{"type":43,"tag":52,"props":1697,"children":1699},{"className":1698},[],[1700],{"type":49,"value":1369},{"type":49,"value":95},{"type":43,"tag":52,"props":1703,"children":1705},{"className":1704},[],[1706],{"type":49,"value":1377},{"type":49,"value":95},{"type":43,"tag":52,"props":1709,"children":1711},{"className":1710},[],[1712],{"type":49,"value":1385},{"type":49,"value":1714}," — see\n",{"type":43,"tag":259,"props":1716,"children":1717},{"href":271},[1718],{"type":49,"value":271},{"type":49,"value":636},{"type":43,"tag":505,"props":1721,"children":1723},{"id":1722},"related-skills",[1724],{"type":49,"value":1725},"Related skills",{"type":43,"tag":524,"props":1727,"children":1728},{},[1729,1756,1789,1810,1832,1852,1877,1905,1930,1950],{"type":43,"tag":528,"props":1730,"children":1731},{},[1732,1740,1742,1747,1749,1754],{"type":43,"tag":259,"props":1733,"children":1734},{"href":495},[1735],{"type":43,"tag":52,"props":1736,"children":1738},{"className":1737},[],[1739],{"type":49,"value":211},{"type":49,"value":1741}," — the ",{"type":43,"tag":69,"props":1743,"children":1744},{},[1745],{"type":49,"value":1746},"base\nlibrary",{"type":49,"value":1748}," whose pipeline this tool observes and tunes. The\npipe \u002F entry \u002F rule surface flow-tune reports on is created by\n",{"type":43,"tag":52,"props":1750,"children":1752},{"className":1751},[],[1753],{"type":49,"value":211},{"type":49,"value":1755}," program code; recommendations route back into that\nprogram via the universal modify-a-sample workflow.",{"type":43,"tag":528,"props":1757,"children":1758},{},[1759,1767,1769,1773,1775,1780,1782,1787],{"type":43,"tag":259,"props":1760,"children":1761},{"href":581},[1762],{"type":43,"tag":52,"props":1763,"children":1765},{"className":1764},[],[1766],{"type":49,"value":548},{"type":49,"value":1768}," — the sibling\n",{"type":43,"tag":281,"props":1770,"children":1771},{},[1772],{"type":49,"value":880},{"type":49,"value":1774}," tool. The rule is: ",{"type":43,"tag":52,"props":1776,"children":1778},{"className":1777},[],[1779],{"type":49,"value":548},{"type":49,"value":1781}," measures\nbaselines; ",{"type":43,"tag":52,"props":1783,"children":1785},{"className":1784},[],[1786],{"type":49,"value":4},{"type":49,"value":1788}," recommends optimizations on top.\nAn agent that reaches for tune without a baseline number from\nperf is optimizing in the dark; an agent that reaches for perf\nwithout a question is benchmarking for the sake of it.",{"type":43,"tag":528,"props":1790,"children":1791},{},[1792,1802,1804,1809],{"type":43,"tag":259,"props":1793,"children":1795},{"href":1794},"..\u002Fdoca-flow-dpa-perf\u002FSKILL.md",[1796],{"type":43,"tag":52,"props":1797,"children":1799},{"className":1798},[],[1800],{"type":49,"value":1801},"doca-flow-dpa-perf",{"type":49,"value":1803}," — the\nDPA-offloaded variant of Flow perf. Relevant when the Flow\npipeline the user is tuning runs through a DPA-offload path;\nthe baseline comes from there, not from host-side\n",{"type":43,"tag":52,"props":1805,"children":1807},{"className":1806},[],[1808],{"type":49,"value":548},{"type":49,"value":636},{"type":43,"tag":528,"props":1811,"children":1812},{},[1813,1823,1825,1830],{"type":43,"tag":259,"props":1814,"children":1816},{"href":1815},"..\u002Fdoca-flow-grpc-server\u002FSKILL.md",[1817],{"type":43,"tag":52,"props":1818,"children":1820},{"className":1819},[],[1821],{"type":49,"value":1822},"doca-flow-grpc-server",{"type":49,"value":1824}," —\nthe remote-control gRPC surface for ",{"type":43,"tag":52,"props":1826,"children":1828},{"className":1827},[],[1829],{"type":49,"value":211},{"type":49,"value":1831},". Programmatic\nFlow rule management lives there; flow-tune's recommendations\nmay be applied through that surface when the operator's\ncontrol plane is remote.",{"type":43,"tag":528,"props":1833,"children":1834},{},[1835,1843,1845,1850],{"type":43,"tag":259,"props":1836,"children":1837},{"href":1197},[1838],{"type":43,"tag":52,"props":1839,"children":1841},{"className":1840},[],[1842],{"type":49,"value":1204},{"type":49,"value":1844},"\n— routing to the public DOCA Flow Tune page on ",{"type":43,"tag":52,"props":1846,"children":1848},{"className":1847},[],[1849],{"type":49,"value":945},{"type":49,"value":1851},"\nand the rest of the public DOCA documentation set.",{"type":43,"tag":528,"props":1853,"children":1854},{},[1855,1863,1865,1875],{"type":43,"tag":259,"props":1856,"children":1857},{"href":1297},[1858],{"type":43,"tag":52,"props":1859,"children":1861},{"className":1860},[],[1862],{"type":49,"value":1304},{"type":49,"value":1864}," — the canonical\nversion-detection chain, four-way match, NGC semantics, and\nheaders-win-over-docs rule. The\n",{"type":43,"tag":259,"props":1866,"children":1868},{"href":1867},"CAPABILITIES.md#version-compatibility",[1869],{"type":43,"tag":52,"props":1870,"children":1872},{"className":1871},[],[1873],{"type":49,"value":1874},"## Version compatibility",{"type":49,"value":1876},"\noverlay in this skill is a thin extension on top.",{"type":43,"tag":528,"props":1878,"children":1879},{},[1880,1890,1892,1897,1899,1904],{"type":43,"tag":259,"props":1881,"children":1883},{"href":1882},"..\u002F..\u002Fdoca-debug\u002FSKILL.md",[1884],{"type":43,"tag":52,"props":1885,"children":1887},{"className":1886},[],[1888],{"type":49,"value":1889},"doca-debug",{"type":49,"value":1891}," — the cross-cutting\ndebug ladder. Flow-tune surfaces ",{"type":43,"tag":281,"props":1893,"children":1894},{},[1895],{"type":49,"value":1896},"its own",{"type":49,"value":1898}," error taxonomy; when\nthe cause turns out to be below DOCA (driver, firmware, NUMA),\nthe tune taxonomy hands off to ",{"type":43,"tag":52,"props":1900,"children":1902},{"className":1901},[],[1903],{"type":49,"value":1889},{"type":49,"value":636},{"type":43,"tag":528,"props":1906,"children":1907},{},[1908,1918,1920,1928],{"type":43,"tag":259,"props":1909,"children":1911},{"href":1910},"..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md",[1912],{"type":43,"tag":52,"props":1913,"children":1915},{"className":1914},[],[1916],{"type":49,"value":1917},"doca-structured-tools-contract",{"type":49,"value":1919},"\n— the bundle's detect → prefer → fall back → report contract.\nThe Command appendix in ",{"type":43,"tag":259,"props":1921,"children":1922},{"href":271},[1923],{"type":43,"tag":52,"props":1924,"children":1926},{"className":1925},[],[1927],{"type":49,"value":271},{"type":49,"value":1929}," honors it.",{"type":43,"tag":528,"props":1931,"children":1932},{},[1933,1941,1943,1948],{"type":43,"tag":259,"props":1934,"children":1935},{"href":476},[1936],{"type":43,"tag":52,"props":1937,"children":1939},{"className":1938},[],[1940],{"type":49,"value":483},{"type":49,"value":1942}," — env preparation,\ninstall verification, hugepages, NUMA, and the ",{"type":43,"tag":281,"props":1944,"children":1945},{},[1946],{"type":49,"value":1947},"I have no\ninstall yet",{"type":49,"value":1949}," path with the public NGC DOCA container.",{"type":43,"tag":528,"props":1951,"children":1952},{},[1953,1963,1965,1971],{"type":43,"tag":259,"props":1954,"children":1956},{"href":1955},"..\u002F..\u002Fdoca-hardware-safety\u002FSKILL.md",[1957],{"type":43,"tag":52,"props":1958,"children":1960},{"className":1959},[],[1961],{"type":49,"value":1962},"doca-hardware-safety",{"type":49,"value":1964}," —\nthe cross-cutting hardware-safety meta-policy this skill's\n",{"type":43,"tag":52,"props":1966,"children":1968},{"className":1967},[],[1969],{"type":49,"value":1970},"## Safety policy",{"type":49,"value":1972}," overlays.",{"items":1974,"total":2076},[1975,1990,2004,2018,2030,2047,2062],{"slug":1976,"name":1976,"fn":1977,"description":1978,"org":1979,"tags":1980,"stars":23,"repoUrl":24,"updatedAt":1989},"accelerated-computing-cudf","accelerate data processing with cuDF","Official NVIDIA-authored guidance for NVIDIA cuDF GPU DataFrames, pandas acceleration, dask-cuDF, ETL, joins, groupby, CSV\u002FParquet I\u002FO, nullable semantics, and multi-GPU DataFrame workloads.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1981,1984,1987,1988],{"name":1982,"slug":1983,"type":15},"Data Analysis","data-analysis",{"name":1985,"slug":1986,"type":15},"Data Engineering","data-engineering",{"name":9,"slug":8,"type":15},{"name":13,"slug":14,"type":15},"2026-07-14T05:28:43.176466",{"slug":1991,"name":1991,"fn":1992,"description":1993,"org":1994,"tags":1995,"stars":23,"repoUrl":24,"updatedAt":2003},"aiq-deploy","deploy and manage NVIDIA AI-Q infrastructure","Use when asked to install, deploy, run, validate, troubleshoot, or stop NVIDIA AI-Q Blueprint infrastructure.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1996,1999,2002],{"name":1997,"slug":1998,"type":15},"Deployment","deployment",{"name":2000,"slug":2001,"type":15},"Infrastructure","infrastructure",{"name":9,"slug":8,"type":15},"2026-07-14T05:29:06.667109",{"slug":2005,"name":2005,"fn":2006,"description":2007,"org":2008,"tags":2009,"stars":23,"repoUrl":24,"updatedAt":2017},"aiq-research","conduct deep research with AI-Q","Use when asked to run deep research or AI-Q research through a reachable NVIDIA AI-Q Blueprint backend.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2010,2013,2014],{"name":2011,"slug":2012,"type":15},"Agents","agents",{"name":9,"slug":8,"type":15},{"name":2015,"slug":2016,"type":15},"Research","research","2026-07-14T05:28:06.816956",{"slug":2019,"name":2019,"fn":2020,"description":2021,"org":2022,"tags":2023,"stars":23,"repoUrl":24,"updatedAt":2029},"amc-run-sample-calibration","run AMC sample dataset calibration","Run end-to-end calibration on the shipped sample dataset (sdg_08_2_sample_data_010926.zip) against a running AMC microservice. Use when user says 'test sample dataset', 'run sample calibration', 'verify AMC install', or 'launch and test'.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2024,2025,2026],{"name":1982,"slug":1983,"type":15},{"name":9,"slug":8,"type":15},{"name":2027,"slug":2028,"type":15},"Testing","testing","2026-07-17T05:29:03.913266",{"slug":2031,"name":2031,"fn":2032,"description":2033,"org":2034,"tags":2035,"stars":23,"repoUrl":24,"updatedAt":2046},"amc-run-video-calibration","calibrate video datasets with AutoMagicCalib","Calibrate a new dataset from pre-recorded video files via the AutoMagicCalib REST API. Use when user has local MP4s and says 'calibrate my videos', 'run AMC on these videos', or similar. For RTSP\u002Flive streams, use amc-run-rtsp-calibration instead.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2036,2039,2042,2043],{"name":2037,"slug":2038,"type":15},"Automation","automation",{"name":2040,"slug":2041,"type":15},"Imaging","imaging",{"name":9,"slug":8,"type":15},{"name":2044,"slug":2045,"type":15},"Video","video","2026-07-17T05:28:53.905004",{"slug":2048,"name":2048,"fn":2049,"description":2050,"org":2051,"tags":2052,"stars":23,"repoUrl":24,"updatedAt":2061},"amc-setup-calibration-stack","deploy AutoMagicCalib microservice with Docker","Launch AutoMagicCalib microservice and web UI from NGC release images via Docker Compose. Use when user says 'deploy auto calibration', 'launch auto calibration', 'launch AMC', 'start MS+UI', or 'set up auto-magic-calib'. Requires NGC API key.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2053,2054,2057,2058],{"name":1997,"slug":1998,"type":15},{"name":2055,"slug":2056,"type":15},"Docker","docker",{"name":9,"slug":8,"type":15},{"name":2059,"slug":2060,"type":15},"Operations","operations","2026-07-17T05:28:56.913999",{"slug":2063,"name":2063,"fn":2064,"description":2065,"org":2066,"tags":2067,"stars":23,"repoUrl":24,"updatedAt":2075},"cudaq-guide","develop quantum applications with CUDA-Q","CUDA-Q onboarding guide for installation, test programs, GPU simulation, QPU hardware, and quantum applications.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2068,2069,2072],{"name":9,"slug":8,"type":15},{"name":2070,"slug":2071,"type":15},"Quantum Computing","quantum-computing",{"name":2073,"slug":2074,"type":15},"Simulation","simulation","2026-07-14T05:26:58.898253",305,{"items":2078,"total":2229},[2079,2097,2113,2124,2136,2150,2163,2177,2188,2197,2211,2220],{"slug":2080,"name":2080,"fn":2081,"description":2082,"org":2083,"tags":2084,"stars":2094,"repoUrl":2095,"updatedAt":2096},"nemoclaw-user-guide","retrieve NemoClaw documentation and configuration","Guides human users' AI agents to the NemoClaw docs MCP server and canonical Fern documentation in Markdown form. Use when users ask how to install, configure, operate, troubleshoot, secure, or learn NemoClaw with an AI coding assistant. Trigger keywords - nemoclaw docs, use nemoclaw with ai agent, nemoclaw mcp docs, nemoclaw install help, nemoclaw quickstart, nemoclaw markdown docs, llms.txt, agent skills.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2085,2088,2091],{"name":2086,"slug":2087,"type":15},"Documentation","documentation",{"name":2089,"slug":2090,"type":15},"MCP","mcp",{"name":2092,"slug":2093,"type":15},"Search","search",21777,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FNemoClaw","2026-07-20T06:00:01.461044",{"slug":2098,"name":2098,"fn":2099,"description":2100,"org":2101,"tags":2102,"stars":2110,"repoUrl":2111,"updatedAt":2112},"mcore-build-and-dependency","manage Megatron-LM development environments","Container-based dev environment setup and dependency management for Megatron-LM. Covers acquiring and launching the CI container, uv package management, and updating uv.lock.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2103,2106,2107],{"name":2104,"slug":2105,"type":15},"Containers","containers",{"name":1997,"slug":1998,"type":15},{"name":2108,"slug":2109,"type":15},"Python","python",17049,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FMegatron-LM","2026-07-27T06:06:11.249662",{"slug":2114,"name":2114,"fn":2115,"description":2116,"org":2117,"tags":2118,"stars":2110,"repoUrl":2111,"updatedAt":2123},"mcore-bump-base-image","update NVIDIA PyTorch base images","Bump the NVIDIA PyTorch base image (`nvcr.io\u002Fnvidia\u002Fpytorch:YY.MM-py3`) used by Megatron-LM CI. Covers the two pin sites (GitHub CI in `docker\u002F.ngc_version.dev` and GitLab CI in `.gitlab\u002Fstages\u002F01.build.yml`), the post-bump CI loop (re-run functional tests, refresh golden values, mark broken tests), and the gotchas that bit PRs",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2119,2122],{"name":2120,"slug":2121,"type":15},"CI\u002FCD","ci-cd",{"name":1997,"slug":1998,"type":15},"2026-07-14T05:25:59.97109",{"slug":2125,"name":2125,"fn":2126,"description":2127,"org":2128,"tags":2129,"stars":2110,"repoUrl":2111,"updatedAt":2135},"mcore-cicd","manage CI\u002FCD pipelines for Megatron-LM","CI\u002FCD reference for Megatron-LM. Covers CI pipeline structure, PR scope labels, triggering internal GitLab CI (which force-pushes the current branch to a pull-request\u002FBRANCH ref — always dry-run and verify the destination first; never run against shared or protected branches), and CI failure investigation.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2130,2131,2132],{"name":2120,"slug":2121,"type":15},{"name":1997,"slug":1998,"type":15},{"name":2133,"slug":2134,"type":15},"GitHub","github","2026-07-27T06:06:12.278222",{"slug":2137,"name":2137,"fn":2138,"description":2139,"org":2140,"tags":2141,"stars":2110,"repoUrl":2111,"updatedAt":2149},"mcore-create-issue","investigate CI failures and create issues","Investigate a failing GitHub Actions run or job and create a GitHub issue for the failure.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2142,2145,2146],{"name":2143,"slug":2144,"type":15},"Debugging","debugging",{"name":2133,"slug":2134,"type":15},{"name":2147,"slug":2148,"type":15},"Triage","triage","2026-07-14T05:25:57.442089",{"slug":2151,"name":2151,"fn":2152,"description":2153,"org":2154,"tags":2155,"stars":2110,"repoUrl":2111,"updatedAt":2162},"mcore-linting-and-formatting","lint and format Megatron-LM code","Linting and formatting for Megatron-LM. Covers running autoformat.sh, tools (ruff, black, isort, pylint, mypy), and code style rules.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2156,2159],{"name":2157,"slug":2158,"type":15},"Best Practices","best-practices",{"name":2160,"slug":2161,"type":15},"Code Analysis","code-analysis","2026-07-14T05:25:56.18433",{"slug":2164,"name":2164,"fn":2165,"description":2166,"org":2167,"tags":2168,"stars":2110,"repoUrl":2111,"updatedAt":2176},"mcore-migrate-gpt-to-hybrid","migrate Megatron-LM models to HybridModel","Migration guide for moving Megatron Core GPTModel checkpoints, model providers, training commands, and layer mappings to HybridModel.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2169,2172,2175],{"name":2170,"slug":2171,"type":15},"Machine Learning","machine-learning",{"name":2173,"slug":2174,"type":15},"Migration","migration",{"name":9,"slug":8,"type":15},"2026-07-17T06:07:11.777011",{"slug":2178,"name":2178,"fn":2179,"description":2180,"org":2181,"tags":2182,"stars":2110,"repoUrl":2111,"updatedAt":2187},"mcore-onboard-gb200-1node-tests","onboard functional tests for GB200","Onboard 1-node GitHub MR functional tests for GB200 from existing mr-scoped 2-node tests.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2183,2186],{"name":2184,"slug":2185,"type":15},"QA","qa",{"name":2027,"slug":2028,"type":15},"2026-07-14T05:25:53.673039",{"slug":2189,"name":2189,"fn":2190,"description":2191,"org":2192,"tags":2193,"stars":2110,"repoUrl":2111,"updatedAt":2196},"mcore-run-on-slurm","launch distributed training jobs on SLURM","How to launch distributed Megatron-LM training jobs on a SLURM cluster. Covers a minimal sbatch skeleton, environment-variable setup for torch.distributed.run, CUDA_DEVICE_MAX_CONNECTIONS rules across hardware and parallelism modes, container conventions, monitoring, and per-rank failure diagnosis.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2194,2195],{"name":1997,"slug":1998,"type":15},{"name":2000,"slug":2001,"type":15},"2026-07-14T05:25:49.362534",{"slug":2198,"name":2198,"fn":2199,"description":2200,"org":2201,"tags":2202,"stars":2110,"repoUrl":2111,"updatedAt":2210},"mcore-split-pr","split pull requests to reduce review load","Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2203,2206,2207],{"name":2204,"slug":2205,"type":15},"Code Review","code-review",{"name":2133,"slug":2134,"type":15},{"name":2208,"slug":2209,"type":15},"Pull Requests","pull-requests","2026-07-14T05:26:01.226578",{"slug":2212,"name":2212,"fn":2213,"description":2214,"org":2215,"tags":2216,"stars":2110,"repoUrl":2111,"updatedAt":2219},"mcore-testing","run and manage Megatron-LM tests","Test system for Megatron-LM. Covers test layout, recipe YAML structure, adding and running unit and functional tests, golden values, marker filters, and CI parity.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2217,2218],{"name":2184,"slug":2185,"type":15},{"name":2027,"slug":2028,"type":15},"2026-07-14T05:25:54.928983",{"slug":2221,"name":2221,"fn":2222,"description":2223,"org":2224,"tags":2225,"stars":2110,"repoUrl":2111,"updatedAt":2228},"nightly-sync","manage nightly main-to-dev sync workflows","Domain knowledge for the nightly main-to-dev sync workflow. Covers merge strategy, CI architecture, failure investigation, and known issues.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[2226,2227],{"name":2037,"slug":2038,"type":15},{"name":2120,"slug":2121,"type":15},"2026-07-30T05:29:03.275638",496]