Rechercher des Issues Jira

Synthétisez l'information, ne concaténez pas les résultats des outils. Chaque étape ci-dessous collecte des données brutes — la valeur de cette compétence réside dans la connexion des points entre les issues, docs et commentaires pour construire une compréhension cohérente qu'un humain peut exploiter.

Workflow

Étape 1 : Récupérer l'Issue Principale

Utilisez l'outil MCP get_issue avec la clé de l'issue. L'outil étend par défaut renderedFields et names, ce qui fournit les champs rendus en HTML et les noms d'affichage lisibles des champs personnalisés.

Extrayez et notez :

Type d'issue (Epic, Story, Task, Bug, Sub-task, etc.)
Résumé et description
Statut et priorité actuels
Assigné et rapporteur
Champs clés pour comprendre le travail (labels, composants, sprint, etc.)
Commentaires qui fournissent un contexte important (clarifications des parties prenantes, décisions techniques, guidance d'implémentation)
Champs personnalisés : Surfacez tous les champs personnalisés non-nuls de la section Additional Fields de la réponse. L'expansion names mappe automatiquement les IDs de champs à des noms d'affichage lisibles.

Étape 2 : Identifier Toutes les Issues Liées

Examinez la réponse de l'issue principale pour identifier les issues liées via :

Issue Links : Cherchez le champ issuelinks dans la réponse API (un champ d'array non typé retourné par Jira) contenant :
- Relations Blocks/Blocked by
- Relations Depends on/Dependency
- Liens Relates to
- Relations Clones, Duplicates, Supersedes
- Tout autre type de lien
Liens Hiérarchiques : Cherchez :
- Issue parent (si c'est une sous-tâche)
- Epic link (si elle est liée à une epic)
- Sub-tasks (si cette issue a des sous-tâches)
- Projets next-gen : Si le type d'issue est Epic ou Feature et que subtasks est vide, utilisez l'outil MCP search_issues avec JQL parent = <ISSUE-KEY> pour découvrir les issues enfants. Les projets Jira next-gen utilisent les relations parent à la place du champ subtasks.
Remote Links : Utilisez l'outil MCP get_issue_remote_links avec la clé de l'issue pour trouver :
- Pages Confluence liées (groupées sous "Confluence Pages" dans la sortie)
- Pull requests et commits (groupés sous "GitHub")
- Documentation externe et autres ressources

Étape 3 : Récupérer les Issues Liées avec Contrôle de Profondeur

Récupérez les issues connexes pour construire le contexte, mais arrêtez-vous avant que les retours diminuent. Chaque saut supplémentaire ajoute des appels API et de l'utilisation de context window tout en fournissant des informations moins directement pertinentes.

Ordre de Priorité :
- Haute Priorité : Blocks, Depends on, Parent, Epic Link — ils déterminent si le travail peut commencer et où l'issue s'inscrit dans la hiérarchie
- Priorité Moyenne : Sub-tasks, Related issues — ils définissent la portée et fournissent du contexte
- Basse Priorité : Clones, Duplicates — uniquement s'ils fournissent un contexte unique non trouvé ailleurs
Contrôle de Profondeur :
- Traversez jusqu'à 2 niveaux au-delà de l'issue principale (issue principale -> issue liée -> un saut supplémentaire pour les liens haute priorité uniquement). Au-delà de 2 niveaux, la pertinence du contexte baisse fortement et le risque de gonfler la réponse augmente.
- Pour les issues référencées dans d'autres projets Jira via des URLs en ligne dans la description (ex. VULN-, SEC-), mentionnez la référence contextuellement mais ne la traversez que si elle apparaît comme un lien formel d'issue (blocks/depends-on/relates-to). Les références inter-projets en ligne sont informatives, pas des signaux de dépendance.
- Tracez les clés d'issues récupérées pour éviter les références circulaires (A lie à B, B lie à A)
- Pour chaque issue liée, utilisez l'outil MCP get_issue et extrayez les informations clés
Récupération Sélective :
- Pour les sous-tâches : Récupérez tout pour comprendre la portée complète du travail. S'il y a plus de 10 enfants, récupérez les 10 premiers et résumez le reste sous forme de liste compacte (clé, statut, résumé) à partir des résultats de recherche.
- Pour les issues bloquantes : Récupérez pour comprendre les dépendances
- Pour les issues connexes : Récupérez si elles semblent critiques pour la compréhension
- Ignorez les issues dupliquées/clonées sauf si elles contiennent une information unique
Rate Limiting : Espacez les requêtes lors de nombreux appels API. Après tous les 5 appels séquentiels, pausez brièvement (1 seconde) pour éviter de heurter les limites de débit d'Atlassian. Si vous rencontrez une réponse 429, attendez 10 secondes avant de réessayer.

Étape 4 : Récupérer la Documentation Confluence Liée

Les pages Confluence contiennent souvent des exigences, des docs de design ou des spécifications :

Extrayez les liens de pages Confluence de :
- Sortie de remote links (Étape 2 — liens groupés sous "Confluence Pages")
- URLs de description d'issue correspondant à */wiki/spaces/*/pages/*/
- URLs de commentaires pointant vers Confluence
Pour chaque lien Confluence :
- Extrayez le pageId de l'URL (ex. https://domain.atlassian.net/wiki/spaces/SPACE/pages/123456789/Title -> 123456789)
- Utilisez l'outil MCP get_confluence_page avec l'ID de page
- Notez le titre de la page et les informations clés du contenu
Budget contexte pour les pages : Pour les pages Confluence de plus de 2000 mots, résumez les sections pertinentes pour l'issue plutôt que de reproduire la page complète. Concentrez-vous sur les exigences, critères d'acceptation, contraintes techniques et décisions de design.

Étape 5 : Gérer les Échecs Gracieusement

Si une récupération échoue, notez l'échec et continuez avec les données disponibles. Modes d'échec spécifiques :

404 sur une issue liée : L'issue a été supprimée ou déplacée. Notez la clé et passez.
403 sur une page Confluence : Pas d'accès. Notez le titre de la page à partir du remote link et passez.
404 sur remote links : L'endpoint peut ne pas être disponible. Passez et fiez-vous aux issue links de la réponse principale.

Signalez toujours quels éléments n'ont pas pu être récupérés à la fin de la synthèse.

Étape 6 : Synthétiser et Présenter

Organisez toutes les informations rassemblées en une compréhension complète :

Vue d'ensemble de l'Issue

Quel est l'objectif principal de cette issue ?
Quel type de travail s'agit-il (nouvelle fonctionnalité, correction de bug, tech debt, etc.) ?
Statut actuel et qui y travaille

Exigences et Contexte

Quelles sont les exigences clés ou critères d'acceptation ?
Quel problème est en cours de résolution ?
Quelle documentation soutient ce travail ?
Affichez tous les champs personnalisés non-nuls sous leur nom d'affichage comme titre, en rendant le contenu en markdown

Dépendances et Relations

Quelles issues doivent être complétées en premier (dépendances bloquantes) ?
Quelles issues cette issue bloque-t-elle (impact en aval) ?
Comment cela s'inscrit-il dans l'epic ou le projet plus large ?

Portée du Travail

Quelles sous-tâches existent ?
Quel est le découpage du travail ?
Y a-t-il des issues connexes qui fournissent un contexte supplémentaire ?

Insights Clés

Décisions techniques ou contraintes des commentaires/documentation
Risques ou préoccupations mentionnés
Contexte historique important (pourquoi ceci a-t-il été cloné, qu'a-t-il remplacé, etc.)

Budget Contexte

Quand la synthèse complète dépasse environ 4000 mots (grossièrement le point où les lecteurs commencent à parcourir plutôt qu'à absorber), condensez les issues liées de priorité inférieure (Related, Clones, Duplicates) en résumés d'une seule ligne avec clé, statut et résumé uniquement. Limitez les commentaires affichés aux 3 plus récents sauf si l'utilisateur en demande plus.

Exemples

examples/deep_read_workflow.md

Walkthrough complet pour une deep read d'une Story avec des sous-tâches, des issues bloquantes et de la documentation Confluence liée.

researching-jira-issues