Pack de rapports

Chainez deux skills pour que les chiffres récurrents du propriétaire arrivent tout seuls, avec assez de contexte pour agir : report-builder pour le pack lui-même, business-pulse pour le tableau complet.

Les propriétaires ont déjà le rapport qu'ils veulent en tête. Ce qu'ils n'ont pas, c'est qu'il arrive lundi sans qu'ils le demandent. C'est tout le travail ici.

Étape 1 — Le pack de rapports (report-builder)

Invoquez report-builder. Il gère la spec, l'extraction des données, les calculs et le classeur — ne reconstruisez rien de cela ici.

• Entre : la description du pack par le propriétaire, ou le nom d'un pack enregistré.
• Sort : un résumé de chat, un classeur XLSX, et une définition enregistrée.

report-builder vérifie d'abord ses définitions enregistrées. Si le pack existe déjà, il réexécute sans re-demander au propriétaire. Sinon, il construit la spec et la confirme une fois.

Validation — confirmation de la spec. Un pack tout neuf demande une confirmation du propriétaire avant de s'exécuter. Un pack qui a déjà une définition enregistrée n'en demande pas. Re-demander à quelqu'un de décrire un rapport qu'il a défini le mois dernier, c'est le moyen le plus rapide de faire sentir cette commande cassée.

Étape 2 — Le snapshot de contexte (business-pulse)

Après l'exécution du pack, invoquez business-pulse pour la même période.

• Entre : la période couverte par le pack.
• Sort : trésorerie, tendance des ventes, pipeline, liste de suivi, et l'une chose qui nécessite attention.

Le pulse est du contexte, pas un deuxième rapport. Il répond à la question que le pack pose toujours : les chiffres ont bougé, mais l'entreprise va-t-elle bien ?

Pas de validation ici. Les deux étapes sont en lecture seule. Rien n'est envoyé, affiché ou écrit dans un registre, donc il n'y a rien à approuver pour le propriétaire entre elles.

Étape 3 — Livrer comme une seule chose

Un message, dans cet ordre : le résumé du pack, puis le pulse en deux ou trois lignes, puis le classeur.

Ray Okonkwo chez Okonkwo Mechanical reçoit son pack du lundi — revenus par équipe par rapport à l'année dernière, vieillissement des AR, main-d'œuvre en pourcentage du revenu — et dessous : trésorerie à 61 400 USD, deux factures en souffrance depuis plus de 60 jours, un van toujours en panne. Il lit les deux en quatre-vingt-dix secondes et sait ce que lundi est.

N'envoyez jamais deux livrables séparés. Un pack et un pulse arrivant séparément, c'est deux choses à lire ; ensemble, c'est une seule réunion d'information.

Rendez cette réunion d'information comme un seul artifact HTML en utilisant le style d'artifact maison (../../shared/artifact-style.md) — additif au résumé de chat et au classeur, jamais un remplacement. Les métriques principales du pack sont des tuiles stat avec leurs comparaisons comme lignes de contexte ; les lignes de rapport groupées sont un tableau avec tabular-nums ; le contexte du pulse s'assoit dans son propre panneau en dessous, ses éléments de liste de suivi portant des badges de statut (avertissement ou critique) ; sources nommées en une ligne de pied discrète.

Étape 4 — Définir la cadence, une fois

Proposez le calendrier une seule fois, après une exécution que le propriétaire a trouvée utile. Pas avant — une cadence proposée sur un pack que personne n'a encore vu, c'est une présentation d'abonnement.

Demandez-le clairement : « Vous le voulez tous les lundis matin ? » Sur un oui, enregistrez la cadence avec la définition du rapport dans report-builder et confirmez en une ligne : « Enregistré. Cela s'exécute tous les lundis matin. »

Puis tenez votre promesse. Chaque exécution programmée répète les étapes 1 à 3 sans questions, sans re-confirmation, et sans proposition de cadence. Un rapport programmé qui pose une question au propriétaire a cessé d'être programmé.

Sur un non, ou sur le silence, laissez tomber et ne demandez plus jamais.

Sur une exécution interactive uniquement — jamais une programmée — terminez par une ligne sur ce qui a été livré, puis l'étape suivante la plus pertinente et au maximum deux autres à proximité :

• Si le pack a soulevé une question de trésorerie : « cash forecast » exécute cash-flow-snapshot.
• Si le pulse a signalé des AR en souffrance : « who owes me money » exécute invoice-chase.
• Pour modifier ce que le pack suit : « build me a report » exécute report-builder.

Maximum trois propositions. Ne répétez jamais une proposition que le propriétaire a déclinée cette session.

Étape 5 — Gérer une exécution maigre sans l'arrêter

Une exécution programmée se fait que chaque connecteur soit sain ou non. Si une source est en panne, report-builder marque cette métrique « n/a » et nomme la source ; le pack est toujours livré.

Ne sautez jamais une livraison programmée parce que les données étaient incomplètes. Un pack avec un gap et une note est utile. Un lundi silencieux se lit comme si le plugin était cassé, et le propriétaire arrête de l'attendre.

Si le propriétaire n'a aucun connecteur du tout, le chemin CSV est le pack. Demandez une fois l'export, exécutez le rapport identique depuis le fichier, et conservez la cadence.

Ce qu'il ne faut pas faire

• Ne re-demandez pas au propriétaire à propos d'un pack enregistré. Vérifiez d'abord la définition enregistrée, à chaque exécution.
• Ne reconstruisez pas la logique du rapport ici. report-builder gère la spec, les calculs et le classeur.
• Ne recalculez pas les nombres du pulse. business-pulse les gère, pour qu'il y ait un seul ensemble de chiffres.
• Ne proposez pas la cadence deux fois. Une fois, après une exécution utile, puis plus jamais.
• Ne demandez rien sur une exécution programmée. Programmé veut dire que cela arrive sans le propriétaire dans la boucle.
• Ne sautez pas une exécution parce qu'un connecteur a échoué. Livrez-le avec le gap nommé.
• Ne livrez pas le pack et le pulse comme deux messages. Une réunion d'information, une lecture.

Utiliser un outil qui n'est pas listé

Les connecteurs nommés dans ce skill sont les chemins testés, pas un mur. Si le propriétaire veut que ce flux utilise un outil qui n'est pas connecté ou listé, proposez build-connector — il vérifie d'abord le répertoire de connecteurs et se connecte via Zapier sinon, jamais en construisant à la main contre une API brute. Une fois la connexion en place, l'outil rejoint ce skill comme tout autre connecteur optionnel, sous les mêmes portes d'approbation.