SMF·SHORTCUT
Un prompt peut-il remplacer Shortcut ?
Gestion de projet — issue tracking for software teams
Bordereau de suivi des pièces
Verdict
Shortcut est un tracker pour les gens qui vivent dans un terminal, et son unique comportement indispensable, c’est la boucle git : un nom de branche porte l’identifiant de la story, la pull request se lie elle-même, et le merge déplace la carte. Cette boucle, c’est un week-end contre les webhooks d’un hébergeur git. Ce que tu perds, c’est tout le social autour — l’application mobile, les intégrations, et le fait que d’autres personnes se donnent la peine de le mettre à jour — ce qui est la raison ordinaire pour laquelle un tracker auto-hébergé pour une équipe meurt silencieusement.
Pièce A — Le prompt
Reçu le31.07.2026Construis un tracker de tickets dont les stories sont mises à jour par git, pas à la main.
Stack : ton choix, Postgres, Docker Compose. Connecte-toi à ton hébergeur git avec une application OAuth et un webhook — GitHub est la référence ; note dans le README ce qui change pour GitLab.
Modèle : Story (id, titre, description, type feature/bug/tâche, état, estimation, responsable, étiquettes), Epic (un groupe nommé de stories avec une complétion calculée), et Itération (une fenêtre datée contenant des stories).
La boucle git, qui est tout l’intérêt :
- Chaque story expose un nom de branche suggéré contenant son id, copiable en un clic, dans un format documenté comme nom/sc-123-titre-court.
- Sur un webhook de création pour une branche correspondant à ce motif, déplace la story vers En cours et enregistre la branche.
- Sur un webhook de pull request référençant l’id dans la branche ou le titre, attache la PR avec son état et son lien, et déplace la story vers En révision.
- Au merge dans la branche par défaut, déplace la story vers Fait et enregistre le commit de merge. À la fermeture d’une PR sans merge, remets-la En cours et dis pourquoi dans le journal d’activité.
- Chaque transition automatique est journalisée comme automatique, avec l’événement webhook qui l’a causée, pour qu’un changement d’état inattendu soit traçable.
- Vérifie la signature du webhook et rejette tout ce qui n’est pas signé. Un point d’entrée webhook ouvert laisse n’importe qui déplacer tes stories.
Itérations : dates de début et de fin, stories assignées dedans, et un graphique de burndown construit à partir d’instantanés quotidiens stockés de l’estimation restante plutôt que recalculé depuis l’état actuel — recalculer te donne un graphique qui réécrit sa propre histoire chaque fois qu’une story est réestimée.
Un rapport : temps de cycle par story de En cours à Fait, comme une distribution plutôt qu’une moyenne, parce que la moyenne cache les deux stories qui ont pris un mois.
Ajoute aussi : un tableau kanban, une recherche pilotée au clavier avec une syntaxe de requête (state:, owner:, label:, epic:), et un export CSV.
Écris des tests pour l’analyse de nom de branche incluant des titres avec des traits d’union et des chiffres, pour la fermeture de PR qui inverse l’état, pour le rejet de signature, et pour les instantanés de burndown idempotents par jour.
Ne construis ni applications mobiles, ni intégrations de chat, ni intégration d’outil de design.L’ouverture pré-remplit le prompt — il ne reste qu’à appuyer sur entrée.
Pièce B — Ce que tu perds
- B.1 les applications mobiles
- B.2 les intégrations maintenues vers le chat, la CI et les outils de design
- B.3 la disponibilité hébergée et les sauvegardes de quelqu’un d’autre
- B.4 la suite de reporting, y compris les tableaux de bord de burndown et de temps de cycle prêts à l’emploi
- B.5 que d’autres personnes l’utilisent, le vrai risque d’un tracker d’équipe auto-hébergé
Alternatives existantes
Pièce C — Pourquoi certains continuent de payer : git integration and team habit
Parce qu’un tracker n’est utile que si toute l’équipe le met à jour, et payer est le moyen le moins cher de faire de son maintien en fonctionnement, et d’un niveau d’agrément suffisant pour qu’on le fasse, le travail de quelqu’un d’autre.
Questions
Pourquoi construire le burndown à partir d’instantanés stockés ?
Parce qu’un graphique recalculé depuis l’état actuel change l’historique d’hier chaque fois qu’une estimation change, ce qui le rend sans valeur pour la seule chose à laquelle il sert — remarquer que tu ne vas pas finir. Une ligne d’instantané quotidien ne coûte rien.
Pourquoi rapporter le temps de cycle comme une distribution ?
Parce que la moyenne est dominée par les nombreuses petites stories et cache les deux qui ont pris un mois, et ces deux-là sont celles qui valent la peine d’en parler. Un histogramme ou des percentiles disent la vérité.
Que se passe-t-il si quelqu’un oublie l’id de la story dans le nom de branche ?
Rien d’automatique, ce qui est correct — le tracker ne devrait jamais deviner. Fais en sorte que le nom de branche suggéré se copie en un clic et l’omission devient rare ; deviner depuis le titre produit de mauvais liens, ce qui est pire que pas de lien du tout.
Shortcut exporte-t-il bien ?
Oui. L’API parcourt les stories, epics, itérations et commentaires, et il y a un export CSV dans l’interface. C’est l’un des trackers les plus portables de cette catégorie.
Outils proches
Récépissé