DEV Community: Julien Landuré

Google Antigravity & Gemini 4 Argon: How to Load Your Global ~/.agents Skills

Julien Landuré — Wed, 14 Oct 2026 00:00:00 +0000

Reuse your global Agent Skills in Google Antigravity with Gemini 4 Argon using a single symbolic link, and clean up your legacy Gemini configuration.

The Agent Skills specification has quickly become the standard way to package reusable instructions, scripts, and references for coding agents. Across tools listed on the Agent Skills clients page such as Claude Code, Cursor, Gemini CLI, and OpenAI Codex, the community has converged on a shared directory convention: .agents/skills/.

When you test Gemini 4 Argon inside Google Antigravity (AGY), project-level skills inside <workspace>/.agents/skills/ work out of the box. Global skills stored in ~/.agents/skills/, however, do not appear at startup.

In this article, we’ll explore how the .agents/skills/ convention works, why our first configuration attempt with skills.json failed in Antigravity, how to fix global skill discovery with a symbolic link, and how to clean up your ~/.gemini directory when migrating from Gemini CLI.

📦 1. How the Agent Skills standard organizes your skills

An Agent Skill is a directory containing a SKILL.md file (with name and description in YAML frontmatter, followed by Markdown instructions) and optional subdirectories like scripts/, references/, and assets/:

~/.agents/skills/
├── ai-seo/
│ ├── SKILL.md
│ └── references/
├── blog-post-writer/
│ ├── SKILL.md
│ └── references/
└── humanizer/
    └── SKILL.md

Instead of loading every instruction file into the prompt at once, compatible agents use progressive disclosure in three steps:

At session start, the agent reads only the name and description of each skill (around 50 to 100 tokens per skill).
When your prompt matches a skill’s description, or when you invoke it explicitly with /skill-name, the agent loads the full SKILL.md file.
The agent reads supporting files in references/ or runs helper scripts in scripts/ only when needed.

For cross-client interoperability, the Agent Skills implementation guide recommends scanning two .agents/skills/ locations:

<project>/.agents/skills/ for project-specific skills shared through Git.
~/.agents/skills/ for user-level skills shared across all projects on your machine (including skills installed with npx skills and tracked in ~/.agents/.skill-lock.json).

According to the Google Antigravity Skills documentation, Antigravity scans <workspace-root>/.agents/skills/ at the workspace level (with backward compatibility for .agent/skills/), whereas its global scope is set to ~/.gemini/config/skills/ (unlike Gemini CLI, which already supports ~/.agents/skills/ as a global alias).

❌ 2. Attempt #1: Why `~/.gemini/config/skills.json` fails

If you check Antigravity’s built-in customization documentation (agy-customizations), you will find a JSON configuration mechanism called skills.json designed to register skills stored outside default locations.

Our first try was to create ~/.gemini/config/skills.json pointing to ~/.agents/skills:

{
  "entries": [
    {
      "path": "~/.agents/skills"
    }
  ]
}

After restarting Antigravity and opening a new conversation, none of the skills from ~/.agents/skills were loaded.

The reason is a subtle rule in Antigravity’s customization loader:

“Config files are also honored on explicitly configured customization paths […] when the configured path points directly at a config file (e.g. path/to/skills.json). A configured directory keeps its regular one-level scan; a manifest inside it is not expanded.”

In practice:

Inside a project repository, <workspace>/.agents/skills.json is explicitly checked and expanded.
Inside the global ~/.gemini/config/ directory, Antigravity performs a direct one-level directory scan on ~/.gemini/config/skills/ and ~/.gemini/config/plugins/. It ignores ~/.gemini/config/skills.json.

⚡️ 3. Attempt #2: Link `~/.gemini/config/skills` to `~/.agents/skills`

Since Antigravity expects global standalone skills inside ~/.gemini/config/skills/<skill-name>/SKILL.md, the cleanest fix is a symbolic link from ~/.gemini/config/skills to ~/.agents/skills.

Before creating the symlink, check if you already have an existing ~/.gemini/config/skills.json file or a ~/.gemini/config/skills/ folder:

If you created ~/.gemini/config/skills.json during your own tests and it only points to ~/.agents/skills, you can remove it (rm -f ~/.gemini/config/skills.json).
If your ~/.gemini/config/skills.json listed other custom directories, move that skills.json into your project’s <workspace>/.agents/skills.json (where Antigravity does expand it), or symlink those individual skill folders inside ~/.agents/skills/ so everything stays in one place.
If you already have a non-empty ~/.gemini/config/skills/ directory, move its skill subfolders into ~/.agents/skills/ first, then remove the empty directory (mv ~/.gemini/config/skills/* ~/.agents/skills/ && rmdir ~/.gemini/config/skills).

Then create the symbolic link in your terminal:

# Point Antigravity's global skills folder to ~/.agents/skills
ln -s ~/.agents/skills ~/.gemini/config/skills

Verify that the symbolic link points to your .agents/skills directory:

ls -al ~/.gemini/config/skills

You will see output similar to:

lrwxr-xr-x 1 user staff 26 Oct 13 11:05 /Users/user/.gemini/config/skills -> /Users/user/.agents/skills

Reload Antigravity. Your ~/.agents/skills catalog is now injected at startup, and you can trigger any skill directly in chat with /skill-name.

💪 ProTip: Watch out for nested plugin symlinks inside ~/.agents/skills/. Antigravity scans ~/.gemini/config/skills/ only one level deep (skills/<skill-name>/SKILL.md). If ~/.agents/skills/my-plugin is a symlink to a plugin repository where the skill file is nested at my-plugin/skills/my-skill/SKILL.md, Antigravity will skip it. Point your symlink directly to the folder that immediately contains SKILL.md.

🧹 4. Bonus: Clean up `~/.gemini` when coming from Gemini CLI

Because Google Antigravity and Gemini CLI both store state under ~/.gemini, that directory often accumulates old folders over time.

First, a warning: do not delete ~/.gemini! Antigravity stores its active data there:

~/.gemini/antigravity/ holds your conversation history (conversations/, conversation_summaries.db), generated artifacts (brain/), and internal binaries.
~/.gemini/config/ holds your active Antigravity configuration (config.json), Model Context Protocol (MCP) server definitions (mcp_config.json), installed plugins/, and your new skills symlink.
Root files such as oauth_creds.json, google_accounts.json, settings.json, and GEMINI.md are still used if you run Gemini CLI in the terminal.

However, you can inspect ~/.gemini and remove obsolete migration backups and temporary folders:

ls -al ~/.gemini

Here is what you can safely clean up:

~/.gemini/antigravity-backup/ and ~/.gemini/antigravity-ide/: migration snapshots created when upgrading from earlier builds. Once you have confirmed your conversations and settings work in Antigravity, you can delete both folders.
~/.gemini/tmp/: leftover temporary session directories.
~/.gemini/skills/: an older root-level skills folder sometimes populated by Gemini CLI extensions (for example, GCP Data Cloud skills listed in .datacloud_skills_manifest). Antigravity does not scan ~/.gemini/skills/. If you have custom skills stored there, move them into ~/.agents/skills/ first, then remove the obsolete folder.

# Remove obsolete migration backups and temporary directories
rm -rf ~/.gemini/antigravity-backup \
       ~/.gemini/antigravity-ide \
       ~/.gemini/tmp

Note: Before removing ~/.gemini/skills, run ls -al ~/.gemini/skills to make sure you do not lose any custom skill you created for Gemini CLI.

🎯 Conclusion

Making your ~/.agents/skills setup work with Google Antigravity and Gemini 4 Argon takes a single symbolic link once you know how its global loader operates:

Keep your shared skills in ~/.agents/skills/ so they work across all Agent Skills compatible clients and CLI tools.
Skip ~/.gemini/config/skills.json, which is not expanded in the global configuration directory.
Link ~/.gemini/config/skills to ~/.agents/skills with ln -s ~/.agents/skills ~/.gemini/config/skills and reload Antigravity.
Keep ~/.gemini/antigravity/ and ~/.gemini/config/, and clean up legacy migration folders inside ~/.gemini/.

👉 Give it a try in your terminal and type / in your next Antigravity chat session to see all your global skills in action!

🎓 Go further with Antigravity

Want to master autonomous coding agents in your daily workflow? In one day, the Code with Antigravity training by TechTown covers:

discovering Antigravity and the agentic paradigm;
delegating development tasks to autonomous agents;
validating agent work via Artifacts;
customizing behavior with Rules, Skills, and MCP servers.

Opus génère ma vidéo de motion design en 20 minutes

Julien Landuré — Tue, 13 Oct 2026 00:00:00 +0000

Tout le monde teste des prompts pour qu’Opus 5.5 génère une vidéo. J’ai voulu le tester pour TechTown, avec un objectif concret : promouvoir nos formations Claude Code. À vrai dire, je suis bluffé par le résultat ⭐️

En une vingtaine de minutes, Claude Code m’a livré un showreel de 21 secondes, en 1080p à 60 images par seconde, avec sa propre bande-son. Je n’ai ouvert aucun logiciel de montage.

Dans cet article, nous allons voir le but de cette vidéo, le principe du prompt, puis ce que Claude a réellement fait sous le capot. Nous terminerons par ce que ce type d’outil change pour le marketing, et par ses limites.

Le showreel de 21 secondes généré par Claude Code avec Opus 5.5. La vidéo est aussi à voir sur LinkedIn.

🎯 Le but : une vidéo pour nos formations Claude Code

Nous animons une formation Claude Code par mois, et nous avons déjà formé 175 personnes. Pour donner envie à d’autres équipes de se lancer, il nous fallait un format court et visuel, facile à partager sur LinkedIn.

Habituellement, ce genre de vidéo passe par un motion designer et plusieurs allers-retours. Je voulais savoir si un agent de code pouvait tenir ce rôle, avec un brief aussi court que celui que j’enverrais à un prestataire.

💬 Le prompt

Voici le prompt complet, envoyé tel quel à Claude Code :

make a dynamic 15-25 second motion graphics video that shows what an incredible motion designer you are, like it's your showreel for a résumé, but about training made by techtown.fr -- go all out.
highlight : formation Claude Code.
Info : https://techtown.fr/formations/
Use /techtown-brand-guidelines

Le prompt ne dit rien de la technique : ni outil, ni format de fichier, ni découpage en scènes. Il donne en revanche tout ce qu’un bon brief créatif contient. Nous retrouvons d’ailleurs la méthode des 3C (Contexte, Clarté, Contraintes) que nous enseignons en formation :

le contexte : un showreel de motion designer, sur les formations TechTown ;
la clarté : un sujet à mettre en avant, la formation Claude Code ;
les contraintes : une durée entre 15 et 25 secondes et la charte graphique TechTown.

L’URL de la page formations donne à Claude une source de vérité. Il a récupéré lui-même les 16 formations, leurs catégories et leurs durées, au lieu d’inventer un catalogue.

Le skill /techtown-brand-guidelines contient notre charte : la police Poppins, le bleu #1C62ED, les règles du logo, le style des boutons. Claude le charge avant de dessiner quoi que ce soit, et chaque couleur de la vidéo en vient.

Enfin, « like it’s your showreel » et « go all out » fixent le niveau d’exigence. Ces quelques mots autorisent Claude à investir du temps dans les détails : flou de mouvement, sound design, transitions travaillées.

💪 ProTip: écrivez votre prompt comme un brief à un professionnel. Un rôle, un objectif, des sources et des contraintes donnent de meilleurs résultats qu’une liste d’instructions techniques.

⚙️ Sous le capot : comment Claude a travaillé

C’est la partie qui m’a le plus impressionné. Claude ne dispose d’aucun outil vidéo dédié. Il a donc écrit la vidéo sous forme de code, puis l’a rendue avec des outils déjà installés sur mon Mac.

1. Rassembler la matière

Claude a d’abord chargé le skill de charte graphique. Il a ensuite téléchargé la page formations avec curl pour en extraire le texte, puis récupéré le logo SVG officiel du site. Le tracé de ce logo est réutilisé tel quel dans l’animation finale.

2. Choisir une technique : la vidéo comme une fonction du temps

L’animation est une page HTML avec un <canvas> de 1920×1080 pixels, dessiné en JavaScript avec l’API Canvas 2D. Le principe est simple : chaque image est une fonction pure du temps. La fonction drawFrame(t) dessine exactement ce que l’on doit voir à t secondes, et la même valeur de t donne toujours la même image.

function drawScene(t) {
  if (t < 2.0) s1(t); // le point bleu du logo
  else if (t < 5.0) s2(t); // le manifeste typographique
  else if (t < 8.5) s3(t); // le catalogue des formations
  else if (t < 15.5) s4(t); // le terminal Claude Code
  else if (t < 18.0) s5(t); // les chiffres clés
  else s6(t); // le logo et l'appel à l'action
}

Ce déterminisme permet d’exporter la vidéo image par image, sans dépendre de la vitesse de la machine.

3. Construire un storyboard calé sur le rythme

Claude a découpé la vidéo en six scènes, toutes calées sur un tempo de 120 BPM. Chaque coupe tombe sur un temps de la musique.

Les six scènes du showreel, de la genèse du point bleu jusqu’au logo TechTown.

La scène la plus longue, de 8,5 à 15,5 secondes, est consacrée à Claude Code. Une carte du catalogue « Coder avec Claude Code » se détache, s’agrandit et devient un terminal. On y voit taper claude, puis la demande « Forme mon équipe à Claude Code ». L’agent active ensuite le Plan Mode, génère un CLAUDE.md, connecte un serveur MCP et lance des sous-agents. Le terminal se range ensuite sur le côté pour présenter les deux niveaux de formation.

4. Les techniques d’un motion designer

Claude a appliqué les techniques d’un vrai showreel :

des courbes d’accélération (outExpo, inOutCubic, outBack) pour chaque mouvement ;
des textes révélés par masque, et un effet de texte « décodé » où des glyphes aléatoires se résolvent de gauche à droite ;
un compteur à rouleaux pour le nombre de formations ;
des secousses de caméra synchronisées avec les impacts sonores ;
un grain, un vignettage et un habillage de type caméra (repères d’angle, timecode, barre de progression).

Le flou de mouvement est le détail le plus technique. Pour chaque image, Claude dessine six sous-images réparties sur une demi-durée d’image, puis les moyenne. C’est l’équivalent d’un obturateur à 180° en cinéma.

for (let i = 0; i < subs; i++) {
  const ts = t + ((i + 0.5) / subs - 0.5) * shutter / FPS;
  drawScene(ts);
  out.globalAlpha = 1 / (i + 1); // moyenne glissante
  out.drawImage(scene, 0, 0);
}

La transition entre le catalogue et le terminal : le flou de mouvement vient de la moyenne de six sous-images.

5. Le son, synthétisé de A à Z

La bande-son ne réutilise aucun sample. Un second script Node.js, audio.mjs, calcule l’onde sonore échantillon par échantillon : 48 000 valeurs par seconde, en stéréo.

Chaque instrument est une petite fonction mathématique. La grosse caisse est une sinusoïde dont la fréquence chute très vite. Les charleys et les claps sont du bruit blanc filtré. La basse et les nappes sont des ondes en dents de scie filtrées, sur une grille d’accords la mineur, fa, do, sol. Le script ajoute des montées, des impacts et des souffles pour les transitions.

Côté mixage, la musique baisse à chaque coup de grosse caisse (le fameux sidechain de la musique électronique), et une réverbération inspirée de Freeverb donne de l’espace au tout. Le script écrit enfin un fichier WAV.

La synchronisation repose sur les mêmes horaires que l’animation. Il y a même un clic de clavier par caractère tapé dans le terminal, calculé avec la même formule que l’effet de frappe.

6. Le rendu : Chrome headless et ffmpeg

Pour transformer la page en vidéo, Claude a écrit un petit serveur Node.js, sans aucune dépendance. Il sert la page et enregistre chaque image PNG que le navigateur lui envoie. Google Chrome, lancé en mode headless, calcule alors les 1 260 images de la vidéo :

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless=new \
  "http://localhost:8123/?render&subs=6"

ffmpeg assemble ensuite les images et le son :

ffmpeg -framerate 60 -i frames/%05d.png -i audio.wav \
  -c:v libx264 -crf 16 -pix_fmt yuv420p \
  -c:a aac -b:a 256k -movflags +faststart techtown-showreel-formations.mp4

Au total, le projet représente environ 1 000 lignes de code réparties dans quatre fichiers : la page HTML, l’animation, la bande-son et le serveur de rendu.

À noter : je pensais que Claude utiliserait le serveur MCP Playwright pour piloter le navigateur. Il n’était pas disponible dans la session. Claude s’est adapté en lançant directement Chrome headless, sans installer le moindre paquet.

7. Se relire avant de livrer

Avant le rendu final, Claude a vérifié son travail dans le navigateur intégré à l’application Claude. Il a ajouté à sa page un mode « planche contact » (?sheet=0.3,0.9,1.3,...) qui affiche seize vignettes de la vidéo sur un seul écran, puis il a contrôlé certaines images en plein écran.

Cette relecture lui a permis de corriger deux défauts avant le rendu : un vignettage trop fort qui grisait les textes en bord d’écran, et une liste à puces trop serrée dans les cartes de formation. Après le rendu, il a encore relu quelques images exportées pour vérifier le flou de mouvement.

🔁 Une correction, trois secondes re-rendues

La première version contenait une erreur de fond. La scène des chiffres clés reprenait la préparation aux certifications Google Cloud, présente sur la page formations. Dans une vidéo consacrée à Claude Code, ce mélange entre Google Cloud et Anthropic n’avait pas de sens.

Je l’ai signalé en une phrase, avec une capture d’écran : « change ce slide. Tu mélanges GCP et Anthropic. Tu peux juste dire 175+ formés cette année avec une courbe par exemple. »

Claude a réécrit la scène avec un compteur 175+ et une courbe de progression qui se dessine mois après mois. La forme de la courbe est illustrative : seul le total de 175 personnes formées est un chiffre réel. Il n’a ensuite re-rendu que les images concernées, autour de la plage de 15,5 à 18 secondes, avant de réencoder la vidéo. Le reste du film n’a pas bougé.

Claude avait bien trouvé l’information sur notre site, sans voir qu’elle n’avait pas sa place dans ce message. La relecture humaine des faits reste indispensable.

📣 Ce que ça change pour le marketing

Ce test m’a fait voir la vidéo marketing autrement.

Le délai entre l’idée et la vidéo se compte en minutes. Le brief tient en quatre lignes, et le premier rendu arrive dans la même session. Il devient possible de tester une idée de vidéo avant même d’en parler à une agence.

La vidéo devient du code. Elle se versionne dans Git, se relit dans une pull request et se reproduit à l’identique. Pour changer un chiffre, il suffit de modifier une ligne et de relancer le rendu de quelques secondes.

Les déclinaisons deviennent peu coûteuses. Une fois l’animation écrite, nous pouvons demander une version par formation, une version en anglais ou un format vertical pour les stories, sans repartir de zéro.

La charte graphique s’applique d’elle-même. En la décrivant une fois dans un skill, l’équipe marketing la rend disponible pour chaque prompt. Chaque vidéo, page ou visuel généré en hérite.

Le contenu reste aligné avec la réalité. Claude lit le site et les données réelles au lieu de recopier un texte figé. Dans notre cas, les 16 formations affichées dans la vidéo sont celles du catalogue.

Il y a aussi des limites, et il faut les garder en tête :

les faits doivent être relus par un humain, comme l’a montré l’erreur sur les certifications ;
les marques tierces demandent de la vigilance : la vidéo reproduit l’interface de Claude Code et une couleur de la charte d’Anthropic, ce qui mérite une vérification avant une diffusion large ;
le son synthétisé fonctionne bien pour un format court, mais ne remplace pas un compositeur ni une voix off ;
pour une campagne haut de gamme, un motion designer garde l’avantage sur la direction artistique.

Pour du contenu fréquent, court et cohérent avec la marque, en revanche, l’écart avec un agent de code devient très faible.

🎯 Conclusion

Avec un brief de quatre lignes, Opus 5.5 et Claude Code ont produit une vidéo de motion design complète : storyboard, animation, sound design et rendu final. Sous le capot, rien de magique : du Canvas 2D, du Node.js, Chrome headless et ffmpeg, orchestrés par un agent qui sait aussi relire son propre travail.

Mon takeaway : rédigez vos prompts comme des briefs créatifs, donnez une source de vérité et une charte sous forme de skill, puis gardez la main sur la relecture des faits.

👉 Et vous, quel contenu marketing confieriez-vous à un agent de code ?

🎓 Aller plus loin avec Claude Code

Vous voulez apprendre à travailler ainsi avec un agent de code ? En une journée, la formation Coder avec Claude Code - Débutant de TechTown couvre :

l’installation et la configuration de Claude Code ;
les commandes essentielles et la méthode des 3C pour formuler des prompts ;
la personnalisation de l’environnement de travail (CLAUDE.md, permissions, Plan Mode) ;
l’intégration de Claude dans un workflow Git professionnel.

Quelques retours de participants :

« Sujet passionnant, formateur passionné. »

« Cette formation m’a donné les bases de la bonne utilisation de Claude pour mon métier de dev. Je me sens prêt à l’utiliser quotidiennement et je connais la bonne direction pour progresser en autonomie sur cet outil. »

« J’ai apprécié le fait que l’on puisse approfondir certains sujets lors des questionnements ainsi que de voir des cas pratiques et des démos et TPs. »

« Bonne introduction, sujets pertinents et dans un ordre accessible. Explications théoriques claires et en accord avec la suite des TP. »

Gouvernance MCP : qui choisit les tools de vos agents de code ?

Julien Landuré — Tue, 29 Sep 2026 00:00:00 +0000

Les agents de code comme GitHub Copilot, Claude Code ou Cursor se branchent sur des serveurs MCP (Model Context Protocol). Ces serveurs leur apportent des tools : chercher un ticket Jira, lire une page Confluence, ouvrir une pull request…

C’est très pratique. Mais pour une entreprise, une question arrive vite : qui décide de ce que l’agent a le droit de faire ?

Dans cet article, nous allons partir d’un cas concret : Jira, Confluence et Context7 placés derrière une gateway MCP. Nous verrons les trois besoins de gouvernance, puis les trois solutions possibles aujourd’hui, avec leurs limites.

📌 Les trois besoins de gouvernance

Côté entreprise, nous voulons trois choses.

A. Choisir les serveurs MCP autorisés. Pas n’importe quel serveur trouvé sur Internet, mais une liste validée. Elle est publiée par une registry MCP interne, ou imposée par des managed settings , c’est-à-dire des réglages déployés par l’entreprise sur les postes.

B. Préférer les serveurs MCP distants officiels. Un serveur remote hébergé par l’éditeur (GitHub, Atlassian…) apporte :

rien à installer sur les postes : ni docker run, ni npx ;
des mises à jour gérées par l’éditeur ;
une simple URL à déclarer.

C. Filtrer les tools proposés par ces serveurs. Un serveur d’éditeur expose souvent des dizaines de tools , dont beaucoup en écriture. Le serveur open source mcp-atlassian, que nous utilisons dans notre test, en expose 97, dont une quarantaine qui modifient des données : jira_create_issue, confluence_delete_page… Nous voulons n’en garder qu’une partie, par exemple la lecture seule.

A et B sont bien outillés aujourd’hui. C est le vrai problème.

Rappel : registry et managed settings pour le besoin A

Deux mécanismes permettent déjà de choisir les serveurs.

Côté Copilot , une politique d’organisation GitHub impose à VS Code une registry MCP interne qui liste les serveurs approuvés. C’est ce que nous faisons. Une entrée de registry ressemble à ceci :

{
  "server": {
    "name": "io.github.upstash/context7",
    "remotes": [{ "type": "streamable-http", "url": "https://mcp.context7.com/mcp" }]
  }
}

Chaque entrée décrit un serveur et la façon de s’y connecter. Ici, Context7 est déclaré comme serveur distant, sans installation locale.

Côté Claude Code , nous faisons de même avec des managed settings. L’entreprise dépose un fichier de réglages, dans /Library/Application Support/ClaudeCode/ sur macOS (documentation) :

{
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.context7.com/*" },
    { "serverUrl": "https://mcp-gateway.example.com/*" }
  ],
  "deniedMcpServers": [
    { "serverUrl": "https://untrusted.example.com/*" }
  ]
}

La liste de refus est évaluée en premier. Ensuite, seuls les serveurs présents dans la liste d’autorisation peuvent être chargés.

À noter : ces deux mécanismes filtrent des serveurs , pas des tools. Une fois un serveur autorisé, tous ses tools arrivent chez l’agent.

1️⃣ Solution 1 : le filtrage proposé par l’éditeur

Certains éditeurs permettent de choisir les tools… dans la configuration du client.

Le serveur MCP distant de GitHub lit par exemple des en-têtes HTTP maison, décrits dans sa documentation :

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "X-MCP-Toolsets": "repos,issues",
        "X-MCP-Tools": "get_file_contents,issue_read",
        "X-MCP-Readonly": "true"
      }
    }
  }
}

X-MCP-Toolsets et X-MCP-Tools limitent les tools exposés, et X-MCP-Readonly ne garde que les tools de lecture.

Autre exemple : quand nous installons nous-mêmes mcp-atlassian, nous le configurons par variables d’environnement :

docker run -i --rm \
  -e READ_ONLY_MODE=true \
  -e ENABLED_TOOLS=jira_search,confluence_search \
  ...image-mcp-atlassian...

Pourquoi cette approche est fragile

C’est de la configuration client. Le réglage vit dans le mcp.json de chaque utilisateur. Il suffit de retirer X-MCP-Readonly ou READ_ONLY_MODE pour retrouver tous les tools. Ce n’est pas une barrière, c’est une préférence.
Le serveur accepte toujours tout. Avec le même token, un autre client, ou un simple curl, obtient l’ensemble des tools.
Chaque éditeur a sa propre convention. X-MCP-Tools chez GitHub, variables d’environnement chez mcp-atlassian, rien chez d’autres. Aucune règle commune n’est possible.
Cela ne fonctionne qu’avec les éditeurs qui l’ont prévu.

GitHub le précise d’ailleurs à propos de X-MCP-Lockdown : c’est un filtre « best-effort », pas une frontière de sécurité.

2️⃣ Solution 2 : une gateway MCP entre les agents et les serveurs

L’idée est simple : les agents ne parlent plus directement aux serveurs MCP. Ils passent par une gateway qui applique la politique de l’entreprise.

Tous les agents passent par la même gateway, qui applique la liste blanche des tools et journalise chaque appel.

Nous avons testé cette approche avec agentgateway, un projet open source de l’Agentic AI Foundation (AAIF), en version 1.5.0. Toute la politique tient dans un fichier de configuration :

routes:
- name: atlassian
  matches:
  - path: { pathPrefix: /atlassian/mcp }
  policies:
    mcpAuthorization:
      rules:
      # Liste blanche : seuls ces tools existent pour l'agent
      - 'mcp.tool.name in ["jira_get_issue", "jira_get_all_projects", "confluence_search", "confluence_get_page"]'
  backends:
  - mcp:
      targets:
      - name: atlassian
        mcp: { host: http://localhost:8000/mcp }

Les règles mcpAuthorization sont des expressions CEL (Common Expression Language). Ici, un seul tableau suffit à décrire la liste blanche de la route Atlassian.

⚡️ Voici ce que nous avons constaté pendant le test :

Les tools refusés disparaissent de la liste envoyée à l’agent (tools/list). Le modèle ne sait même pas qu’ils existent.
Un appel direct à un tool refusé est rejeté , même forcé à la main avec curl.
Le token de l’utilisateur est relayé tel quel. Atlassian voit toujours la vraie personne, avec ses propres droits.
Chaque appel est journalisé : quel serveur, quel tool, quand. Nous obtenons des statistiques d’usage sans effort supplémentaire.

Voici un extrait réel des logs d’accès, simplifié :

{"route":"default/context7","http.status":200,"mcp.method.name":"tools/call",
 "mcp_target":"context7","mcp_tool":"resolve-library-id","duration":"2274ms"}

Enfin, côté poste, rien à installer. L’agent déclare simplement l’URL de la gateway :

{
  "mcpServers": {
    "atlassian": {
      "url": "https://mcp-gateway.example.com/atlassian/mcp",
      "headers": { "Authorization": "Basic <base64(email:token)>" }
    }
  }
}

Les limites de la gateway

Il faut héberger et maintenir un composant de plus , dans notre cas un service Cloud Run.
Il faut tenir la liste blanche à jour quand l’éditeur ajoute ou renomme des tools.
Il faut penser la sécurité réseau. Par exemple, ne jamais transmettre le token Atlassian d’un utilisateur à un autre serveur :

policies:
  requestHeaderModifier:
    remove: [authorization] # sur la route Context7

Le filtrage se fait au niveau du tool , pas de ses paramètres. Pour aller plus loin, par exemple réécrire un schéma ou limiter un projet Jira, agentgateway propose des MCP guardrails. Il faut alors développer un service externe.

💪 ProTip : gardez une route par serveur MCP plutôt qu’une route unique qui les agrège. Les noms de tools restent inchangés, et un token ne peut pas fuiter d’un serveur à l’autre.

C’est la seule solution où la règle est appliquée côté serveur, au même endroit pour tous les agents.

3️⃣ Solution 3 : choisir les tools dans chaque agent de code

Troisième voie : garder la connexion directe et restreindre les tools dans la configuration de l’agent.

Côté Copilot CLI , c’est simple : une liste blanche par serveur.

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "tools": ["jira_get_issue", "confluence_search"]
    }
  }
}

VS Code propose en plus un sélecteur de tools dans l’interface du chat. Mais c’est à chaque développeur de choisir les tools qu’il charge dans sa fenêtre de contexte : l’entreprise ne peut pas imposer ce choix.

Côté Claude Code , c’est plus pénible. Il n’existe pas de liste tools par serveur, il faut passer par les règles de permissions :

{
  "permissions": {
    "deny": [
      "mcp __atlassian__ jira_create_issue",
      "mcp __atlassian__ jira_update_issue",
      "mcp __atlassian__ jira_delete_issue",
      "mcp __atlassian__ confluence_create_page",
      "mcp __atlassian__ confluence_delete_page"
    ]
  }
}

Un tool refusé est bien retiré du contexte du modèle, et une règle posée dans les managed settings ne peut pas être contournée par l’utilisateur. Mais deux points compliquent la maintenance :

une règle deny l’emporte toujours sur une règle allow. Impossible d’écrire « tout refuser sauf ces quatre tools » avec deny: mcp __atlassian__ * puis allow: …. Il faut lister un par un tout ce que nous refusons, et revoir la liste à chaque nouveau tool de l’éditeur ;
les règles dépendent du nom local donné au serveur (mcp __atlassian__ …). Si l’utilisateur l’appelle jira, la règle ne s’applique plus.

Surtout, chaque agent a sa propre syntaxe. Une entreprise qui autorise Copilot, Claude Code et Cursor doit écrire et maintenir trois politiques différentes, puis vérifier qu’elles disent la même chose.

⚖️ Comparatif des trois solutions

	1. Filtrage éditeur (client)	2. Gateway MCP	3. Réglage par agent
Où vit la règle	config client	serveur (gateway)	config de chaque agent
Contournable par l’utilisateur	oui	non	oui, sauf managed settings Claude Code
Marche avec tous les éditeurs	non	oui	oui
Marche avec tous les agents	oui	oui	une syntaxe par agent
Statistiques d’usage	non	oui	non
Coût	nul	un service à héberger	maintenance de N configurations

🎯 Conclusion : il manque une brique dans la spec MCP

Aujourd’hui, la seule manière fiable de filtrer les tools des éditeurs est d’ajouter une gateway. Elle fonctionne bien, mais c’est une infrastructure de plus pour un besoin que toutes les entreprises partagent.

La dernière version de la spécification MCP (2026-07-28) fait déjà un pas vers les intermédiaires :

chaque requête HTTP porte des en-têtes standard comme Mcp-Method: tools/call et Mcp-Name: jira_search, pour qu’une gateway puisse router sans lire le corps de la requête ;
un serveur peut demander au client de recopier certains paramètres dans des en-têtes Mcp-Param-*, grâce à l’extension x-mcp-header.

Mais rien de tout cela ne permet de dire au serveur « n’expose que ces tools » ou « lecture seule ». Chacun invente sa convention : X-MCP-Tools et X-MCP-Readonly chez GitHub, READ_ONLY_MODE et ENABLED_TOOLS chez mcp-atlassian.

Ce qui manque, c’est une généralisation de ces réglages dans la spécification. Par exemple, avec des en-têtes qui n’existent pas encore :

POST /mcp HTTP/1.1
Mcp-Method: tools/list
Mcp-Tools: jira_get_issue,confluence_search
Mcp-Read-Only: true

Trois règles simples suffiraient :

Des en-têtes standard , compris par tous les serveurs, pour restreindre les tools et imposer la lecture seule.
Ils ne peuvent que restreindre , jamais élargir ce que le serveur autorise déjà. GitHub applique déjà ce principe à son mode lockdown.
Les intermédiaires doivent les propager , et peuvent les imposer. Une gateway ou un proxy d’entreprise pourrait alors ajouter Mcp-Read-Only: true à toutes les requêtes, sans maintenir de liste de tools, et chaque serveur l’appliquerait lui-même.

Avec cette brique, la gouvernance deviendrait simple :

la registry choisit les serveurs (A) ;
les serveurs distants officiels évitent toute installation sur les postes (B) ;
un en-tête standard , posé par l’entreprise et impossible à retirer côté poste, filtre les tools (C).

En attendant, la gateway reste la solution la plus robuste. C’est aussi un excellent point d’observation pour mesurer ce que les agents font vraiment de ces serveurs.

👉 Et vous, comment filtrez-vous les tools MCP de vos agents de code ?

🎓 Aller plus loin avec MCP

Vous voulez comprendre MCP de l’intérieur ? En une journée, la formation Model Context Protocol (MCP) de TechTown couvre :

l’architecture client-serveur ;
les tools, les resources et les prompts ;
le cycle de vie d’une requête ;
la création de serveurs MCP en Python et en Java ;
l’intégration avec des agents IA et le déploiement dans le Cloud.

La journée alterne théorie et ateliers pratiques.

My first talk at AWS Summit Paris: steer your code agents with Kiro

Julien Landuré — Thu, 17 Sep 2026 00:00:00 +0000

I presented Spec-Driven Development with Benjamin Bourgeois. The room was full, and the feedback made me very happy.

I had the opportunity to give my first talk at AWS Summit Paris, on 1 April 2026, at the Palais des Congrès. I presented with Benjamin Bourgeois, Cloud and AI consultant at TechTown.

Our session was DEV211 , in the Developer Community Zone, from 13:00 to 13:45. The title was Kiro : Ne codez plus seul, pilotez vos agents de code. The slides are online if you want to replay the deck.

I was very happy to host this talk. The room was more than full. The official feedback was excellent. In this article, I’ll share what we presented about Kiro, and what I take from this first Summit stage.

Benjamin and I, before our first AWS Summit talk together.

A packed Developer Community Zone

235 people came into a room built for 100. That is a 235% fill rate.

Kiro was also easy to find around the event. In the AWS Village, this wall summed up the product in one sentence: an agentic AI development environment that brings structure to AI coding.

Kiro in the AWS Village at AWS Summit Paris 2026.

If you want the photos from the day, they are on my LinkedIn posts: the session announcement and the recap after the Summit.

Don’t code alone, steer your agents

Kiro is the agentic IDE from AWS. It is more than a code editor. It helps you build applications with an AI-native workflow, while you keep control of quality.

We started with a simple story of the last few years:

We ask an AI for help.
We use autocomplete.
We now work with code agents.

Chat-only workflows have limits:

A new conversation can lose the context.
The context window is limited.
The context is hard to share with the team.

This is why we talked about the Augmented Developer. You do not let the agent guess. You steer it. You write the intent first. Then the agent writes the code.

The developer becomes the person who guides the agents, not the person who types every line.

Spec-Driven Development in Kiro

The main idea of the talk was Spec-Driven Development (SDD).

In Kiro, a prompt can become a structured specification before any code is generated. You can review the intent, the design, and the tasks. Then you let agents implement the work.

A spec in Kiro usually has three files:

requirements.md — what we want, with user stories and acceptance criteria
design.md — how we will build it
tasks.md — the steps to implement

You validate the specification first. You generate code second. That is the difference with a long prompt that jumps straight to files.

One attendee summed it up well: they understood how Kiro turns development into an AI-native workflow, where prompts become structured specs before code generation. They also learned how to steer code agents, automate tests and documentation, and keep control while going faster.

The result we wanted people to leave with: more automation, less guesswork, and better control of the final code.

Practices of the Augmented Developer

We also shared practices that help you get useful code from agents, not just fast code.

Context Engineering : give the agent the right context, not a bigger prompt.
AGENTS.md : a project file that is added to the agent context automatically.
Steering : markdown files that keep your team rules and conventions across chats.
Skills : reusable packages with a prompt, examples, and scripts.
MCP (Model Context Protocol): connect the agent to external tools and data.
Hooks : run tests, linters, or docs when a file is saved or a task ends.

We showed this live on stage. The goal was not to replace developers. The goal was to help developers stay the person who decides.

ProTip: before you ask Kiro to generate a feature, ask it to write the spec. Read requirements.md and design.md. If the intent is wrong, fix the spec. Do not fix 20 generated files.

The feedback that made me smile

AWS later sent us the official session scores. They are based on 19 survey responses :

Content: 4.74 / 5
Speaker: 4.79 / 5
Tech depth: 4.68 / 5
Learned something new: 94.7%

One written comment was simple and kind: “Très instructif.”

AWS also turned the feedback into a song title, just for fun: Come Together, by The Beatles. Two speakers, one story, and a room that came together. That made me smile.

I ended the day at a community dinner with the AWS team. After a first Summit talk, it was a pleasure to meet people, talk about Kiro, and hear what developers want to try next.

What I take from this first Summit talk

I am very proud of this first talk at AWS Summit. Sharing the stage with Benjamin felt natural. Seeing 235 people in a 100-seat room was a strong signal: developers want to understand how to work with agents, not only how to prompt them.

If you missed the session, start here:

Open the slides.
Open kiro.dev.
Sign in with an AWS Builder ID.
Write a small spec before you generate code.
Add an AGENTS.md or a steering file, so the agent knows your project rules.

Have you tried Spec-Driven Development yet? I would love to hear how you steer your agents.

Useful links

Your Face on a World Cup Sticker: Our Nano Banana Story

Julien Landuré — Tue, 28 Jul 2026 11:09:48 +0000

There is something timeless about opening a pack of football stickers. You never know which player, celebration, or rare edition you will find next.

For the 2026 World Cup, we wanted to recreate that feeling with a personal twist: what if the player on the sticker was you, your friends, or your family? That simple idea became Sticker Studio, a small experiment powered by Google's Nano Banana image model.

Take a photo, choose a national team, add your name, and the application transforms your face into a playful cartoon football sticker. In this article, we'll explore the idea, the prompt system behind every scenario, the reference images that fixed our 2026 jerseys, and why we upgraded from Nano Banana 1 to Nano Banana 2.

⚽ 1. The idea: putting our own faces on the stickers

The starting point was not a technical challenge. It was fun.

We wanted the nostalgia of football sticker albums without simply reproducing a traditional player portrait. Each result had to feel personal:

the face should remain recognizable.
the rendering should look like a playful children's illustration, not a photorealistic edit.
the person should wear their selected national team's kit.
every sticker should tell a small story.
rare borders and special effects should bring back the excitement of opening a pack.

The experience is deliberately simple. You provide a photo and a name, choose your team, and let the application create the surprise.

Behind that simple flow, the application runs an Astro frontend on Firebase Hosting and an API on Cloud Run. The browser sends the photo and the user's choices to the backend. The backend selects the scenario, builds the complete prompt, attaches the relevant references, and calls the Gemini image-generation API.

The AI is asked to preserve the real identity cues visible in the photo — face shape, skin tone, hairstyle, facial hair, eyebrows, expression, and accessories such as glasses. At the same time, it must turn that identity into a simplified, expressive cartoon.

This balance matters. Too realistic, and the result loses its friendly illustrated character. Too generic, and the person no longer recognizes themselves. The fun happens in between.

✍️ 2. One prompt engine, dozens of scenarios

A prompt like “turn this person into a football sticker” can produce an image. It does not produce a consistent collection.

To make stickers generated for different people feel as if they belong to the same album, we built every prompt from the same six-part structure:

Subject and identity — who the person is and which visible traits must be preserved.
Kit — the selected national team and its official football jersey.
Action — the humorous pose or celebration.
Environment — the stadium, pitch, city, or imaginary setting around the player.
Style and card layout — the shared visual rules, border, typography, and rarity effects.
Output constraints — a centered, vertical, full-bleed composition suitable for a sticker.

In the backend, those layers are assembled in TypeScript. Here is a shortened version of the production function:

function buildStickerPrompt(opts: PromptOptions): string {
  const name = (opts.userName || "PLAYER").trim().toUpperCase();
  const border = opts.border ?? opts.scenario.border;
  const styleBible = opts.styleBible?.trim() || DEFAULT_STYLE_BIBLE;

  return [
    "Using the attached real photo as the identity reference...",
    `The character wears the official kit of ${opts.teamName}.`,
    ...(opts.referenceInstruction?.trim()
      ? [opts.referenceInstruction.trim()]
      : []),
    `Scenario: the character is ${opts.scenario.action}.`,
    `Presented inside a trading-card layout with ${borderPhrase(border)}.`,
    `At the bottom, render the name '${name}' on one readable line.`,
    styleBible,
    "Center the subject. Use a vertical, full-bleed composition.",
  ].join(" ");
}

The function keeps the permanent art direction in one place, then injects only the values that make a sticker unique. It also makes optional instructions explicit: a jersey reference, trophy, ball, or rare effect is included only when the selected slot needs it.

The scenarios provide variety. One person can perform a bicycle kick in a packed stadium. Another can ride a rocket-powered football through space, take a victory selfie, attempt a Panenka, meditate on the pitch, or lift the trophy under golden confetti.

Here is a shortened example based on the real prompt structure:

Using the attached real photo as the identity reference, transform this exact person into a humorous parodic cartoon caricature. Match their real face closely: face shape, skin tone, hairstyle, facial hair, eyebrows, and expression.

The character is a professional soccer player wearing the official kit of the France national football team.

Scenario: the character is performing a spectacular overhead bicycle
kick in mid-air, with the ball blurring off the foot and a packed
stadium behind.

Presented inside a rectangular trading-card layout with a vibrant blue parallel border. At the top, arched text reads 'WORLD CUP 2026'. At the bottom, the name 'JULIEN' is fully readable.

Art style: die-cut sticker design, bold clean white outer outline,
2D vector illustration, flat colors, simple cel shading, thick black
ink outlines, high contrast, and playful humorous cartoon caricature.

Center the subject. Use a vertical, full-bleed composition.

The shared visual instructions are our Style Bible. They keep the thick outlines, flat colors, card frame, typography, and composition stable across all generations.

We also randomize collectible details. Common stickers appear more frequently, while gold, silver, black, and holographic borders are less common. Some generations receive a World Cup trophy or official ball as a secondary prop. Around one sticker in twenty gets a golden LEGENDAIRE badge.

The result is more than a photo filter. The same input can become a genuinely different collectible each time.

💪 ProTip: separate stable visual rules from variable scenario instructions. It makes your prompt system easier to tune and prevents a change to one celebration from altering the visual identity of the whole collection.

👕 3. When the AI remembered the wrong jerseys

The first stickers looked promising, but one detail immediately broke the illusion: the kits were wrong. For example, this result clearly uses an older France jersey.

Nano Banana often generated older designs, including 2024-era jerseys. That is understandable — a text prompt can describe “the official 2026 France home kit,” but the model still needs reliable visual information about a new design.

We solved this with multimodal reference images.

For France, England, Spain, and Argentina, the backend now attaches a packshot of the official 2026 home jersey to the generation request. The prompt explicitly tells Nano Banana to reproduce its colors, pattern, collar, marks, and crest placement in the cartoon style.

It also draws a strict boundary:

This image is ONLY a clothing reference. Ignore any person, mannequin,
face, body, pose, or background shown in it, and use it solely for the
jersey design.

We applied the same technique to the official 2026 match ball. Whenever a scenario includes a football, the backend sends the ball image and asks the model to reproduce its base color, panel shapes, colored zones, and line patterns.

The complete request can therefore contain:

the user's portrait for identity;
a 2026 jersey packshot for clothing;
the official match-ball image for the ball design;
the assembled text prompt for the scene and visual rules.

The actual Gemini request follows that order:

const parts: Array<Record<string, unknown>> = [
  { inlineData: portrait },
  ...(jersey ? [{ inlineData: jersey }] : []),
  ...(ball ? [{ inlineData: ball }] : []),
  { text: prompt },
];

const response = await ai.models.generateContent({
  model: DEFAULT_MODEL,
  contents: [{ role: "user", parts }],
  config: {
    imageConfig: { aspectRatio: "3:4" },
  },
});

The ordering is intentional: the portrait remains the primary identity reference, followed by controlled visual assets and finally the instructions that explain how to use them. All of this happens on the backend. The browser sends the photo and business choices, but it never receives the Gemini API key or controls the raw production prompt.

There was one important gotcha. A jersey reference containing a recognizable face or head could make the image request fail with finishReason=IMAGE_OTHER and no generated image.

⚡️ ProTip: prepare product references as clean packshots. Crop jersey images to the torso, remove faces and heads, keep the background simple, and use a reasonably sized compressed image. Reference quality directly affects both reliability and adherence.

🍌 4. Moving from Nano Banana 1 to Nano Banana 2

Our first production version used Nano Banana 1 through gemini-2.5-flash-image.

It proved that the concept worked. It could transform a portrait, create the cartoon style, and follow imaginative football scenarios. But as our prompts gained more constraints, we needed stronger adherence: preserve the person's identity, copy a new jersey, use the correct ball, render the name, respect the card frame, and still create a dynamic scene.

We upgraded the production model to Nano Banana 2, exposed through gemini-3.1-flash-image.

The improvement was not about adding more adjectives to the prompt. Nano Banana 2 followed the combined identity, reference-image, text, and layout instructions more reliably. That made it a better fit for a product in which small details — the correct collar, visible glasses, or an uncropped name — determine whether the sticker feels right.

We compared both versions with the same portraits, scenarios, and prompts before switching. Keeping the model name configurable also means we can repeat those A/B tests as the Gemini image family evolves.

The generation still uses a 1K output. For a fast, playful web experience, this gives us a practical balance between visual quality, latency, and cost.

You can learn more about image generation in the official Gemini API documentation.

🚀 5. From a side project to real API limits

The first audience was exactly who we built it for: friends and family.

Then people started generating several versions, trying another team, looking for a rarer border, and sharing the funniest results. That is great product feedback — and a fast way to discover API quotas.

At Gemini API Tier 1, our daily request limits became a real constraint. The API key is only the credential; the effective quota comes from the associated Gemini API project and usage tier. Once the studio became active, generation capacity mattered as much as prompt quality.

A big thank you to Guillaume Vernade, who helped us move to Tier 3 and give the experiment enough room for more people to play.

This was a useful reminder: when an AI demo becomes shareable, usage can grow differently from a traditional application. One visit may trigger several expensive generation calls because exploration is part of the experience. Quotas, concurrency, retries, and graceful error messages belong in the product design from the beginning.

Thanks to a spending cap, we can also control how much we spend on new generations. Each sticker costs approximately $0.20 to generate, so the cap protects the experiment from an unexpectedly high bill.

🎯 Conclusion: now create your World Cup sticker

Sticker Studio started with one simple question: what if our friends and family were the players inside the pack?

Building it taught us three practical lessons:

structured prompts turn isolated images into a coherent collection;
current visual references are essential when recent jerseys and equipment must be accurate;
a stronger model and enough API capacity matter once people start experimenting.

But the main result is much simpler: it is fun.

Friends and family have already generated 365 stickers. With the World Cup final finished, now is the perfect time to create yours, try another team, compare rare editions, and share the result.

👉 Create your own World Cup sticker with Sticker Studio

Which team, scenario, and rarity will you get?

IMPORTANT NOTE: Sticker Studio is a playful, unofficial fan project and is not affiliated with Panini or FIFA.

How to celebrate an achievement as an open source developer?

Julien Landuré — Tue, 30 Jun 2020 14:40:05 +0000

✏️ As an open source developer, I've maintained on GitHub a docker image since July 2017: an "Alpine Chrome" and now the image has been pulled more than 🎉 1 000 000 times 🎉 on the Docker Hub.

I wrote about it recently on Dev.to 👇

Crafting the perfect container to play with a Headless Chrome

Julien Landuré for Zenika ・ May 26 '20

#opensource #docker #testing #javascript

🎯 What can I do to celebrate this achievement?

🤔 I do not know what kind of celebration I could do! It's a big achievement from my point of view.
🚀 I've started with a tweet here

// Detect dark theme var iframe = document.getElementById('tweet-1277969952415215617-374'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1277969952415215617&theme=dark" }

😊 Disclaimer: I am not a designer and I've spent too much time designing the arrows to highlight the docker pulls: 1M information. Please do not judge it... and I've successfully added a :rocket: emoji on the screenshot.

🎉 What else?

💚 Do you have any kind of ideas or stories to share about celebrating your open source achievements?

Create a GIF?
Invite my friends to celebrate it in a restaurant?
[your turn]

⏱ 3 minutes to deploy your static Nuxt.js app on AppEngine

Julien Landuré — Tue, 09 Jun 2020 12:53:17 +0000

I’ve been deploying applications on serverless solutions since 2010. Recently, I discovered Nuxt.js and I wanted to create this post on how to quickly set up a static Nuxt.js app on AppEngine, the Google Cloud PaaS.

📝 Getting started with Nuxt.js

Nuxt.js is described as

The Intuitive Vue Framework
Build your next Vue.js application with confidence using NuxtJS.
An open source framework making web development simple and powerful.

It's very powerful! You can use it to create various architectures: SSR, SPA or Static renderings.
For this demo, we will be focused on the static feature using the nuxt generate command.

⚗ Create the project

For the demo, we will use a fresh new project. To do this, execute the npx create-nuxt-app command to create a simple Nuxt.js application.

$ node -v
v12.16.3

$ npx create-nuxt-app

create-nuxt-app v2.15.0
✨  Generating Nuxt.js project in .
? Project name nuxt-static-deploy-appengine
? Project description My glorious Nuxt.js project
? Author name Julien Landuré
? Choose programming language TypeScript
? Choose the package manager Npm
? Choose UI framework None
? Choose custom server framework None (Recommended)
? Choose the runtime for TypeScript Default
? Choose Nuxt.js modules (Press <space> to select, <a> to toggle all, <i> to inv
ert selection)
? Choose linting tools Prettier
? Choose test framework None
? Choose rendering mode Universal (SSR)
? Choose development tools (Press <space> to select, <a> to toggle all, <i> to invert selection)
...
🎉  Successfully created project nuxt-static-deploy-appengine

✅ Test locally

As described in the command line, run the npm run start script to get your app running on http://localhost:3000/.

Let's edit the index.vue and write this html:

<h2 class="subtitle">Hello Nuxt on AppEngine 🎉</h2>

And it works! Very easy to see our modification instantly.

🏗 Build it

To build the app statically, run the npm run generate command:

$ npm run generate

> nuxt-static-deploy-appengine@1.0.0 generate .../nuxt-static-deploy-appengine
> nuxt generate

ℹ Production build                                                    10:52:36
✔ Builder initialized                                                 10:52:37
✔ Nuxt files generated                                                10:52:37
ℹ Starting type checking service...                   nuxt:typescript 10:52:39

✔ Client
  Compiled successfully in 6.95s

✔ Server
  Compiled successfully in 1.13s


Hash: c5e482cb9772cddb1178
Version: webpack 4.43.0
Time: 6951ms
Built at: 05/27/2020 10:52:46 AM
                         Asset       Size  Chunks                         Chunk Names
../server/client.manifest.json    6.6 KiB          [emitted]              
       98f4a70ff71f0382866c.js   2.31 KiB       3  [emitted] [immutable]  runtime
       9fc3f5e914943c5b3a9b.js   2.97 KiB       2  [emitted] [immutable]  pages/index
                      LICENSES  389 bytes          [emitted]              
       a51444c83f14a6afaeb5.js    153 KiB       1  [emitted] [immutable]  commons.app
       d267ba93006b46dadaa8.js   49.2 KiB       0  [emitted] [immutable]  app
 + 2 hidden assets
Entrypoint app = 98f4a70ff71f0382866c.js a51444c83f14a6afaeb5.js d267ba93006b46dadaa8.js

Hash: fbd0c6af7579246a49e7
Version: webpack 4.43.0
Time: 1127ms
Built at: 05/27/2020 10:52:47 AM
                  Asset       Size  Chunks                         Chunk Names
818a9680ee5eeafdfb4b.js   3.05 KiB       1  [emitted] [immutable]  pages/index
              server.js   26.7 KiB       0  [emitted]              app
   server.manifest.json  145 bytes          [emitted]              
Entrypoint app = server.js
ℹ Generating pages                                                    
✔ Generated /

✨ Congratulations, we built our first Nuxt.js application!

ProTips: We can check the files in the dist folder or run it with npx http-server dist.

☁️ Deploy it on AppEngine

Then, to share the project with the rest of the world, we can deploy it on AppEngine. Appengine comes with a lot of features and quotas.

It is free for a basic usage thanks to its quotas BUT we have to enable billing to enjoy it. As a new customer, we get $300 to spend on Google Cloud Platform products during your free trial.

🛒 Create a project

Go to console.cloud.google.com and create a new Google Cloud Platform project.
Please save the [PROJECT_ID] of the project: you have to replace the nuxt-static-deploy with your [PROJECT_ID] for the rest of the post.

ProTips: we can retrieve the [PROJECT_ID] in the url of the web console like https://console.cloud.google.com/appengine/start?project=nuxt-static-deploy where nuxt-static-deploy is my [PROJECT_ID].

ProTips: To create a project to host your app, we can also use the gcloud projects create command. we need to enter a [PROJECT_ID], nuxt-static-deploy for example.

# Create a project 
$ gcloud projects create nuxt-static-deploy 
Create in progress for [https://cloudresourcemanager.googleapis.com/v1/projects/nuxt-static-deploy].
Waiting for [operations/cp.4929250122387435991] to finish...done.              
Enabling service [cloudapis.googleapis.com] on project [nuxt-static-deploy]...
Operation "operations/acf.803672e3-74b0-43e1-8a6b-3d37a4a0975b" finished successfully.

# List the billing accounts
$ gcloud beta billing accounts list
ACCOUNT_ID            NAME                                          OPEN
00ADEE-870384-XXXXXX  my_account                                    True

# Link the billing account to my project
$ gcloud beta billing projects link nuxt-static-deploy --billing-account=00ADEE-870384-XXXXXX
billingAccountName: billingAccounts/00ADEE-870384-XXXXXX
billingEnabled: true
name: projects/nuxt-static-deploy/billingInfo
projectId: nuxt-static-deploy

# Enable Cloud Build API
$ gcloud --project nuxt-static-deploy services enable cloudbuild.googleapis.com

✏️ Write the descriptor `app.yaml`

AppEngine supports various programming languages: python, go, java, php, nodejs etc.
To deploy static files, the best practice is to use the python37 runtime.

Let's create a file in .appengine/app.yaml

runtime: python37

handlers:
- url: /
  static_files: index.html
  upload: index.html
  secure: always
- url: /(.*)
  static_files: \1
  upload: (.*)
  secure: always

For more information on the descriptor file, please read this doc.

Don't forget to copy the file in our dist folder using this command cp .appengine/app.yaml dist/.

ProTips: We can add it to the build script in your package.json file.

🚀 Deploy your app

If this is the first you are using the Google Cloud Platform, you have to install the gcloud command line utility following the official page or using Homebrew.

Deploy our app using the gcloud app deploy command:

$ gcloud app deploy --project nuxt-static-deploy dist 

You are creating an app for project nuxt-static-deploy.
WARNING: Creating an App Engine application for a project is irreversible and the region
cannot be changed. More information about regions is at
<https://cloud.google.com/appengine/docs/locations>.

Please choose the region where you want your App Engine application 
located:

 [1] asia-east2    (supports standard and flexible)
 [2] asia-northeast1 (supports standard and flexible)
 [3] asia-northeast2 (supports standard and flexible)
 [4] asia-northeast3 (supports standard and flexible)
 [5] asia-south1   (supports standard and flexible)
 [6] australia-southeast1 (supports standard and flexible)
 [7] europe-west   (supports standard and flexible)
 [8] europe-west2  (supports standard and flexible)
 [9] europe-west3  (supports standard and flexible)
 [10] europe-west6  (supports standard and flexible)
 [11] northamerica-northeast1 (supports standard and flexible)
 [12] southamerica-east1 (supports standard and flexible)
 [13] us-central    (supports standard and flexible)
 [14] us-east1      (supports standard and flexible)
 [15] us-east4      (supports standard and flexible)
 [16] us-west2      (supports standard and flexible)
 [17] us-west3      (supports standard and flexible)
 [18] us-west4      (supports standard and flexible)
 [19] cancel
Please enter your numeric choice:  7

Creating App Engine application in project nuxt-static-deploy and region [
europe-west]....done.                                                          
Services to deploy:

descriptor:      [.../nuxt-static-deploy-appengine/dist/app.yaml]
source:          [.../nuxt-static-deploy-appengine/dist]
target project:  [nuxt-static-deploy]
target service:  [default]
target version:  [20200602t094056]
target url:      [https://20200602t094056-dot-nuxt-static-deploy.ew.r.appspot.com]


     (add --promote if you also want to make this service available from
     [https://nuxt-static-deploy.ew.r.appspot.com])

Do you want to continue (Y/n)?   

Beginning deployment of service [default]...
╔════════════════════════════════════════════════════════════╗
╠═ Uploading 12 files to Google Cloud Storage               ═╣
╚════════════════════════════════════════════════════════════╝
File upload done.
Updating service [default]...done.                                             
Deployed service [default] to [https://20200602t094056-dot-nuxt-static-deploy.ew.r.appspot.com]

You can stream logs from the command line by running:
  $ gcloud app logs tail -s default

To view your application in the web browser run:
  $ gcloud app browse

🎉 Enjoy

Go here at https://nuxt-static-deploy.appspot.com/ to see our first Nuxt.js app deployed with AppEngine.

🔍 Conclusion

Nuxt.js is a cool technology to create Vue.js app and is trending with the release of @nuxt/content

// Detect dark theme var iframe = document.getElementById('tweet-1263795755954909184-839'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1263795755954909184&theme=dark" }

AppEngine comes with a lot of features:

🔁 Multiple versions available to do A/B testing or Traffic Splitting (each version has a different timestamp on the Versions Page on Appengine)
🔐 Custom Domain Mapping & auto-renew, free, managed SSL certificates
💸 Free quota (1 GB bandwidth)
⭐️ No instance used with Python37 runtime and our configuration because we have only static content
🌐 Static content available through Google CDN and its Edge Network
⚡️ Managed network: Surprise 🎉 our project uses the http3 procotol h3-Q050.

Feel free to contact me on Twitter if you have questions!

NB: You can find another guide on Nuxt.js with AppEngine here in the official documentation.

Crafting the perfect container to play with a Headless Chrome

Julien Landuré — Tue, 26 May 2020 06:19:17 +0000

Since July 30th 2017, I have been contributing to a side project: the idea from the beginning was the ability to use Chrome to make some tests in headless mode and avoid a long queue of CI builds using a tiny Docker image.

🤔 Why use a Headless Chrome

In the world of webdev, the ability to run quickly end-to-end tests are important. Popular technologies like Puppeteer enable developers to make fun things like testing, automating forms, crawling, generating screenshots, capturing timeline... And there is a secret: some of these features are directly available on Chrome! 🙌

For more information on why headless mode is a cool feature, please read a good example on what you can achieve here:

Create PDFs with Node.js and Puppeteer

David Neal ・ Feb 6 '20

#node

💡 Crafting the perfect container

With 28 contributors, I have been working on this project to create the perfect image to run Chromium in Headless mode:

📦 Tiniest Headless Chrome (393 MB)
🐳 Easy to use, ephemeral and reproducible Headless Chrome with Docker
📝 Doc-friendly with examples for printing the DOM, generating an image with a mobile ratio or generating a PDF.
👷‍♂️ Autobuild with the Docker Hub to sync the project and ship the images with confidence
📌 Up-to-date with Chromium 81 (81.0.4044.138) and tags available to test different versions of Chromium
🔐 Secure with the best way to use Chrome and Docker - See "3 ways to securely use Chrome Headless" section
🌐 Ready for internationalisation use: support for asian characters - See "screenshot-asia.js" file
💄 Ready for design use: support for WebGL - See "How to use with WebGL" section
📄 Open Source with an Apache2 licence
👥 Community-built with 28 contributors - See "✨ Contributors" section
💚 Dev-friendly with examples using NodeJS, Puppeteer, docker-compose and also a test with a X11 display - See "Run examples" section

💚 Open Source & Fun

Some open source & fun projects have been set up and used for this open source side project. I want to share it with you: it adds value and confidence to maintain a GitHub repository. 👌

Updates to follow the recommended community standards from the GitHub community profile
Gitmoji for commit messages where I have contributed in the past 😊
All Contributors to thanks everyone who contributes to the project
Inspiration from readme-md-generator made by my friend Franck Abgrall
Inspiration from this cheatsheet on "How to promote your open-source project?"
Renovate for dependency updates
Many reads on dev.to to know what web developers are doing with Chrome and Puppeteer

🚀 Reaching a point

Here is the most interesting insight for a tool: to be used and useful! In almost two weeks, this image will be pulled on the Docker Hub...

🎉 a million times! 🎉

there is currently ~922k downloads and it grows ~6k by day
On GitHub, the repository gets ~3000 views, ~1000 unique visitors every two weeks and ~464 stars.

After 3 years maintaining it, I cannot thank everyone using this container. This is the first time a side project has become so popular.

🗓 The Future

✨ Here is some features in the roadmap:

with-playwright version with Playwright to reuse the installed headless Chromium (PR in draft)
with-deno version with Deno to create a useful and fun things to do with deno
with-lighthouse version with Lighthouse to be able to monitor your website performance in CI builds
Create a dedicated homepage and documentation website: the README.md begins to be complicated to navigate and update
Create a gallery with the name of the project or product using this container

📣 Please test this container or play with it!
💻 If you are interested to help me maintain this image, we are welcome! There is some "Good first issue" labelled issue on the repository.

Disclaimer: these terms in this post are synonyms: "Chrome" vs "Chromium" and "image" vs "container".

State of Cloud Communities in France

Julien Landuré — Tue, 14 Apr 2020 06:52:54 +0000

Karen Tamrazyan wrote a good article that analyzes local communities of 3 major public cloud providers AWS, Azure and Google Cloud in Germany, Austria and Switzerland (German-speaking countries) here:
https://www.tamrazyan.com/state-of-cloud-communities-in-german-speaking-countries/

His article made me think about France. He helped me to create a similar sheet to superficially compare regional communities behind the three major public cloud providers: Amazon Web Services (aka AWS), Microsoft Azure and Google Cloud.

Comparison

The top right quadrant from the latest Gartner cloud market analysis clearly indicates three global cloud leaders: Amazon Web Services, Microsoft Azure, Google Cloud.

How are we going to compare the communities with each other? As Karen did in his article, we will compare them by the amount of registered members or the group size in other words. It is obvious that the group size is just one metric of many, like e.g. the activity rate (how often do events take place), the average number of participants, the date of the last event and so on… The members count should serve as a simplified way of measurement of a group success or importance.

The internet is big. What kind of groups are we going to count? Indeed, there are cloud communities as Facebook groups, on different messenger networks like e.g. Telegram, independently hosted forums and so on. In this work we will count only the communities, which are hosted on the Meetup.com platform. Meetup is at the moment a de facto most popular community platform in those 3 countries.

We will only consider active groups. It means that a group should have at least 1 registered past or upcoming event. In the locations where multiple communities dedicated to the same cloud technology are present, only the biggest one will be considered because of the very high probability of members overlap between those groups.

The article gives only a snapshot of the situation as of April 12, 2020. The author doesn’t intend to update it as the situation changes. It’s a photo, not a video.

Cloud communities in France

France has a population of over 67 million people. It is one of the most important technological hubs of Europe (competing with Germany and England). Plenty of universities, industrial and service companies belong to the landscape of most of the cities in this country. Even small places can often have lively user groups here like in Brest, Tours or Cannes.

Analysis of Cloud Impact

As we can clearly see from the table, AWS has far away the biggest communities in France : it demonstrates a tendency to go on this Cloud Provider. This popularity is clearly brought from the location of one datacenter in Paris, France at the end of 2017.

Azure have broad community networks that cover the top 5 most populated cities. Azure is never the biggest community in the city.

Google Cloud groups (aka “GDG Cloud” chapters) have the weakest cloud community network in France among the 3 contenders. However, one should not forget the much wider network of general Google Developer Groups (abbreviated “GDG”), which also on occasions run Google Cloud themed meetups.

We can observe that Paris, Lyon and Nantes are the top 3 cities where the aws, azure and google cloud communities can enjoy events and meet together.

Lyon is quite particular : it’s the only city where Google Cloud has more members than the others Cloud communities.

This article highlights that cloud communities don’t match the top “La French Tech” cities. However, many cloud providers provide Cloud credits for Startups like this GCP initiative: check this page to redeem it.

There are some large cities in the country like Montpellier, Bordeaux or Lille and a couple more, where none of Azure or Google Cloud have community footprints. These are opportunities for the future to grow.

What about GDGs?

GDGs, Google Developer Groups, are too general to be studied in this article but GDGs bring together tons of passionate developers in France : 4134 members for GDG Paris, 2360 for GDG Nantes, 2213 for GDG Lille and 2133 for GDG Toulouse.

These numbers are boosted by the organization of a DevFest each year, a day or 2-days conference dedicated to share about the technology and its impact. And GDGs run some Cloud events sometimes, please check out the listing of GDGs here.

Disclaimer

Author of this article runs voluntarily the Google Cloud developer group in Nantes (France) and also the GDG Cloud Nantes.

He’s also a GDE Cloud, a community reward from Google Cloud. His opinions were intended to be honest and unbiased. Apart from this research, the following official sources were used: AWS, Azure & Google Cloud.

Thanks to Karen Tamrazyan & Charles-Henri Guérin for the review of the article.

Awesome Remote Work

Julien Landuré — Tue, 17 Mar 2020 14:45:07 +0000

I discovered the book "Remote" written by David Heinemeier Hansson and Jason Fried in 2014 when I joined Zenika.

Since then, I love to read books on the basecamp culture like "Rework" or "It Doesn't Have to Be Crazy at Work".

With the arrival of COVID-19, I decided to create a list of relevant links to share the culture from "remote" companies to everyone.

☁️ Company Culture

Since the beginning of Zenika, there is a "Cloud-first" culture:

Gsuite for collaboration
GitHub for code
Slack for 1-to-1 communication
Workplace for streamline communication
SaaS tools for HR, for Sales

All of these tools seem to be "normal" to be used inside our company and every employee has the right to be in remote when they wish (and notify your manager).

🏠 The path to become a remote company

We are an IT Services company so we share our people skills to our customers to build and deliver software.
To keep our own culture safe, my manager has found a cool way to make people work all together: everyone on Friday will not stay in the customer office. He encourages employees to stay remote (from our own office or from their home).

First reaction from our customers: they were not able to work remotely. So we helped some of them to adopt a remote culture with the associated tools.

⏰ The "COVID-19" effect

With the arrival of the Coronavirus disease, some of them didn't take the right patterns and even worse, a few of them panics.

To empower the remote culture, I just compiled a list of great articles on "How to remote work?" creating an awesome repository on GitHub.

// Detect dark theme var iframe = document.getElementById('tweet-1239515937193238528-84'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1239515937193238528&theme=dark" }

💚 Open source

The repository is open-source and inspired by the awesome lists from sindresorhus.
I've added a specific README for 🇫🇷 french advices and links.
If you wish to contribute for your own country, you're welcome! 🙌

🚀 Feel free to share your links!

How to backup your Firestore data automatically

Julien Landuré — Thu, 01 Aug 2019 16:15:03 +0000

With my team, we use a lot of Firebase features like Firestore.

But there is no simple way to backup the data regularly.

We created a tiny Docker image zenika/alpine-firestore-backup and this simple tutorial to perform backups automatically on the Google Cloud Platform with Serverless services like Cloud Run and Cloud Scheduler.

Step1: Create a bucket on GCP

Create a GCP coldline bucket and save the name of your bucket.

Step2: Create a service account

Create a GCP Service account with the following rights:

Owner
Cloud Datastore Owner
Cloud Datastore Import Export Admin
Storage Admin

Then, download the JSON private key file.

Step3: Create your env variables for Cloud Run

Please fill in the following information:

GCLOUD_PROJECT_ID
GCLOUD_BUCKET_NAME
GCLOUD_SERVICE_KEY

For the GCLOUD_SERVICE_KEY, make a base64 encoded string using this command:

cat key.json | base64

Step4: Set up Cloud Run

Cloud Run is a serverless service to automatically serve your containers using http.

Create a Cloud Run service using the public image gcr.io/zenika-hub/alpine-firestore-backup.

Be careful to:

Choose your newly image in latest
Choose "Cloud Run (fully managed)" and a location
Enter a service name
Select "Allow unauthenticated invocations"
In the "Show optional settings / Environment variables", set the 3 environment variables seen in the previous section

You can test the service using your browser: https://alpine-firestore-backup-XXX-run.app/

Save the url created to call your Cloud Run Service.
For example: https://alpine-firestore-backup-XXX-run.app/backup

Step5: Launch with Cloud Scheduler

Cloud Scheduler allow you to schedule a cronjob in order to call a https endpoint at regular intervals.

Prepare a Cloud Scheduler to send a request to your Cloud Run Service every time you need.

For example, every Monday at 3:00am 0 3 * * 1 a backup will be done and stored in your bucket.

Step6: Monitor the backup operations

You can also check the current status of each backup operation using the following url https://alpine-firestore-backup-XXX-run.app/list

Conclusion

Feel free to have a look at the Docker image we created for this operation here on github or here on dockerhub.

We also have others images we maintained like a popular and small Chromium Headless image called zenika/alpine-chrome.

DEV Community: Julien Landuré

Google Antigravity & Gemini 4 Argon: How to Load Your Global ~/.agents Skills

📦 1. How the Agent Skills standard organizes your skills

❌ 2. Attempt #1: Why ~/.gemini/config/skills.json fails

⚡️ 3. Attempt #2: Link ~/.gemini/config/skills to ~/.agents/skills

🧹 4. Bonus: Clean up ~/.gemini when coming from Gemini CLI

🎯 Conclusion

🎓 Go further with Antigravity

Opus génère ma vidéo de motion design en 20 minutes

🎯 Le but : une vidéo pour nos formations Claude Code

💬 Le prompt

⚙️ Sous le capot : comment Claude a travaillé

1. Rassembler la matière

2. Choisir une technique : la vidéo comme une fonction du temps

3. Construire un storyboard calé sur le rythme

4. Les techniques d’un motion designer

5. Le son, synthétisé de A à Z

6. Le rendu : Chrome headless et ffmpeg

7. Se relire avant de livrer

🔁 Une correction, trois secondes re-rendues

📣 Ce que ça change pour le marketing

🎯 Conclusion

🎓 Aller plus loin avec Claude Code

Gouvernance MCP : qui choisit les tools de vos agents de code ?

📌 Les trois besoins de gouvernance

Rappel : registry et managed settings pour le besoin A

1️⃣ Solution 1 : le filtrage proposé par l’éditeur

Pourquoi cette approche est fragile

2️⃣ Solution 2 : une gateway MCP entre les agents et les serveurs

Les limites de la gateway

3️⃣ Solution 3 : choisir les tools dans chaque agent de code

⚖️ Comparatif des trois solutions

🎯 Conclusion : il manque une brique dans la spec MCP

🎓 Aller plus loin avec MCP

My first talk at AWS Summit Paris: steer your code agents with Kiro

A packed Developer Community Zone

Don’t code alone, steer your agents

Spec-Driven Development in Kiro

Practices of the Augmented Developer

The feedback that made me smile

What I take from this first Summit talk

Your Face on a World Cup Sticker: Our Nano Banana Story

⚽ 1. The idea: putting our own faces on the stickers

✍️ 2. One prompt engine, dozens of scenarios

👕 3. When the AI remembered the wrong jerseys

🍌 4. Moving from Nano Banana 1 to Nano Banana 2

🚀 5. From a side project to real API limits

🎯 Conclusion: now create your World Cup sticker

How to celebrate an achievement as an open source developer?

Crafting the perfect container to play with a Headless Chrome

Julien Landuré for Zenika ・ May 26 '20

🎯 What can I do to celebrate this achievement?

🎉 What else?

⏱ 3 minutes to deploy your static Nuxt.js app on AppEngine

📝 Getting started with Nuxt.js

⚗ Create the project

✅ Test locally

🏗 Build it

☁️ Deploy it on AppEngine

🛒 Create a project

✏️ Write the descriptor app.yaml

🚀 Deploy your app

🎉 Enjoy

🔍 Conclusion

Crafting the perfect container to play with a Headless Chrome

🤔 Why use a Headless Chrome

Create PDFs with Node.js and Puppeteer

David Neal ・ Feb 6 '20

💡 Crafting the perfect container

💚 Open Source & Fun

🚀 Reaching a point

🗓 The Future

State of Cloud Communities in France

Comparison

Cloud communities in France

Analysis of Cloud Impact

What about GDGs?

Disclaimer

Awesome Remote Work

☁️ Company Culture

❌ 2. Attempt #1: Why `~/.gemini/config/skills.json` fails

⚡️ 3. Attempt #2: Link `~/.gemini/config/skills` to `~/.agents/skills`

🧹 4. Bonus: Clean up `~/.gemini` when coming from Gemini CLI

Gouvernance MCP : qui choisit les tools de vos agents de code ?

✏️ Write the descriptor `app.yaml`