Source : ~/.pi/agent/skills/commit-msg/SKILL.md, “Core Contract”.

Le message de commit généré DOIT :

1. Correspondre au style et au format des commits récents de la branche `develop`.
2. Utiliser le passé.
3. Être multiligne.
4. Être basé uniquement sur les changements de fichiers inspectés à partir de l'entrée demandée.
5. Éviter les affirmations qui ne sont pas supportées par les données diff/stat/name-status.
6. Éviter de réutiliser un sujet espace réservé tel que `WIP` à partir du/des commit(s) cible(s).
7. Éviter de muter l'état git ; cette compétence est en lecture seule.

Source : ~/.agents/skills/implementation-steps/SKILL.md, contrat d'ouverture.

Produire un cours d'implémentation pratique pour la cible sélectionnée. Chaque étape numérotée
inclut le code source fonctionnel réel et son propre README détaillé. Un apprenant qui
suit les étapes documentées doit comprendre ce qu'il écrit et pourquoi, et
atteindre exactement le code cible capturé. La correction technique, l'égalité exacte de la source
et l'enseignabilité sont des exigences séparées ; aucune ne se substitue à une autre.

Ce flux de travail est indépendant du langage et du framework. Inspectez la cible plutôt
que d'imposer un runtime, une architecture, un nombre fixe d'étapes ou les choix d'implémentation
d'une tâche précédente. Créez les artefacts d'apprentissage ; laissez la cible inchangée.

Source : ~/.agents/skills/lightpanda/SKILL.md, “CLI and persistent automation”.

Pour une URL autorisée connue, commencez par une extraction bornée :

```zsh
lightpanda fetch --dump markdown --dump-max-bytes 12000 --fail-on-http-error 'http://127.0.0.1:PORT/PATH'
```

Remplacez l'URL par une URL d'application observée. Utilisez `--dump html` pour le balisage ou `--dump semantic_tree_text` pour un arbre sémantique compact. Inspectez le statut de la commande et les erreurs ; un dump seul n'est pas une preuve de navigation ou d'interaction réussie.

Source : ~/.agents/skills/rex/SKILL.md, fichier complet.

---
name: rex
description: Utilisez le CLI rex pour gérer les sessions Rex, ouvrir des onglets, organiser des volets, exécuter des commandes, inspecter la sortie du terminal et contrôler les applications Rex connectées.
metadata:
  rex-stub: "2"
---


Exécutez `rex __internal skill` et suivez le guide qu'il affiche. Le guide provient
du CLI Rex installé, il décrit donc les commandes disponibles dans cette version.

Si la commande échoue, la version Rex installée est antérieure au guide. Commencez par
`rex whoami --json`, puis utilisez `rex --help` et `rex COMMAND --help`.

Source : ~/.agents/skills/ui-sdk/SKILL.md, “Read first”.

La documentation pour la version installée est livrée dans chaque paquet, au format Markdown :

- `node_modules/@ui-sdk//docs/llms.txt` est l'index. Lisez-le en premier. `` est `react`, `vue`, `svelte`, `solid` ou `web`.
- Ensuite, lisez uniquement les pages dont votre tâche a besoin, comme `docs/components/select.md`. Ne lisez pas tout le dossier `docs/` ; il est volumineux.
- Une interface construite à partir de nos composants n'a pas besoin de `docs/core.md`. Seul le chemin 2 ci-dessous en a besoin, et même là, vous le recherchez par titre : il fait plus de 300 Ko. `docs/rendering.md` se trouve à côté dans le même dossier `docs/`.
- Ne lisez pas le JavaScript compilé dans `dist/*.js`, même pour déboguer. La documentation et les types `.d.ts` sont l'API ; quand ils ne répondent pas, écrivez un petit test qui essaie.

Ici, “chemin 2” signifie construire un composant/comportement manquant à partir de @ui-sdk/core, plutôt que de composer des composants existants.

Source : ~/.agents/skills/ui-ux-a11y/SKILL.md, “Scope and authority gate”.

Avant d'éditer ou d'approuver le travail :

1. Identifiez le périmètre d'implémentation autorisé par l'utilisateur, les instructions du dépôt et tout plan ou critère d'acceptation applicable dans le projet actuel.
2. Découvrez et inspectez les sources de vérité réelles du projet actuel : comportement produit existant, référence fournie par l'utilisateur, contrat de design, système de design, source de jetons et comportement déployé lorsque la tâche l'exige. Ne supposez aucun nom de fichier ou chemin.
3. Identifiez chaque ID de règle `UX-*`, `A11Y-*`, `CC-*` et `VAL-*` applicable pour les routes, états, locales, fenêtres d'affichage, thèmes et interactions affectés.
4. Enregistrez la ligne de base faisant autorité requise par `VAL-01` avant l'implémentation. Utilisez une ligne de base de référence uniquement lorsque la tâche ou le projet actuel en définit une.
5. Arrêtez-vous si une source de vérité requise est manquante ou si la conformité nécessiterait une route, fonctionnalité, refonte, flux de travail, dépendance, contenu, permission ou changement de périmètre produit non approuvé.

Son dossier de règles complet ui_ux_a11y/ reste faisant autorité ; cet extrait ne remplace pas ses vérifications d'accessibilité, de contraste et d'expérience rendue.

{
  "subagents": {
    "agentOverrides": {
      "worker": {
        "model": "openai-codex/gpt-6.1-sol",
        "thinking": "medium",
        "inheritProjectContext": true,
        "tools": [
          "read",
          "grep",
          "find",
          "ls",
          "bash",
          "edit",
          "write",
          "contact_supervisor"
        ],
        "systemPrompt": "Vous êtes le travailleur d'implémentation. Implémentez uniquement le travail assigné traçable aux exigences réelles de l'utilisateur. N'étendez jamais le périmètre sans approbation explicite préalable de l'UTILISATEUR. Les recommandations de l'agent ne sont pas une approbation. Le\n coordinateur coordonne, maintient le registre de progression et relaie le code écrit par l'agent ; il ne doit pas écrire ou réviser le code. Appliquez le code fourni par le conseiller uniquement après avoir vérifié son applicabilité aux fichiers actuels et aux exigences\n approuvées. À chaque point de contrôle d'implémentation assigné, rapportez les références d'exigences, les fichiers modifiés, les preuves de validation, le travail restant et les mises à jour du registre nécessaires ; demandez la décision du coordinateur avant de commencer l'unité\n d'implémentation suivante. Utilisez contact_supervisor avec la raison need_decision pour les questions bloquantes et les décisions de point de contrôle, ou progress_update pour les changements matériels nécessitant l'attention du coordinateur. N'envoyez pas de narration de routine ou de messages de complétion en double. Ne prétendez jamais que la validation a réussi sans preuve."
      },
      "reviewer": {
        "model": "openai-codex/gpt-6.1-sol",
        "thinking": "high",
        "inheritProjectContext": true,
        "defaultContext": "fresh",
        "tools": [
          "read",
          "grep",
          "find",
          "ls",
          "contact_supervisor"
        ],
        "systemPrompt": "Vous êtes le relecteur d'implémentation en lecture seule. Révisez le point de contrôle du travailleur assigné par rapport aux exigences réelles de l'utilisateur, à l'implémentation, aux tests et aux preuves de validation. N'éditez pas de fichiers et ne créez pas de patch ou\n de fichiers de rapport. Renvoyez des conclusions exploitables avec les références d'exigences, les emplacements exacts, les preuves et le code de remplacement concret ou les diffs unifiés EN LIGNE lorsque utile. Distinguez les défauts réels des recommandations optionnelles. Ne\n développez pas ou ne redéfinissez pas le périmètre, et ne traitez jamais vos recommandations comme une approbation utilisateur. Rapportez les conclusions bloquantes rapidement via contact_supervisor ; sinon renvoyez une revue finale concise. Évitez les battements de cœur, les conclusions en double et le bavardage de routine. Identifiez les points de contrôle obsolètes et les affirmations de complétion non supportées."
      },
      "oracle": {
        "model": "openai-codex/gpt-6-astra",
        "thinking": "medium",
        "inheritProjectContext": true,
        "defaultContext": "fresh",
        "tools": [
          "read",
          "grep",
          "find",
          "ls",
          "contact_supervisor"
        ],
        "systemPrompt": "Vous êtes un conseiller en lecture seule répondant à la question spécifique assignée par le coordinateur. Contestez les hypothèses non supportées, identifiez les risques architecturaux ou de correction, et distinguez les faits, l'incertitude,\n et les recommandations. Lorsque utile, fournissez du code correctif réel ou des diffs unifiés EN LIGNE. N'éditez pas de fichiers et ne créez pas de patch ou de fichiers de rapport. Préservez les exigences réelles de l'utilisateur ; l'extension de périmètre nécessite une approbation explicite préalable de l'UTILISATEUR. Vous ne pouvez pas accorder cette approbation. Escaladez les décisions manquantes bloquantes via contact_supervisor ; sinon renvoyez votre réponse bornée sans bavardage de progression de routine. N'inventez pas d'exigences supplémentaires et n'initiez pas de travail non lié."
      },
      "scopeCreepPatrol": {
        "model": "openai-codex/gpt-6-astra",
        "thinking": "medium",
        "inheritProjectContext": true,
        "defaultContext": "fresh",
        "tools": [
          "read",
          "grep",
          "find",
          "ls",
          "contact_supervisor"
        ],
        "systemPrompt": "Vous êtes l'auditeur de périmètre et de traçabilité des exigences en lecture seule. Comparez le point de contrôle du travailleur assigné et le registre de progression avec les exigences réelles de l'utilisateur et les approbations explicites préalables de l'utilisateur. Détectez\n l'extension non autorisée, les exigences omises ou altérées, et les suggestions de l'agent présentées à tort comme autorité utilisateur. Vérifiez que le registre inclut les références d'exigences d'implémentation, une colonne littérale 1 à N, le statut et l'origine de l'exigence.\n N'inventez pas la signification de 1 à N. Préservez les statuts exactement : no-started / in-progress / deferred / completed / not-applicable. Distinguez l'exigence utilisateur de l'exigence agent ; une exigence agent n'autorise pas\n l'extension de périmètre. Rapportez les divergences étayées par des preuves rapidement via contact_supervisor. Fournissez du code correctif concret EN LIGNE lorsque utile et dans le périmètre existant. N'éditez jamais de fichiers, ne créez jamais de patch ou de fichiers de rapport, ne redéfinissez jamais\n les exigences, n'accordez jamais d'approbations et ne fabriquez jamais de portes d'acceptation. Évitez le bavardage de routine."
      }
    },
    "watchdog": {
      "enabled": true,
      "scope": {
        "enabled": true
      },
      "clarification": true,
      "main": {
        "model": "openai-codex/gpt-6-astra",
        "thinking": "medium"
      },
      "cadence": {
        "everyNTools": 16
      },
      "children": {
        "enabled": false,
        "overrides": {
          "worker": {
            "enabled": true,
            "model": "openai-codex/gpt-6.1-sol",
            "thinking": "high",
            "cadence": {
              "everyNTools": 8
            }
          }
        }
      }
    }
  }
}

Depuis local-inference/packages/pi-proxy/src/index.ts. Les identifiants et la configuration du fournisseur restent derrière ModelRuntime ; le rafraîchissement et le listing reçoivent le signal d'annulation de la requête.

  static async create(options: PiBackendOptions = {}): Promise<PiBackend> {
    const { provider, ...runtimeOptions } = options;
    return new PiBackend(await ModelRuntime.create(runtimeOptions), provider);
  }

  async models(signal: AbortSignal) {
    await this.runtime.refresh({ providers: this.provider ? [this.provider] : undefined, signal });
    signal.throwIfAborted();
    const available = await this.runtime.getAvailable(this.provider, { signal });
    return available.map(model => ({ id: this.provider ? model.id : `${model.provider}/${model.id}`, owned_by: model.provider }));
  }

Depuis le même fichier. Pi fournit les métadonnées du fournisseur et la résolution de modèle personnalisé ; la couche HTTP conserve l'ID de modèle exact de l'appelant plutôt que d'appliquer les commodités de nom flou ou de suffixe de réflexion du CLI.

  async resolve(id: string, signal: AbortSignal): Promise<InferenceModel> {
    signal.throwIfAborted();
    const slash = id.indexOf("/");
    const provider = this.provider ?? (slash > 0 ? id.slice(0, slash) : undefined);
    const modelId = this.provider ? id : id.slice(slash + 1);
    if (!provider) throw new ApiError(400, "Utilisez provider/model comme ID de modèle, ou commencez par --provider");
    await this.runtime.refresh({ providers: [provider], signal });
    signal.throwIfAborted();
    const selected = resolveCliModel({ cliProvider: provider, cliModel: modelId, modelRuntime: this.runtime });
    if (!selected.model) throw new ApiError(400, selected.error ?? "Pi n'a pas pu résoudre le modèle demandé", "model_resolution_error");
    // Pi possède la construction du modèle, les métadonnées du fournisseur et le support de modèle personnalisé.
    // Son résolveur CLI accepte aussi les noms flous/suffixes de réflexion ; un modèle HTTP
    // est un ID exact, donc ces commodités ne doivent pas réécrire ce champ.
    return { ...selected.model, id: modelId };
  }

Depuis PiBackend.stream dans le même fichier. Les options de raisonnement partagées utilisent streamSimple ; les options natives reasoningEffort utilisent stream.

    const events = request.reasoningEffort === undefined
      ? this.runtime.streamSimple(model, context, request)
      : this.runtime.stream(model, context, request);

Depuis local-inference/packages/server/src/index.ts, à l'intérieur du switch d'événement. Les deltas de texte sont émis dès qu'ils arrivent, sans attendre la complétion du fournisseur.

      case "text_delta": source.push(event.delta); await chunk({ content: event.delta }); break;
      case "thinking_delta": await chunk({ reasoning_content: event.delta }); break;