# Autonomous Learning Os > Construit à l'utilisateur son propre dashboard d'apprentissage sur mesure — entretien de setup, deep research multi-agents sur son sujet, génération du curriculum, app Next.js au design BizOS, brief Telegram optionnel. À utiliser quand l'utilisateur veut apprendre un sujet sérieusement, se construire un cursus, ou lance ce repo. - **Type:** Skill - **Install:** `agentstack add skill-gquthier-autonomous-learning-os-autonomous-learning-os` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [gquthier](https://agentstack.voostack.com/s/gquthier) - **Installs:** 0 - **Category:** [Data & Analytics](https://agentstack.voostack.com/c/data-and-analytics) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [gquthier](https://github.com/gquthier) - **Source:** https://github.com/gquthier/autonomous-learning-os ## Install ```sh agentstack add skill-gquthier-autonomous-learning-os-autonomous-learning-os ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Autonomous Learning OS — skill de setup Tu conduis l'utilisateur de « je veux apprendre X » à un dashboard d'apprentissage qui tourne sur sa machine, rempli de sources réelles et vérifiées, en une seule conversation. **Ta contrainte absolue : à la fin, `npm run dev` doit afficher une app complète et fonctionnelle, sans qu'il reste une seule étape manuelle non annoncée.** Pas de placeholder, pas de « à toi de remplir », pas de curriculum d'exemple laissé en place. --- ## Phase 0 — Repérage (avant de parler) Fais ça en silence, avant la première question. Ça évite de demander ce que tu peux voir. ```bash bash scripts/00-detect-stack.sh ``` Le script écrit `.setup/stack.json` et affiche un résumé. Il détecte : - les runtimes : `node`, `npm`, `python3` - les CLIs de données : `supabase`, `railway`, `psql`, `neonctl` — **et si elles sont authentifiées** - les CLIs de déploiement : `vercel`, `gh` - les CLIs d'IA : `claude`, `codex` - les variables d'environnement d'API déjà présentes dans le shell Lis `.setup/stack.json` avant de poser la question 4 et la question 5. Si l'utilisateur a déjà `supabase` connecté, tu proposes Supabase en premier choix, pas en dernier. --- ## Phase 1 — L'entretien Six questions. Pose-les **une par une**, attends la réponse, rebondis. Ce n'est pas un formulaire : si une réponse est vague, creuse avant de passer à la suite. Utilise l'outil de question à choix multiples quand les options sont fermées (questions 4, 5, 6). Laisse la réponse libre pour 1, 2, 3. ### Q1 — Qu'est-ce que tu veux apprendre ? Ouverte. Ce que tu veux en sortir : - **Le sujet exact.** « L'IA » est trop large — tu veux savoir si c'est *entraîner des modèles*, *utiliser des LLM en produit*, ou *comprendre les fondations mathématiques*. Reformule et fais confirmer. - **Mono-sujet ou cursus ?** Un sujet unique donne un curriculum profond. Plusieurs matières donnent un cursus large. **3 à 5 matières actives est ce qui tient le mieux dans la durée** (cf. `docs/LEARNING-SCIENCE.md`) — dis-le, puis **construis ce qu'il demande**. Il n'y a pas de plafond : c'est son temps. - **Le format actuel.** Demande explicitement : *« Tu apprends comment aujourd'hui ? Vidéos, livres, cours en ligne, projets ? Qu'est-ce qui n'a pas marché ? »* Ça oriente la pondération vidéo / lecture / pratique de la recherche. ### Q2 — Où tu en es, et où tu veux aller ? - Niveau de départ, en concret : ce qu'il sait déjà faire, pas un « intermédiaire ». - **Le résultat visé doit être vérifiable.** « Comprendre la finance » ne l'est pas. « Lire un bilan et repérer trois signaux d'alerte » l'est. Reformule jusqu'à obtenir un critère observable — il devient l'objectif de sortie du curriculum. ### Q3 — Combien de temps par jour, sur combien de semaines ? - Minutes par session : 15 / 30 / 45 / 60 / 90 / 120 / 180. L'app calibre la séquence dessus. - Jours par semaine. - Horizon en semaines → détermine le nombre de modules à générer (compte ~1 module par 2 sessions). ### Q4 — Comment on branche l'IA ? Trois modes, décrits dans `docs/AI-PROVIDERS.md`. Propose-les dans cet ordre : | Mode | `AI_PROVIDER` | Ce que ça veut dire | |---|---|---| | **Ton agent** *(recommandé)* | `claude-code` | Aucune clé. L'app prépare le prompt de correction, tu le colles à ton agent, il corrige. Zéro coût marginal. | | **Ta CLI locale** | `cli` | L'app appelle `claude -p` ou `codex exec` sur ta machine. Détecté en phase 0. Zéro clé dans un fichier. | | **Ta clé API** | `api` | Anthropic ou OpenAI, ta clé, ton compte. Elle va dans `app/.env.local`, qui est git-ignoré. | **Ne propose jamais, et n'accepte jamais, une clé qui ne serait pas celle de l'utilisateur.** Ce repo ne fournit aucune clé. Si l'utilisateur choisit `api`, ne lui demande pas de te coller sa clé dans le chat. Dis-lui de l'écrire lui-même dans `app/.env.local`, ou fais-le écrire par une commande shell qu'il lance (le `!` prefix dans Claude Code). ### Q5 — Où stocker ta progression ? Regarde `.setup/stack.json` avant de proposer. | Option | Quand la proposer | Ce que fait l'agent | |---|---|---| | **Fichier local** *(défaut)* | Toujours disponible | Rien à faire. `app/.data/` est créé au premier écrit, git-ignoré. | | **Supabase** | Si `supabase` est installé **et** authentifié | `bash scripts/03-database.sh supabase` : crée/lie le projet, applique le schéma, écrit `DATABASE_URL`. | | **Railway** | Si `railway` est installé **et** authentifié | `bash scripts/03-database.sh railway` : provisionne Postgres, récupère l'URL, applique le schéma. | | **Postgres existant** | Si l'utilisateur a déjà une URL | `bash scripts/03-database.sh url` puis colle l'URL. | Le fichier local suffit pour un usage solo sur une machine. La DB sert dès qu'il veut la progression sur plusieurs appareils ou un déploiement. ### Q6 — Tu veux un brief Telegram ? Si oui : suis `docs/TELEGRAM.md` **avec lui**, pas à sa place. Il doit créer son bot chez `@BotFather` (tu ne peux pas le faire), récupérer le token, lui écrire un message, puis lancer `bash scripts/04-telegram.sh` qui résout le chat ID et teste l'envoi. Le message quotidien est **personnalisé sur son sujet** : le module du jour, la source exacte à ouvrir, la durée, et la question de rappel. Le template est dans `docs/TELEGRAM.md` — adapte-le à son domaine, ne renvoie pas un texte générique. --- ## Phase 2 — La deep research C'est ce qui fait la valeur. **Ne la saute pas, ne la remplace pas par ce que tu crois savoir.** Un curriculum écrit de mémoire contient des liens morts et des cours qui n'existent plus. Lis `research/PROMPTS.md` en entier, puis lance **quatre sous-agents en parallèle** avec le contexte de l'entretien (sujet, niveau, objectif, temps) : | Sous-agent | Mission | Modèle conseillé | |---|---|---| | `ACADEMIC` | Cours universitaires ouverts, manuels libres, papiers de référence, syllabi publics. | Sonnet 5 | | `VIDEO` | Chaînes et playlists, **avec segments horodatés** et durée réelle. | Sonnet 5 | | `PRACTITIONER` | Retours de terrain, études de cas, outils — étiquetés comme tels, jamais comme preuve académique. | Sonnet 5 | | `SYLLABUS` | L'ordre des notions : prérequis, dépendances, progression. Ne cherche pas de liens, structure. | Opus / GPT-5.x | Chaque sous-agent rend du JSON conforme à `research/curriculum.schema.json`. Écris les rendus bruts dans `.setup/research/.json` — ils servent de trace et permettent de relancer une seule branche si elle est faible. ### Les règles non négociables sur les sources Elles sont dans `docs/SOURCE-POLICY.md`. Les trois qui font échouer une source : 1. **Elle doit être gratuitement accessible.** Pas de certificat payant obligatoire, pas de paywall. Note l'accès dans `accessNote`. 2. **Elle doit être vérifiée.** Tu ouvres le lien. Si tu ne peux pas confirmer qu'il répond, tu ne le mets pas. `verifiedAt` porte la date du jour. 3. **Elle doit porter une raison.** `why` explique pourquoi *cette* source pour *cette* notion, à *ce* niveau. « C'est un bon cours » n'est pas une raison. Pour une vidéo, `segmentStartSeconds` et `minutes` définissent la capsule à regarder. C'est le cœur du produit : l'utilisateur ne regarde jamais 90 minutes par défaut, il regarde les 11 minutes qui portent la notion du jour. ### Fusion Tu fusionnes les quatre rendus : 1. `SYLLABUS` donne l'ordre des modules. 2. `ACADEMIC` et `VIDEO` remplissent les sources de chaque module ; en cas de doublon, garde la plus institutionnelle et mets l'autre en `alternatives`. 3. `PRACTITIONER` alimente les exercices de transfert et les études de cas. 4. Écris `app/content/curriculum.json`. 5. **Valide :** `node scripts/validate-curriculum.mjs`. Corrige jusqu'au vert. --- ## Phase 3 — Le montage ```bash bash scripts/01-scaffold.sh # prépare app/, .env.local, .data/ cd app && npm install ``` Puis, selon les réponses : ```bash bash scripts/02-configure.sh # écrit AI_PROVIDER, APP_NAME, LEARNING_SUBJECT bash scripts/03-database.sh # seulement si Q5 ≠ fichier local bash scripts/04-telegram.sh # seulement si Q6 = oui ``` ### Personnalisation visuelle L'app porte l'UX BizOS V9 (`docs/DESIGN.md`) : wallpaper plein écran, panneaux blancs à trait 1 px et ombre dure 5 px, Inria Serif, monochrome noir/blanc/gris. **Ne le remplace pas, et n'y réintroduis aucune couleur d'accent.** Ce qui se personnalise : - Le wordmark reste `BizOS × Learning`, avec le sujet de l'utilisateur en sous-titre (`NEXT_PUBLIC_LEARNING_SUBJECT`). - Le fond d'écran par défaut : `NEXT_PUBLIC_DEFAULT_WALLPAPER`. Les 12 fonds procéduraux livrés sont dans `app/src/lib/wallpapers.ts` — choisis-en un qui colle au domaine (`blueprint` pour l'ingénierie, `ledger` pour la finance, `synapse` pour les sciences cognitives…). - Les icônes de matières dans `curriculum.json` (`icon`) — un glyphe simple, jamais un emoji couleur : la V9 est monochrome. L'utilisateur peut changer de fond à tout moment depuis **Réglages → Apparence**, et déposer les siens dans `app/public/wallpapers/`. --- ## Phase 4 — La vérification (obligatoire) Tu ne déclares pas terminé sans avoir fait tourner ça : ```bash bash scripts/05-verify.sh ``` Il enchaîne : validation du curriculum, `npm test`, `npm run build`, démarrage du serveur, et un GET sur `/`, `/learning`, `/exercises`, `/reviews`, `/settings`. Puis **ouvre réellement l'app** et regarde-la. Si tu as un outil de navigation, charge `localhost:3000`, clique sur les cinq onglets, lance une vidéo, ouvre la galerie de fonds. Un build qui passe n'est pas une preuve que l'écran est correct. Enfin : ```bash bash scripts/check-secrets.sh ``` Aucun secret ne doit être committable. Si le script sort en erreur, corrige avant toute autre chose. --- ## Phase 5 — La remise Dis à l'utilisateur, en clair et court : 1. **Ce qui tourne** — l'URL, les cinq écrans, le sujet, le nombre de modules. 2. **Ce que la recherche a trouvé** — combien de sources, de quelles institutions, et la plus forte selon toi. 3. **Ce qu'il fait maintenant** — sa première session, sa durée, la première source. 4. **Ce qui reste optionnel** — Telegram s'il a dit non, la DB s'il est en fichier, le déploiement Vercel. 5. **Comment ça se met à jour** — relancer la recherche pour le module suivant, ou éditer `curriculum.json` à la main. Ne fais pas un rapport de 40 lignes. Il veut apprendre, pas lire ton compte rendu. --- ## Règles de conduite - **Une question à la fois.** L'entretien est ce qui rend le curriculum juste. - **Ne devine pas les sources.** Cherche, ouvre, vérifie. Un lien mort dans le livrable, c'est un échec. - **Ne partage aucune clé, ne demande aucune clé qui ne soit pas la sienne.** - **Ne laisse pas le curriculum d'exemple.** Si la recherche échoue, dis-le franchement et propose de relancer — ne livre pas l'exemple en prétendant que c'est sur mesure. - **Le français est la langue par défaut** de l'interface et du curriculum, sauf demande contraire. Les titres de sources restent dans leur langue d'origine. - **Le nombre de matières est SA décision.** Tu recommandes 3 à 5 actives, une fois, avec la raison. S'il en veut huit, tu construis les huit — proprement, sans y revenir et sans version dégradée. Un backlog est une option que tu proposes, jamais une limite que tu imposes. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [gquthier](https://github.com/gquthier) - **Source:** [gquthier/autonomous-learning-os](https://github.com/gquthier/autonomous-learning-os) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** yes - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-gquthier-autonomous-learning-os-autonomous-learning-os - Seller: https://agentstack.voostack.com/s/gquthier - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.