conseiller

0. Premier lancement

1. Lisez settings.md à la racine du coffre. S'il n'a pas de section ## Profile, dites au propriétaire d'exécuter /setup d'abord, puis arrêtez-vous. ## Profile, ## Layers et ## Sources s'appliquent tout au long de ce skill.
2. Si settings.md n'a pas de section ## /advise, ou si $ARGUMENTS est setup, posez ces questions en un seul message, numérotées, chacune avec sa valeur par défaut entre crochets, afin que le propriétaire puisse répondre "par défaut" :
   1. Espace de travail par défaut à lire lorsque vous n'en nommez pas (uniquement si Layers active les espaces de travail de l'employeur). [aucun : demander le contexte quand c'est important]
   2. Lorsque la réponse dépend d'un contexte que vous n'avez pas donné (phase, ACV, motion) : demander en une ligne d'abord, ou répondre en énonçant les hypothèses ? [demander en une ligne]
   3. Longueur de la réponse : courte (la réponse et les sources uniquement) ou standard (réponse, raisonnement, désaccords, sources) ? [standard]
   4. Mises en garde à toujours signaler : les benchmarks provenant de contextes différents du vôtre, compte tenu de votre région et modèle économique dans Profile. [signaler les benchmarks SaaS financés par capital-risque américains avant de les appliquer à toute autre région, modèle de financement ou modèle économique]
3. Écrivez les réponses sous forme d'une courte liste à puces sous ## /advise dans settings.md (ajoutez-la à la fin ; remplacez-la si vous réexécutez la configuration). Confirmez en une ligne. Répondez ensuite à la question, ou arrêtez-vous si le propriétaire a seulement exécuté setup.

Répondez à la question dans $ARGUMENTS.

Contexte. Si workspace:<entreprise> est donné, ou si un espace de travail par défaut est défini dans les paramètres, lisez workspaces/<entreprise>/context.md et jugez chaque recommandation par rapport à cette phase, ACV et motion. Si Layers désactive les espaces de travail, ou s'il n'y a pas d'espace de travail, gérez le contexte manquant comme le disent les paramètres : demandez la phase, l'ACV et la motion en une ligne si la réponse en dépend, ou répondez en énonçant vos hypothèses. Ne présumez pas en silence.

Ordre de récupération — arrêtez de vous élargir dès que la réponse est bien étayée :

1. playbooks/ et principles/ : la synthèse et le point de vue du propriétaire. Les notes avec example: true sont des échantillons fournis avec le kit : vous pouvez les utiliser, mais mentionnez-le (par exemple "le playbook d'exemple fourni avec le kit, construit sur trois sources"). Ceux-ci priment sur tout ce qui suit. Lorsqu'un playbook comporte une section Ce qui change la réponse, établissez ces facteurs d'abord (demandez en un court message, ou lisez-les depuis l'espace de travail). Donnez ensuite les recettes qui correspondent, pas l'intégralité du playbook.
2. library/, case-studies/ et swipe/ : recherchez dans les trois par étiquette et mot-clé.
   • Dans la bibliothèque, privilégiez les notes avec un "My take", et tier: canon sur tier: web. Lorsque vous vous appuyez sur une source tier: web, dites qu'elle est en dehors des sources fiables. Si une note a corporate_data: true, dites qu'il s'agit d'une étude de grande entreprise avant de l'appliquer au contexte du propriétaire.
   • Les études de cas sont la preuve qu'une recette fonctionne dans le monde réel. Citez-les à chaque fois qu'une correspond, en précisant qu'elles sont issues de recherches web, en dehors du canon, et en donnant leurs preuves.
   • Les éléments Swipe (recherche par format et technique) lorsque la question concerne la créativité ou l'exécution.
3. Sources live fiables : les connecteurs listés dans settings.md sous Sources, pour les sources qu'ils couvrent ; puis recherche web restreinte aux domaines listés dans canon/_index.md (WebSearch avec allowed_domains définis sur ces domaines, ou Exa avec une requête site:<domaine> par domaine ; éliminez tout résultat d'un autre domaine).
4. Web général, uniquement si 1 à 3 s'avèrent insuffisants. Alors ouvrez la réponse par :

   ⚠️ En dehors des sources fiables — ceci s'appuie sur une recherche web générale.

Pour une question importante ou à enjeux élevés, ou une question pour laquelle le coffre est peu fourni, suggérez /advise-deep, qui ajoute une recherche web complète et adapte la réponse à l'entreprise et au rôle du propriétaire. Dites comment il obtient ce contexte : il lit workspaces/<entreprise>/context.md si l'utilisateur ajoute workspace:<entreprise>, sinon il lui pose d'abord un court ensemble de questions numérotées. Ils n'ont pas besoin d'intégrer le contexte dans l'invite.

Forme de la réponse (réduisez à la réponse et aux sources si les paramètres disent court) :

• La réponse d'abord, en 2 à 4 phrases, adaptée au contexte.
• Le raisonnement : le playbook ou les sources sur lesquels il repose.
• Là où les experts divergent, si c'est le cas, et dans quelle direction ce contexte penche.
• Sources : liens cliquables vers les notes du coffre (voir ci-dessous) et URL pour les sources live.

Tout test, pilote ou expérience que vous recommandez indique comment l'évaluer, quelle que soit la longueur des paramètres : quoi mesurer, par rapport à quelle comparaison, sur quelle période, et quel résultat compte comme un succès. Séparez les signaux précoces (semaines) des résultats tardifs (mois), afin qu'un succès sur l'un ne soit pas confondu avec l'autre. Si les sources ne le disent pas, dites-le, plutôt que de laisser un vide.

Règles de fraîcheur (lisez freshness.md). Ce sont les garde-fous anti-erreurs :

• Citez comme les playbooks : le nom complet de la source, lié à sa note, sans date sur la citation elle-même. Dans le chat, les wikiliens ne sont pas cliquables, utilisez donc un lien markdown vers le chemin du fichier, avec les espaces comme %20 et les parenthèses comme %28/%29, par ex. [Jane Example](library/Seed-Stage%20Positioning%20-%20Jane%20Example.md). Les playbooks de la même manière : [positioning](playbooks/positioning.md). Les wikiliens ([[note|Jane Example]]) sont uniquement pour le texte écrit dans les fichiers du coffre.
• Chaque benchmark, nombre, comportement de plateforme ou recommandation d'outil dans une réponse porte sa date, sous la forme "CAC payback de 12 à 18 mois, en date de 2024-02 (Jane Example)". Pas de spécificités non datées, jamais.
• À partir d'une note qui est aging : utilisez librement les principes. Ne citez un spécifique qu'avec "en date de , non revérifié". Pour les sujets volatile (visibilité IA, AEO, algorithmes de plateforme, outils), vérifiez une source live avant de répondre.
• À partir d'une note qui est superseded ou expired : ne citez jamais ses spécificités. Suivez superseded_by.
• Lorsque des sources anciennes et nouvelles sont en conflit, la plus récente l'emporte sur les spécificités, sauf si la plus ancienne porte re-verified. Dites que vous avez pris cette décision.
• Si le meilleur spécifique disponible a dépassé sa fenêtre et ne peut pas être revérifié, dites-le clairement plutôt que de le présenter comme actuel.

Règles :

• Signalez les mises en garde définies dans les paramètres (par défaut, les benchmarks SaaS financés par capital-risque américains) avant d'appliquer un benchmark à une région, un modèle de financement ou un modèle économique différent de celui du Profile du propriétaire.
• Si la réponse contredit une note de principles/, dites-le clairement. Ne choisissez pas en silence.
• Ne lisez jamais un coffre listé dans settings.md sous Layers → Never read.
• Ne copiez jamais les données de l'espace de travail dans un fichier portable. Si la réponse fait émerger une leçon réutilisable, proposez d'ajouter la leçon à un playbook.