AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Autonomous Learning Os

skill-gquthier-autonomous-learning-os-autonomous-learning-os · by gquthier

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.

No reviews yet
0 installs
0 views
view→install

Install

$ agentstack add skill-gquthier-autonomous-learning-os-autonomous-learning-os

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets Used
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-gquthier-autonomous-learning-os-autonomous-learning-os)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
7d ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Autonomous Learning Os? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

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 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, neonctlet 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.

  1. 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.

  1. 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.

  1. PRACTITIONER alimente les exercices de transfert et les études de cas.
  2. Écris app/content/curriculum.json.
  3. Valide : node scripts/validate-curriculum.mjs. Corrige jusqu'au vert.

Phase 3 — Le montage

bash scripts/01-scaffold.sh          # prépare app/, .env.local, .data/
cd app && npm install

Puis, selon les réponses :

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 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 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.

  1. Ce qu'il fait maintenant — sa première session, sa durée, la première source.
  2. Ce qui reste optionnel — Telegram s'il a dit non, la DB s'il est en fichier,

le déploiement Vercel.

  1. 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.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.