SF ShipGlows
Menu Ouvrir le menu de navigation Fermer le menu de navigation

Pour les fondateurs solo qui livrent avec des agents

L’IA a accéléré la construction. Elle a aussi rendu les mauvais passages de relais plus coûteux.

ShipGlows donne à chaque exécution d’agent une carte de contexte, un contrat de tâche, un niveau d’exigence, des portes de vérification et les contrôles serveur nécessaires pour livrer de vrais projets. Le but n’est pas de faire aller les agents plus vite à tout prix. Le but est d’arrêter de confier du travail sérieux à un fil vide en espérant qu’il reconstruise correctement le système.

  • les nouveaux agents partent d’une carte connue, pas de résidus de chat
  • le travail non trivial est cadré avant le code
  • les raccourcis passent après la correction, la sécurité, la maintenabilité et la preuve
Sans système Même explication du dépôt, prompt vague, sortie assurée, docs périmées.
Avec ShipGlows Point d’entrée, carte de contexte, tâche cadrée, contrat qualité, boucle de vérification.
Livraison réelle Environnements Flox, processus PM2, routage Caddy, accès SSH.
Une seule couche opérationnelle pour le travail écrit par l’IA et les systèmes qui l’exécutent.

Pourquoi ShipGlows existe

Le problème n’est plus de taper du code. C’est de diriger le système autour.

L’IA peut échafauder rapidement les parties faciles. Le plus difficile est de décider ce qui mérite une solution professionnelle, de fournir le bon contexte, de détecter les dérives et de garder le chemin de déploiement relié à la promesse faite.

Le contexte devient une infrastructure

Un nouveau fil reçoit un point d’entrée, une carte opérationnelle et des contrats explicites au lieu de reconstruire la même histoire de mémoire.

La planification précède le prompt

Les specs, les vérifications de préparation et les limites de tâche transforment une demande floue en travail exécutable sans deviner le produit.

La qualité passe avant le chemin le plus court

Le choix du modèle, le routage, l’implémentation et la vérification optimisent la correction, la sécurité, la maintenabilité, la performance utile et la preuve avant la vitesse ou la commodité.

La revue a quelque chose à tester

La vérification n’est pas de l’optimisme après un build vert. Elle contrôle le comportement, les docs et les dérives de contrat face à ce que le travail devait changer.

Le chemin serveur reste dans la boucle

ShipGlows garde aussi la réalité opérationnelle visible : environnements, processus, tunnels, publication, santé et état serveur autour de la livraison réelle.

La boucle agent

ShipGlows couvre le travail autour de l’agent, pas seulement le prompt envoyé.

La question utile n’est pas de savoir si l’IA peut écrire du code. Elle le peut. La question utile est de savoir si votre système peut diriger, inspecter, exécuter et expliquer ce travail sans récompenser le chemin fragile le plus rapide.

01

Cadrer le travail avant le départ de l’agent

Transformer une demande floue en contexte, périmètre, critères d’acceptation et contraintes réellement suivables.

02

Choisir le chemin professionnel avant l’édition

Donner à l’agent la carte du dépôt, les contrats actifs, le niveau d’exigence, les docs pertinentes et les commandes opérationnelles avant qu’il modifie les fichiers.

03

Vérifier face à la promesse et au niveau d’exigence

Contrôler le comportement, les docs, les claims publics, les cas limites, la posture sécurité et l’impact workflow avant de considérer le changement terminé.

04

Livrer avec l’état serveur toujours visible

Garder les environnements, processus, tunnels, publications, états de santé et logs assez proches du workflow agent pour agir dessus.

Ce qu’est ShipGlows

Le modèle opérationnel autour du travail généré par IA.

L’IA peut produire du code plus vite que votre ancien processus ne peut l’absorber en sécurité. ShipGlows relie le workflow agent, les contrats de décision et le cycle de vie serveur pour que la sortie ait un cadre discipliné où atterrir.

Discipline de livraison pour agents

  • orienter vite un nouvel agent vers le bon contexte
  • cadrer le travail non trivial avant le code
  • vérifier face aux contrats plutôt qu’espérer
  • garder business, produit et docs traçables

Contrôle serveur pour livrer réellement

  • exécuter des environnements isolés avec Flox
  • gérer les processus et leur cycle de vie avec PM2
  • publier via Caddy et DuckDNS
  • utiliser tunnels, contrôles et opérations runtime sans bricolage

Comment l’ensemble reste cohérent

Chaque document a un seul rôle.

La documentation ShipGlows ne cherche pas à être encyclopédique. Elle est conçue pour orienter vite les agents, avec un rôle explicite et exclusif pour chaque artefact.

AGENT.md (compat) point d’entrée pour un nouvel agent
shipglows_data/* corpus de gouvernance local au projet pour les dépôts adoptés
shipglows_data/technical/context.md carte opérationnelle du dépôt
shipglows_data/technical/context-function-tree.md index structurel pour les grands fichiers procéduraux
shipglows_data/editorial/content-map.md où vit le contenu et comment il est réutilisé
shipglows_data/business/business.md pour qui, quelle valeur, quel modèle
shipglows_data/business/product.md quoi, workflows, non-objectifs
shipglows_data/branding/branding.md comment le produit s’exprime
shipglows_data/business/gtm.md comment le produit est présenté et distribué
shipglows_data/technical/architecture.md comment le système est organisé
shipglows_data/technical/guidelines.md comment contribuer dans le dépôt
shipglows_data/technical/decisions/project-governance-layout.md où doivent vivre les artefacts de gouvernance projet

Preuve, pas storytelling

Le mécanisme est visible avant d’acheter l’histoire.

ShipGlows ne devrait pas vous demander de croire des promesses d’automatisation vagues. La preuve est dans les fichiers, workflows, portes et opérations inspectables.

AGENT.md + contexte opérationnelsf-spec -> sf-ready -> sf-start -> sf-verifycontrat de qualité de décisiontemplates d’artefactslinter de métadonnées en bibliothèque standard Pythonskills de vérification et d’auditopérations PM2 + Flox + Caddy

Hypothèse tarifaire

Le modèle commercial reste ouvert. Le parcours d’achat doit rester simple.

ShipGlows est d’abord cadré pour les fondateurs solo. L’offre doit donc rester lisible, orientée autonomie et compatible avec un cycle de décision court.

Ajustement probable

Logiciel packagé, accès payant ou hybride léger avec setup et support. L’essentiel est un chemin simple pour fondateurs, pas une machine commerciale enterprise.

Ce qui compte d’abord

Positionnement fort, preuve visible, usage réel et raison claire de faire confiance au framework avant que la pression tarifaire devienne la question principale.

FAQ

Les questions évidentes, avec des réponses directes.

ShipGlows est-il un outil serveur ou un framework de workflow IA ?

Les deux. Le but est de garder la discipline d’exécution des agents et la livraison serveur dans un même modèle opérationnel cohérent.

Pourquoi ne pas simplement mieux prompter les agents ?

Parce que le mode d’échec principal n’est pas seulement la qualité du prompt. C’est le contexte perdu, les passages de relais faibles, l’ambiguïté silencieuse et la dérive entre docs, intention produit et implémentation.

ShipGlows optimise-t-il pour la vitesse ?

Seulement quand la qualité est sûre. Par défaut, la correction, la sécurité, la maintenabilité, la performance pertinente et la preuve passent avant la vitesse, le coût ou le chemin le plus court.

Faut-il toute la couche documentaire pour obtenir de la valeur ?

Non. Mais les docs deviennent plus précieuses à mesure que le travail devient moins trivial. Le framework est conçu pour qu’un nouvel agent s’oriente vite sans reconstruire le même contexte depuis zéro.

Comment fonctionnent vraiment les arguments de skills ?

Certains skills traitent l’argument comme du texte de tâche, d’autres comme un commutateur de mode ou une entrée structurée. Le comportement est défini par le contrat du skill, pas deviné depuis son nom.

Est-ce un PaaS généraliste ?

Non. ShipGlows ne cherche pas à abstraire tous les modèles d’hébergement. C’est un framework pratique pour exécuter et livrer de vrais projets tout en guidant plus strictement la livraison assistée par IA.

Entrée documentation

Commencez par les docs qui font réellement avancer le travail.

Pour comprendre ShipGlows vite, partez de la couche de routage et de contexte, puis suivez le workflow et les contrats de décision.

Comprendre les arguments de skills avant de deviner le workflow

Les skills ShipGlows n’interprètent pas tous les arguments de la même façon. Certains décrivent une tâche. D’autres changent entièrement le chemin d’exécution.

Lire l’aide au lancement

Traiter l’utilisateur comme un founder

Quand la conversation est orientée business, l’agent doit viser des décisions utiles, la croissance et la clarté plutôt que la dérive technique.

Lire le tag founder

Traiter ShipGlows comme un actif de portefeuille

Quand la conversation concerne ShipGlows ou ses actifs adjacents, l’agent doit raisonner en propriétaire et arbitrer au niveau portefeuille.

Lire le tag ShipGlows-owner

Commencer par les questions directes

Pour une entrée plus courte que la vue d’ensemble des docs, la FAQ répond aux questions récurrentes sur le workflow, la documentation et ce que ShipGlows cherche vraiment à résoudre.

Ouvrir la FAQ

Recentrer l’IA avec des tags simples

Vous n’avez pas toujours besoin d’un nouveau prompt. Un petit pack comme #offer #cta #clarity recentre plus vite la conversation.

Ouvrir la cheatsheet tags

Commencer ici

Si vos agents vont vite mais que vos passages de relais perdent le contexte, commencez ici.

Commencez par le dépôt, lisez les docs comme des contrats de travail et inspectez comment ShipGlows transforme contexte, exécution, vérification et opérations serveur en système pratique.