X bookmarks

Proposal — Installer le skill xurl sur Marco pour étendre l'accès X au-delà des bookmarks. Le tweet annonce un guide officiel xAI pour le skill `xurl` qui permet à un Hermes Agent de lire/écrire sur X en langage naturel (post, search, bookmarks, lists). Concrètement pour Marco : (1) suivre le setup guide pour installer xurl dans `~/.hermes/skills/`, (2) câbler les credentials OAuth déjà présents (`X_USER_ID`, `X_ACCESS_TOKEN` dans `.env.local`) pour que xurl les réutilise au lieu du fetch manuel de `lib/x-bookmarks.ts`, (3) ajouter des capacités côté dashboard : un endpoint `/api/x/search` qui délègue à xurl pour requêter des sujets thématiques (ex: 'next.js 15 server actions'), et un endpoint `/api/x/lists` pour suivre des listes curatées de devs. À terme, remplacer le code custom de `lib/x-bookmarks.ts` (fetch + 429 mapping + pagination) par un appel xurl natural-language — Marco gère le retry et le refresh token via le skill, on supprime la dette OAuth manuelle (regen token à 2h).

Proposal — Ajouter un ERRORS.md par projet vault + injecter la règle dans le prompt Marco. L'article décrit un pattern simple mais absent du setup Marco : maintenir un `ERRORS.md` par projet listant les approches qui ont demandé >2 tentatives (ce qui a foiré / ce qui a marché / note pour la suite). Concrètement : (1) ajouter `marco-vault/projects/<slug>/ERRORS.md` (template court avec sections datées), (2) modifier le prompt système injecté par `~/.hermes/scripts/pipeline.py` au spawn `claude -p --model opus` pour deux instructions — « lis `ERRORS.md` du projet avant de proposer une approche » et « si une approche a demandé >2 tentatives durant cette session, ajoute une entrée à `ERRORS.md` avant de terminer ». (3) Côté marco-dashboard, ajouter un onglet « Erreurs apprises » dans `app/projects/[slug]/page.tsx` qui lit le fichier via un nouveau helper `getErrorsLog(slug)` dans `lib/vault.ts`, rendu à côté de Status/Backlog/Ideas. Ça transforme les ratés en mémoire réutilisable entre features et donne à Paolo une vue rapide des pièges connus par projet.

Proposal — Ajouter canary output + silent-failure alert sur les agents Marco/Hermes. Appliquer la règle 2 de l'article aux runs Marco. Concrètement : (1) Étendre le format de sortie des sessions Hermes pour exiger un bloc canary `{sources_checked, items_processed, last_source_timestamp, confidence}` — ajouter ce champ dans le prompt système Marco et le valider côté pipeline.py avant de marquer un run OK. (2) Dans `lib/pipeline-log.ts`, parser ce canary et exposer un nouveau marker `PHASE_EMPTY` quand `items_processed === 0` OU `last_source_timestamp` > seuil (ex: 8j). (3) Dans `lib/overview.ts`, faire remonter `needsAttention` aussi quand le dernier run a un `PHASE_EMPTY` non-acknowledgé, pas seulement sur stopped/iteration_failed. (4) Ajouter sur `/projects/[slug]` un badge "silent failure suspecté" avec la liste des canaries dégradés des 7 derniers jours. Bonus : un spot-check hebdo affiché sur `/` qui pioche 1 output aléatoire à relire — 4 min/semaine pour catcher le drift avant qu'il devienne panne.

Proposal — Découper la pipeline Marco en pipeline researcher → coder → reviewer. Refacto de `~/.hermes/scripts/pipeline.py` pour remplacer le `claude -p` unique par 3 sessions chaînées, chacune avec un system prompt focalisé et un contrat JSON en sortie. (1) `researcher` : reçoit `feature.md` + slug projet, explore le repo (Grep/Read seuls, pas d'Edit), produit `research-brief.json` (fichiers à toucher, conventions repérées, deps, risques). (2) `coder` : reçoit la feature + le brief, code uniquement (Edit/Write/Bash), produit `coder-report.json` (fichiers modifiés, commandes lancées, tests passés). (3) `reviewer` : lit le diff `git diff main`, lance lint+tests, produit `review.json` avec un score rubric (tests OK, pas de violation CLAUDE.md, pas de secret leaké). Si score < seuil, renvoyer au coder avec les findings. Commencer par juste researcher+coder (pattern Pipeline du post), valider le format des handoffs, ajouter reviewer ensuite. Bonus aligné avec l'article : standardiser les JSON dès le départ pour éviter les handoffs cassés.

Proposal — Ajouter un scheduled task `marco-daily-brief` qui produit un résumé matinal cross-sources. Créer `scripts/daily-brief.ts` (entrée cron à 06:30) qui agrège l'état des sources Marco en un brief markdown déposé dans `~/.hermes/marco-dashboard/briefs/YYYY-MM-DD.md`. Sections suggérées : (1) Pipeline — runs des dernières 24h via `lib/pipeline-log.ts` (groupRunsByProject + filtre RUN_OK/RUN_STOPPED/PHASE_FAIL), (2) Vault — features passées en Under Review ou Done depuis la veille via `lib/vault.ts`, (3) Bookmarks — top 5 nouveaux items du jour par score via `lib/x-bookmarks.ts`, (4) Attention — projets où `needsAttention=true` depuis `lib/overview.ts`. Le script suit le pattern existant de `scripts/sync-bookmarks.ts` (un JSON line stdout, exit codes 0/1/2, 60s timeout via AbortController). Exposer aussi `GET /api/briefs/today` et une page `/briefs` qui liste les fichiers générés, pour que le brief soit consultable depuis le dashboard mobile sans ouvrir le fichier. Cron : `30 6 * * *` dans `~/.hermes/cron/marco-dashboard-brief.cron`.

Proposal — Audit SOUL.md + pin skills critiques + profil dédié pour bookmarks pipeline. Le masterclass Hermes décrit trois leviers immédiats pour Marco. (1) Vérifier que `~/.hermes/SOUL.md` existe et capture l'identité de Marco (ton terse, stack TS/Next.js/Postgres, conventions Paolo, règles readonly) — c'est slot #1 du system prompt, avant tout le reste. Si absent ou générique, le réécrire en s'inspirant du template 'staff engineer' de l'article. (2) Lister les skills custom critiques (auto-propose, wrappers pipeline.py, scoring bookmarks, etc.) et les protéger avec `hermes curator pin <skill>` — sans pin, le Curator archive après 90j d'inactivité, et la communauté rapporte qu'il écrase parfois des customisations par des versions moins bonnes. (3) Créer un profile Hermes dédié via `hermes profile create bookmarks-researcher --clone` pour isoler la pipeline bookmarks→propositions du Marco principal (mémoire + skills + state.db séparés) — ça évite que les 100+ bookmarks polluent la MEMORY.md de Marco. Bonus : si le taux de propositions 'no' devient trop élevé, regarder le repo `NousResearch/hermes-agent-self-evolution` pour optimiser le skill auto-propose offline via GEPA (~$2-10/run, pas de GPU).

Proposal — Vue coût-par-session dans marco-dashboard (tokens × modèle × cache). Le thread chiffre les fuites tokens des agents (auto-context 80% gaspillé, Opus sur tâches Haiku = 30x payé). Pour Marco la plus exploitable est la visibilité. Concrètement dans marco-dashboard : nouveau `lib/cost.ts` + route `GET /api/sessions/[id]/cost` qui lit `messages` de state.db, agrège par modèle les `input_tokens` / `output_tokens` / `cache_read_input_tokens` (déjà dans le JSON `usage` des rows assistant), multiplie par une table de prix hardcodée Opus/Sonnet/Haiku, et renvoie `{totalUsd, byModel, cacheHitPct, topExpensiveToolCalls}`. Affichage : un card en tête de `/sessions/[id]` + colonne `costUsd` dans `/sessions`. Permet d'identifier a posteriori les sessions où Marco aurait dû router sur Haiku (lint/rename/format). Suite logique côté Hermes : règle dans `~/.hermes/scripts/pipeline.py` qui force `--model haiku` quand le titre de phase matche `/^(lint|format|rename|chore)/i`. Test : Vitest sur `computeSessionCost(messages, priceTable)` avec un fixture multi-modèle.

Proposal — Injecter un DESIGN.md de Refero Styles dans le contexte pipeline Marco. Ajouter une étape de bootstrap dans `~/.hermes/scripts/pipeline.py` qui, pour chaque projet front (cave-shopify, miso-landing, marco-dashboard), charge un `DESIGN.md` de référence sélectionné depuis styles.refero.design et le concatène au prompt système de la session `claude -p`. Concrètement : (1) créer `marco-vault/design-refs/<slug>.md` avec le DESIGN.md choisi (ex. xAI Midnight Command Center pour marco-dashboard sombre, un système retail premium pour cave-shopify) ; (2) dans la phase dev du pipeline, si `marco-vault/projects/<slug>/index.md` a `design_ref: <file>` en frontmatter, lire le fichier et l'inclure via `--append-system-prompt` ou équivalent ; (3) documenter la convention dans `marco-vault/CLAUDE.md`. Bénéfice : les sessions dev qui touchent à l'UI auront en contexte des tokens design cohérents (palette, échelles d'espacement, hiérarchie typo) au lieu de réinventer du Tailwind générique.

Proposal — Panneau /insights dans marco-dashboard : coûts par provider + sessions stalled. Construire app/insights/page.tsx + lib/insights.ts qui lit l'équivalent de /insights [days] depuis state.db (messages + tool_calls JSON) et ~/.hermes/sessions/. Trois cards : (1) tokens consommés par projet sur 30j, (2) coût par provider/modèle (jointure messages.model → table de prix locale, calculé côté serveur), (3) sessions stallées (started_at ancien + pas de completion marker depuis >1h). Réutilise le singleton better-sqlite3 readonly de lib/hermes-db.ts. Ajoute route /api/insights/summary?days=30 (clamp [1,90]) renvoyant {byProject, byProvider, stalled}. Bonus config Marco actionnable en parallèle : configurer un auxiliary model Haiku 4.5 pour compression contexte via `hermes model` (gain coût immédiat — l'article rappelle que la plupart payent Opus pour du grunt work).

Proposal — Bot hygiène backlog vault pour Marco, inspiré clawsweeper. Ajouter un module Marco `hermes/scripts/backlog-sweeper.py` qui scanne périodiquement les `features/*.md` de chaque projet vault et propose des fermetures motivées. Patterns à reprendre de clawsweeper : (1) review-only puis apply guardé — écrire un rapport markdown par feature dans `~/.hermes/marco-reviews/<projet>/<feature>.md` avec `{verdict, evidence, snapshot_hash, proposed_status_change}`, et seules les propositions inchangées entre deux passes (snapshot stable) sont appliquées en flippant le frontmatter `status: Done`. (2) Raisons strictement allowlistées : `implemented_on_main` (git log montre commits liés mergés + RUN_OK récents dans pipeline.log via `findRunsForSlug`), `superseded_by:<slug>` (autre feature couvre déjà via depends_on inversé), `stale_no_signal` (>60j sans update + aucun run pipeline). (3) Token flow séparé : le worker Claude n'a aucun accès en écriture vault ; un step déterministe en aval applique le diff frontmatter après re-check du snapshot. (4) Exposer dans marco-dashboard sous `/projects/[slug]` un onglet "Hygiène backlog" listant les propositions en attente avec verdict + bouton accepter/rejeter.

Proposal — Ajouter une skill Marco `weekly-connections` sur `marco-vault/inbox/`. Créer `~/.claude/skills/marco-weekly-connections.md` inspiré de la skill `weekly-connections` de l'article. Trigger : 'run connection session' ou cron hebdo. Process : (1) lister tous les fichiers de `marco-vault/inbox/*.md` modifiés dans les 7 derniers jours via `listInboxIdeasForSlug` étendu sans filtre de slug ; (2) demander à Claude de trouver 3-5 connexions fortes selon les 4 types de l'article (même principe dans deux domaines, contradiction, pattern à 3+ notes, question répondue ailleurs) ; (3) pour chaque connexion, écrire une note dans `marco-vault/connections/YYYY-MM-DD-<slug>.md` avec frontmatter `{type, sources: [...], bridge, hook}` et liens `[[...]]` vers les notes sources. Bonus : ajouter un onglet `/connections` dans le dashboard qui liste ces notes via un nouveau `lib/connections.ts` calqué sur `lib/vault.ts`. Permet à Marco de produire des propositions de features cross-projets plutôt que d'attendre que Paolo voie le lien lui-même.

Proposal — Ajouter un DESIGN.md par projet front + export Tailwind dans la pipeline. Adopter le format `google-labs-code/design.md` pour figer l'identité visuelle des projets et la rendre lisible par Marco. Concrètement : (1) créer `DESIGN.md` à la racine de `cave-shopify` et `miso-landing` (front commerciaux où la cohérence visuelle compte), avec YAML front matter (colors, typography, rounded, spacing, components button-primary etc.) + sections prose Overview/Colors/Typography/Components ; (2) installer `@google/design.md` en devDep et ajouter `npm run design:lint` (script `designmd lint DESIGN.md`) + `npm run design:export` qui pipe `designmd export --format css-tailwind DESIGN.md > app/theme.css` (Tailwind v4) ou `--format json-tailwind` pour v3 ; (3) câbler le lint dans la CI à côté de `npm run lint` — exit code 1 sur broken-ref ou regression ; (4) côté Marco : faire lire le DESIGN.md du projet courant par le dev agent au début de chaque feature front (injection dans le prompt via `npx @google/design.md spec`), pour qu'il génère des composants alignés sans qu'on redécrive la palette à chaque session. Marco-dashboard peut suivre plus tard (interne, moins prioritaire).

Proposal — Cron hebdo qui archive les dossiers memory/ de Marco avec rotation. Marco écrit/met-à-jour seul ses fichiers de mémoire dans `~/.claude/projects/*/memory/` (MEMORY.md + un .md par souvenir). L'article rappelle qu'un agent peut écraser une entrée par erreur et que la version précédente disparaît sans backup. Concrètement : ajouter `scripts/archive-memory.sh` qui `cp -R` chaque dossier `memory/` vers `~/.hermes/memory-archives/YYYY-MM-DD/<project-slug>/`, garde uniquement les 8 dernières archives (`ls -1t ~/.hermes/memory-archives | tail -n +9 | xargs -I{} rm -rf ~/.hermes/memory-archives/{}`), et planifier via `~/.hermes/cron/marco-memory-archive.cron` à `0 4 * * 0` (dimanche 4h). Coût stockage négligeable (chaque dossier fait quelques Mo). Bonus possible côté dashboard : une page `/memory` listant les archives par date avec un bouton 'restore' qui copie un snapshot daté par-dessus le dossier vivant — mais le script + cron seuls couvrent déjà le besoin de récupération.