Cursor × Linear — fil par feature et conversations partagées¶
Définition¶
Doctrine de travail qui répond à une question : où doit vivre le contexte d'une feature quand on y revient plusieurs fois dans le temps, et comment le partager à plusieurs ? La réponse tient en un principe : le « fil par feature » n'est pas un chat IDE qu'on garde ouvert, c'est l'issue Linear elle-même et son Cloud Agent rattaché. Le chat de l'éditeur reste l'outil du travail solo profond, ré-hydraté à la demande ; le contexte durable et partageable vit dans Linear et dans le second cerveau.
Pourquoi on en parle¶
Question posée par Romain le 09/06/2026 : faut-il une conversation par feature Linear pour éviter de renourrir le contexte à chaque session, ouvrir Cursor depuis Linear (puisque la porte d'entrée est la todo donc Linear), et avoir des conversations partagées entre coéquipiers accessibles depuis Linear pour travailler à plusieurs ?
Cette page acte la réponse recommandée et sert de référence quand on voudra en faire un standard d'équipe.
État actuel (auto)¶
Dernière mise à jour : 2026-06-09
Le principe : deux endroits où vit une conversation¶
Dans Cursor, une « conversation » peut vivre à deux endroits qui répondent à deux besoins distincts. Confondre les deux est la source du malentendu.
| Endroit | Nature | Partage | Contexte qui dure |
|---|---|---|---|
| Chat de l'IDE (desktop) | Local, attaché au compte de l'utilisateur | Non partageable en live — seulement export read-only (Shared Transcripts) + fork | Mauvais support : un chat qui s'allonge traîne du contexte périmé, devient lent et coûteux |
| Cloud Agent rattaché à l'issue Linear | Tourne dans le cloud, lié à l'issue | Collaboratif par construction : tout coéquipier ayant accès à l'issue pilote le même agent | C'est le bon support : le contexte s'accumule sur l'issue, persistant et multi-personnes |
Réponses aux trois questions¶
« Une conversation par feature pour ne pas renourrir le contexte » — bonne idée dans l'esprit, mais à ne PAS matérialiser par un méga-chat IDE éternel (il se dégrade). Le support de persistance, c'est l'issue Linear + le second cerveau. Vu le setup Bricks, le contexte durable vit déjà là : le workflow workflow BRI-XXX relit le ticket via le MCP Linear à chaque lancement (workflow-agent-linear, skill workflow-2.0). On re-rentre dans le contexte à bas coût à chaque session, sans entretenir un fil qui pourrit.
« Plus logique d'ouvrir Cursor depuis Linear » — oui pour le mode cloud : mettre Cursor en assignee de l'issue, ou écrire @Cursor en commentaire, lance un Cloud Agent lié à l'issue (statut temps réel dans Linear + PR auto). En revanche il n'existe pas de bouton natif « ouvrir l'IDE desktop avec le contexte de l'issue préchargé ». La passerelle existe dans l'autre sens : un agent lancé depuis Linear peut être rapatrié en local dans l'Agents Window pour itérer, puis renvoyé au cloud.
« Conversations partagées entre utilisateurs accessibles depuis Linear » — oui, c'est exactement le Cloud Agent sur l'issue. Chaque commentaire @Cursor est envoyé en follow-up au même agent avec son contexte accumulé ; plusieurs personnes peuvent le piloter. Pour un chat IDE, le partage existe mais reste read-only + fork (les Shared Transcripts) : un coéquipier voit l'historique et peut le forker dans son propre éditeur — ce n'est pas de l'édition live à plusieurs.
Recommandation Bricks¶
- Le « fil par feature » = l'issue Linear + son Cloud Agent, pas un chat IDE. C'est ce qui est partageable, persistant et multi-personnes.
- Le chat IDE reste pour le travail solo profond, ré-hydraté à la demande via
workflow BRI-XXX(le contexte durable est dans le ticket et le cerveau, pas dans le fil). - Articulation avec le pipeline autonome : à ne pas confondre avec le workflow agent autonome Linear → Code → GitHub (3 agents Claude Code, cron, PR auto, zéro conversation, specs sans ambiguïté). Ici on parle d'un agent interactif et collaboratif piloté par des humains via commentaires.
Prérequis et limites à lever avant d'en faire un standard¶
- Prérequis : plan Cursor payant ; un admin connecte l'intégration Linear au workspace ; GitHub connecté pour les PR. Les Shared Transcripts ne sont dispo qu'en plan Teams/Enterprise.
- À tester avant standardisation
[à valider]: ré-mentionner@Cursorpeut parfois assigner un nouvel agent plutôt que continuer l'existant ; et la reprise d'un agent terminé depuis plusieurs jours n'est pas documentée noir sur blanc côté Cursor. Vérifier le comportement sur une vraie issue avant d'en faire une convention d'équipe. - Limite : pas d'édition live collaborative de la même conversation IDE (le fork crée une copie). Le vrai « à plusieurs sur le même fil » passe par le Cloud Agent sur l'issue.
Concepts liés¶
- workflow-agent-linear — pipeline autonome (non interactif) Linear → 3 agents → PR auto ; cette page en est le pendant interactif/collaboratif
- conventions-linear-bricks — doctrine initiative/projet/issue ; l'issue est aussi le support de contexte par feature
- ai-coding-vibe-coding — cadre IA dans le dev ; un Cloud Agent reste soumis à la matrice N1/N2/N3
Areas impactées¶
- areas/tech — workflow de dev, intégration Linear → Cloud Agent
- areas/produit — la porte d'entrée reste la todo / Linear
Ressources externes¶
- Cursor — intégration Linear (assignee
Cursor,@Cursor, statut temps réel, PR auto) - Cursor — Cloud Agent (anciennement Background Agent ; points d'entrée Web/Desktop/Slack/GitHub/Linear/API)
- Cursor — Agents Window (handoff cloud ↔ local)
- Cursor — Shared Transcripts (partage read-only + fork, Teams/Enterprise)
- Cursor — Deeplinks (ouvrir l'IDE avec un prompt pré-rempli, hors contexte Linear)
Sources¶
- Question Romain en session 2026-06-09 (fil par feature / ouvrir Cursor depuis Linear / conversations partagées).
- Recherche documentation Cursor en session (intégration Linear, Cloud Agent, Shared Transcripts, Agents Window, Deeplinks) — cf. liens Ressources externes ci-dessus.