Outil de rapport de capacités DOCA (doca_caps)

Par où commencer : ceci est une skill d'outil permettant d'invoquer doca_caps, une CLI sans effet de bord. Ouvrez TASKS.md et commencez à ## run pour les invocations documentées, ou ## test quand vous utilisez doca_caps comme test de validité d'installation. Ouvrez CAPABILITIES.md quand la question concerne les familles de capacités que doca_caps rapporte. Si DOCA n'est pas encore installé, orientez d'abord vers doca-setup.

Exemples de questions auxquelles cette skill répond bien

Les CLASSES de questions doca_caps pour lesquelles cette skill est construite, chacune avec un exemple travaillé. La classe est l'élément fondamental ; l'exemple travaillé en est une instance.

• « Quels appareils DOCA cet hôte voit-il ? » — exemple travaillé : « mon BlueField PF est-il visible à DOCA ». Répondu par l'énumération d'appareils dans CAPABILITIES.md ## Capabilities and modes
  • l'invocation --list-devs dans TASKS.md ## run.
• « Quelles bibliothèques DOCA sont disponibles sur ce système d'exploitation ? » — exemple travaillé : « Flow est-il disponible sur mon hôte RHEL ». Répondu par la surface de disponibilité des bibliothèques dans CAPABILITIES.md ## Capabilities and modes
  • l'invocation d'énumération de bibliothèques dans TASKS.md ## run.
• « Cet appareil supporte-t-il la capacité Y de la bibliothèque X ? » — exemple travaillé : « cet appareil supporte-t-il Flow hairpin ? ». Répondu par la matrice de capacités par appareil et par bibliothèque dans CAPABILITIES.md ## Capabilities and modes
  • l'invocation scoped --pci-addr dans TASKS.md ## run.
• « Quels représentateurs sont visibles à DOCA ? » — exemple travaillé : « énumérer les représentateurs VF pour pf0 ». Répondu par l'énumération de représentateurs dans CAPABILITIES.md ## Capabilities and modes
  • l'invocation --list-rep-devs dans TASKS.md ## run.
• « Je veux une capture d'état à joindre à ma session de débogage. » — exemple travaillé : « enregistrer la sortie device + library + capability dans un fichier ». Répondu par le workflow de capture dans TASKS.md ## test et consommé par doca-debug ## test étape 3 (triple en lecture seule) et doca-programming-guide ## debug.
• « doca_caps n'a rien retourné pour la capacité Y — qu'est-ce que cela signifie ? » — exemple travaillé : « sortie vide pour RDMA ». Répondu par les règles d'interprétation de sortie vide dans TASKS.md ## debug + CAPABILITIES.md ## Error taxonomy.

Audience

Cette skill sert les opérateurs externes, développeurs et agents IA qui ont besoin d'un moyen sans effet de bord de demander « qu'est-ce que DOCA voit sur cet hôte ? » avant de faire quoi que ce soit qui change l'état. Concrètement :

• Un développeur externe qui a installé DOCA (ou utilise le conteneur DOCA NGC public selon doca-setup ## no-install) et veut confirmer que l'installation voit le matériel avant d'écrire du code.
• Un opérateur de plateforme déployant un service DOCA qui veut une capture documentée et en lecture seule de quelles bibliothèques DOCA cet hôte supporte réellement et quelles capacités chaque appareil DOCA offre.
• Un agent IA produisant un artefact snapshot de capacités durant les procédures documentées de setup ou de débogage du guide de programmation (c'est listé comme première étape canonique dans doca-setup ## test et doca-programming-guide ## debug).

Ce n'est pas pour les utilisateurs débogant doca_caps lui-même, et pas un substitut au guide live public de l'outil de rapport de capacités.

doca_caps est livré comme un outil (un seul binaire CLI), pas une bibliothèque contre laquelle vous liez. La skill utilise la même forme trois-fichiers kind: tool que le reste du bundle, donc le contrat task-verb de l'agent (configure / build / modify / run / test / debug) est uniforme sur les bibliothèques, services et outils — même quand certains verbes individuels deviennent un stub de routage pour un binaire en lecture seule livré.

Quand charger cette skill

Chargez cette skill quand l'utilisateur est — ou l'agent doit — invoquer doca_caps sur un hôte réel avec DOCA installé (ou dans le conteneur DOCA NGC public). Concrètement :

• Exécuter doca_caps --list-devs pour énumérer les appareils DOCA.
• Exécuter doca_caps --list-rep-devs pour énumérer les appareils représentateurs.
• Scoper la sortie à une adresse PCIe spécifique avec --pci-addr.
• Énumérer les bibliothèques DOCA que l'installation rapporte comme disponibles sur le système d'exploitation actuel.
• Énumérer les noms de logger DOCA disponibles.
• Capturer une snapshot de capacités documentée et sans effet de bord comme preuve préalable requise pour les workflow ## debug ultérieurs.

Ne chargez pas cette skill pour l'orientation générale DOCA, les travaux API de bibliothèque ou l'installation. Pour cela, utilisez doca-public-knowledge-map, la skill libs/<library> correspondante, ou doca-setup.

Ce que cette skill fournit

Ceci est un chargeur léger. Le matériel substantif vit dans deux fichiers compagnons :

• CAPABILITIES.md — ce que doca_caps rapporte (les cinq familles de capacités documentées : appareils, représentateurs, bibliothèques, capacités de bibliothèque, loggers), disponibilité des versions et environnement d'exécution, surface d'erreur étroite de l'outil, son rôle d'observabilité dans les workflows d'autres skills, et sa posture de sécurité en lecture seule.
• TASKS.md — workflows étape par étape pour les verbes de tâche in-scope : configure (routage vers install), build (routage vers install), modify (refuser), run (les invocations documentées), test (snapshot de capacités comme test de validité d'install), debug (que faire quand l'outil ne rapporte rien ou échoue), plus un bloc Deferred task verbs routant les questions hors-scope.

La skill suppose un hôte où DOCA est déjà installé (ou le conteneur DOCA NGC public est en cours d'exécution) et l'opérateur a les permissions que le guide public requiert pour que doca_caps énumère les appareils sur sa plateforme.

Ce que cette skill ne livre délibérément pas

Cette skill est une guidance d'agent, pas un bundle de samples ou de scripts. Pour garder la limite claire, elle ne contient délibérément pas — et les pull requests ne doivent pas ajouter :

• Sortie d'exemple pré-cuite. La sortie est spécifique à l'installation et au matériel. Un exemple capturé épinglé à une plateforme et une version DOCA égarent les opérateurs sur une plateforme / version différente.
• Wrappers, parseurs ou scripts dans n'importe quel langage qui consomment la sortie doca_caps. Le format de sortie est documenté ; si un utilisateur veut scripter contre, la bonne réponse est « lisez le guide live, écrivez le parseur contre votre version installée ».
• Un sous-arbre samples/ ou reference/. C'est un chargeur léger pour une CLI documentée ; le matériel substantif vit sur la page publique et dans --help.

Ordre de chargement

1. Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est in-scope (l'utilisateur veut réellement invoquer doca_caps, pas apprendre DOCA en général).
2. Pour ce que doca_caps rapporte, la disponibilité des versions, la surface d'erreur et la posture de sécurité, voir CAPABILITIES.md.
3. Pour les invocations documentées et le workflow de snapshot de capacités — configure, build, modify, run, test, debug — voir TASKS.md.

Skills connexes

• doca-public-knowledge-map — routage vers le guide live de l'outil de rapport de capacités et le reste de l'ensemble de documentation DOCA public.
• doca-setup — préparation d'env, vérification d'install (doca_caps est l'étape canonique première là), et le chemin je n'ai pas encore d'install avec le conteneur DOCA NGC public.
• doca-programming-guide — patterns de programmation cross-library, incluant la procédure ## debug où la snapshot doca_caps sauvegardée est consommée.
• La skill libs/<library> correspondante — pour les questions de capacité fine-grained spécifiques à la bibliothèque qui vont au-delà de ce que doca_caps expose.