Commencer par une procédure contextuelle

Un package peut contenir une checklist, des références, des exemples ou des modèles de document, sans agent ni code exécutable. Il utilise le même touba.package.json qu'un package de code.

La distinction utile porte sur le contenu :

• une procédure contextuelle guide le modèle ;
• une skill Touba est une capacité exécutable typée ;
• un tool représente une opération hôte ;
• un agent agit sous sa responsabilité et ses autorisations déclarées.

Créer le contexte

Terminal

touba package new acme.review --context --yes
touba package check review

Le dossier auteur review/ contient touba.package.json, SKILL.md, README.md, .gitignore et packages/ pour ses dépendances. Aucune empreinte à maintenir à la main. L'entrée contexts du manifeste déclare la procédure, les ressources et les règles d'activation.

Pour installer ce dossier dans un projet Touba, utilisez touba package add ./review. Préparez-le d'abord si vous voulez encore modifier ses fichiers ; un contenu installé est verrouillé.

Sans tests déclarés, touba package test review retourne no_tests, pas une réussite. Ajoutez des tests Node de vos critères métier avant de revendiquer une validation.

Découvrir puis activer

Ajoutez à la commande de votre programme :

Options de run

--skill-pack packages/acme.review#review
--activate-skill-pack skill_pack:acme.review/review
--skill-pack-discovery-max-bytes 4096
--skill-pack-activation-max-bytes 16384
--agent-model-input-max-bytes 65536

La première option rend le contexte disponible. Sans activation, le provider reçoit seulement des indications courtes. L'activation charge la procédure et les ressources autorisées avec leur provenance. Les options sont répétables. Si un package contient plusieurs contextes, #<id> choisit celui à fournir.

Les budgets sont explicites. Un dépassement refuse l'appel ; Touba ne tronque pas silencieusement la procédure. user_invocable: false interdit l'activation demandée par l'utilisateur.

Configurer la CLI et le serveur

Dans touba.project.json, la même sélection s'applique à run --project et à serve, y compris aux reprises :

Dans configuration

{
  "contexts": [
    { "package": "acme.review", "context": "review", "active": true }
  ]
}

Omettez active ou mettez-le à false pour la découverte seule. Les packages doivent avoir été installés avec package add. Une copie externe de même identité ne remplace pas le contenu verrouillé. Une sélection explicite hors projet porte la provenance author, et non project.

model_invocable gouverne une activation demandée par le provider ; user_invocable gouverne l'activation explicite de l'hôte. Ces indicateurs ne rendent jamais une ressource exécutable et ne modifient pas uses.

Ressources et scripts

Un fichier script est inventorié mais son contenu n'est pas injecté dans l'entrée modèle. Il ne s'exécute jamais par activation. Pour l'utiliser, un handler doit le charger explicitement derrière un tool gouverné.

Les execution_links désignent des tools ou skills déjà présents dans l'AIR. Le chargement vérifie leur existence ; le runtime vérifie également le uses de l'agent. Le contexte n'accorde ni grant, ni secret, ni caller.

Les traces distinguent découverte, activation, chargement et refus. L'exclusion normale d'un script produit skill_pack_resource_refused avec reason: script_content_not_loaded, sans code d'erreur runtime. Une tentative d'exécution par le contexte reste refusée.

Le contrôle de contenu sensible reconnaît les valeurs de secrets résolues pour le run. Il ne détecte pas universellement toutes les clés API possibles. Ne placez aucun secret dans les procédures ou ressources distribuées. Le protocole interne conserve les noms skill_pack_* pour ces événements ; ce ne sont pas des formats de distribution supplémentaires.

Voir le tutoriel contexte, script et tool et le guide des packages.