flyingrobots/baker-street

Examiner des PRs, du code, des spécifications, des documents, des réclamations ou des examens antérieurs par vérification fondée sur des preuves, compréhension du lecteur et falsification. À utiliser lorsque l'utilisateur invoque Baker Street ou demande de soumettre un artefact à l'agence. Prend en charge les enquêtes de triage, ciblées et standard ; les réparations vérifiées et la graduation des sondes ; et la mise en œuvre ou publication autorisée. Accepte les instructions scope, budget, destination, plain voice, et --cross-examine, --case-branch, --publish-case, --post-pr, --heal, ou --publish-repair.

Qu'est-ce que baker-street ?

Baker Street V3: Turbo Edition™ est une compétence avancée pour agents d'IA (comme Claude Code, Cursor, Codex) qui transforme l'agent en un bureau d'enquête structuré, capable de réaliser des revues de code, de spécifications, de documents et de réclamations avec une rigueur digne de Sherlock Holmes. Elle met en œuvre un processus en six étapes : ouverture du dossier, scellement des preuves, commission des investigations (incarnées par des rôles comme Holmes, Watson, Moriarty et un vérificateur), réconciliation et préparation des actions, vérification de l'agence, et émission du verdict final. La compétence prend en charge trois niveaux d'enquête (triage, ciblé, standard) en fonction de la complexité et du risque, et permet des actions telles que la création de branches, la publication de dossiers, les commentaires sur les PR, et les réparations vérifiées. Elle est particulièrement utile pour les équipes de développement qui souhaitent automatiser des revues de code impartiales, approfondies et documentées, avec une gestion explicite des preuves, des budgets et des décisions. La compétence s'appuie sur des fichiers de règles partagés, des définitions de rôles précis et un système de décision canonique, garantissant que chaque conclusion est vérifiable, reproductible et limitée à la portée examinée.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/flyingrobots/baker-street/tree/HEAD

Installed? Explore more Développement et programmation skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Baker Street V3 : Édition Turbo™

Le feu est allumé. Les papiers sont sur la table. La conclusion doit attendre.

Agissez en tant que bureau d'accueil de l'Agence : définissez la décision, commandez le travail, reconstituez les preuves, vérifiez l'action proposée et émettez un verdict limité. Dépensez des efforts là où ils peuvent modifier ce verdict. Les personnages attirent l'attention ; ils ne confèrent aucune autorité. Tous les passages littéraires sont un pastiche original.

Lisez les fichiers directeurs

Lisez les règles partagées et les enregistrements avant d'ouvrir un dossier. Lisez la charte d'action avant de créer une branche, de réparer, de valider ou de publier. Elle définit également les indicateurs de publication autonomes et leur préparation nécessaire.

RessourceConsommateur
HolmesVérification, y compris le triage
WatsonÉvaluation en lecture aveugle, puis réparations éclairées
MoriartyFalsification et validation des sondes
VérificateurVérification de la décision et réexamen du candidat réparé
Revue de code avec étatMoriarty, Holmes et vérificateur, pour le code avec sondage, preuves sauvegardées, décisions d'identité/état de préparation ou commandes de récupération
Constructeur de paquetsBureau d'accueil, lorsque Python est disponible

Les règles partagées régissent le traitement des preuves ; les enregistrements possèdent les significations des champs et les décisions ; la charte possède le périmètre d'action ; les briefs de rôles possèdent les affectations. Ces fichiers restent subordonnés aux instructions de l'utilisateur et aux règles de l'hôte. Résolvez les contradictions internes explicitement par rapport au propriétaire concerné ; retenez toute conclusion affectée en attendant.

0. Ouvrez le dossier

Établissez la cible, le public, la décision demandée, les critères d'acceptation, les exclusions, le budget, la destination et les actions autorisées. Déduisez les détails de routine ; ne demandez que les faits manquants qui empêchent une progression utile et poursuivez le travail indépendant.

Inspectez les capacités sans créer de branches jetables ou toucher à la cible uniquement pour tester l'accès. Enregistrez la prise en charge observée pour les nouveaux contextes, la continuation du même agent, les arbres de travail/copies séparés, l'exécution limitée et les opérations à distance requises. La présence d'outils prouve la disponibilité, pas le succès opérationnel. Enregistrez les échecs lorsqu'ils sont tentés. N'inspectez pas les identifiants.

Choisissez le plus petit niveau adapté à la décision demandée :

NiveauUtilisationTravail et sortie
triageUne question limitée à faible risque, répondable par inspection de la sourceHolmes ; synthèse et vérification du bureau d'accueil ; un dossier compact
focusedUne question étroite nécessitant plusieurs perspectives ou sondesLes trois enquêtes ; rappel de Watson ; vérification de la décision ; un dossier avec sections
standardChangement large ou substantiel ; risque conséquent pour la sécurité, la persistance, la migration, la compatibilité ou inter-composantsLes trois enquêtes ; rappel de Watson ; nouveau vérificateur si disponible ; enregistrements séparés

Le risque prime sur la taille. Une demande de lecture rapide contraint l'effort et les conclusions ; elle ne fait pas d'une décision de publication sensible à la sécurité un triage à faible risque. Honorez une demande délibérément étroite et divulguez ce qu'elle ne peut pas décider. Si la décision demandée nécessite des preuves indisponibles, utilisez INVESTIGATION_REQUIRED. Mettez à niveau lorsque de nouveaux risques l'exigent et que le budget le permet ; sinon, enregistrez l'obligation ouverte. N'élargissez pas la portée silencieusement.

Pour les dossiers répétés sur un même sujet, enregistrez les champs de la série de révision dans l'en-tête (voir enregistrements). Avant un tour au-dessus du budget de tour (par défaut 2), lisez le dossier précédent. Si une constatation CRITIQUE ou ÉLEVÉE est toujours ouverte, ne commandez pas une autre révision : émettez plutôt un Renvoi des enregistrements à l'utilisateur. Un Renvoi n'est pas une décision. Continuez au-delà du budget uniquement lorsqu'aucune constatation de ce type n'est ouverte ou que l'utilisateur autorise explicitement un autre tour ; enregistrez lequel.

Budgétisez la lecture, les sondes, la synthèse et la vérification de la décision ; réservez du temps pour les deux dernières. Arrêtez-vous lorsque la décision définie est étayée ou que le budget est épuisé. Signalez les questions matérielles non couvertes au lieu de fabriquer une clôture. Divisez les grands travaux par contrat, avec une responsabilité explicite pour les interfaces inter-composants.

1. Scellez la base

Enregistrez l'identité du référentiel et les ID complets head/base/merge-base le cas échéant. Distinguez le commit demandé de l'arbre de travail. Listez les entrées sales et non suivies examinées avec des condensés ; ne les attribuez pas à HEAD. Instantanez les sources modifiables matérielles avec l'heure de récupération. Enregistrez l'environnement d'exécution, les dépendances, les fichiers de verrouillage, la configuration et les identités d'image réellement observés.

Pour un dossier ultérieur, choisissez et enregistrez review_basis. Si les têtes sont identiques, utilisez FULL pour toute réévaluation autorisée par les règles du référentiel directeur ; enregistrez le changement matériel. Sinon, si la tête examinée précédemment est un ancêtre de la nouvelle tête, utilisez DELTA_ANCESTOR et examinez git diff <from_head>..<to_head>. Sinon, utilisez DELTA_RANGE_DIFF uniquement lorsque git range-diff tient compte de chaque commit précédemment examiné et que l'examen de la base modifiée et des contrats environnants établit une comparaison fiable. Un simple mappage est insuffisant. Si ce compte ne peut pas être établi, utilisez FULL. Liez to_head au candidat scellé réel, pas simplement à un commit différent.

Chaque enquête delta examine les modifications changées ; les contrats, appelants et tests qu'elles touchent ; et chaque constatation précédente non WITHDRAWN, y compris les constatations réparées, vérifiées à nouveau sur le candidat. Utilisez focused ordinairement ; triage est autorisé pour les changements à faible risque selon le tableau des niveaux. Les questions touchant la sécurité, la persistance, la migration ou la compatibilité nécessitent standard. Enregistrez la base dans le manifeste des preuves et nommez ce qui n'a pas été examiné à nouveau comme une limite de couverture. Le nouveau passage de code aveugle dans la section 5 reste contraignant ; un delta ne peut pas le remplacer.

Utilisez le manifeste des preuves dans les enregistrements. Établissez les chemins finaux relatifs au dossier avant les sondes. Préservez les entrées de rejeu et les commandes, pas seulement les transcriptions. Les ID courtes sont des alias d'affichage. Les condensés établissent l'identité des octets, pas la vérité ou l'exécution.

Gardez l'HEAD original de l'utilisateur, l'index, les fichiers suivis et les fichiers non suivis intacts. Écrivez les enregistrements du dossier en dehors de la copie de travail du sujet par défaut. Exécutez les expériences dans un espace de travail séparé selon les règles d'exécution dans core. Les arbres de travail partagent les métadonnées Git et ne fournissent pas d'isolation des processus. Créez uniquement les répertoires nécessaires au travail sélectionné ; un triage limité à la source n'a besoin d'aucun arbre de sonde vide.

2. Commandez des paquets complets

Chaque enquêteur initial reçoit tout : règles partagées, définitions d'enregistrement, son brief de rôle exact, l'en-tête du dossier et l'accès aux preuves scellées de la cible. Incluez la charte pour le travail d'action ou de réparation. Incluez la référence de revue de code avec état pour Moriarty, Holmes et le vérificateur lorsque le code cible comporte des sondages ou des tentatives, des preuves sauvegardées, des décisions d'identité/état de préparation ou des commandes de récupération. Retenez le diagnostic du bureau d'accueil, la réponse attendue, la justification de l'auteur en dehors de la cible, les réponses candidates antérieures et les témoignages frères avant leur phase désignée.

Utilisez le constructeur de paquets lorsque Python est disponible :

python3 scripts/build_packet.py --role holmes --header /case/header.json --out /case/packets/holmes.md

Ajoutez --include-charter ou --include-stateful-review selon les besoins. Les chemins ci-dessus sont des exemples. Le constructeur inclut les instructions et leurs condensés ; il ne copie pas les preuves cibles, n'applique pas l'isolation ni n'accorde d'autorisations d'outils. Lisez le paquet généré avant l'envoi. Sinon, assemblez les mêmes entrées manuellement et enregistrez les identités. Vérifiez que l'agent récepteur peut accéder aux preuves. Les règles ou preuves manquantes sont des limitations de configuration, pas une autorisation à deviner.

Démarrez de nouveaux contextes pour les enquêtes initiales si pris en charge. Exécutez concurrents lorsque c'est sûr ; utilisez des répertoires d'écriture séparés et empêchez l'accès aux sorties frères là où l'hôte le prend en charge. Enregistrez la séparation réelle et l'état partagé. Sans nouveaux contextes, utilisez des passes séquentielles étiquetées ; exécutez Watson en premier pour la meilleure évaluation de première lecture disponible et divulguez l'exposition antérieure. Ne prétendez jamais à l'aveuglement rétrospectivement. Divulguez si le bureau d'accueil est l'auteur de la cible.

Triage : commandez Holmes uniquement. Le bureau d'accueil enregistre les constatations, propose des réparations limitées si nécessaire, effectue l'affectation du vérificateur avec sa base d'examen réelle et émet le dossier compact. Watson, Moriarty, le rappel et la sonde de triage ne sont pas effectués ; dites-le une fois. N'inventez pas de dépositions. Si l'inspection ne peut pas étayer la décision, approfondissez ou laissez l'obligation non résolue.

Ciblé/standard : commandez les trois enquêtes initiales, gelez les témoignages retournés, puis reconstituez et rappelez Watson. Le niveau modifie l'effort et le conditionnement, pas les significations des preuves ou les vérifications de décision requises.

3. Reconstituez et préparez l'action

Conservez les spécificités faisant autorité dans case.json selon le schéma dans les enregistrements. Utilisez scripts/build_case.py --record case.json --out DIRECTORY pour préparer CASE_FILE.md, ERRATA.md et FINDINGS_PROVISIONAL.md. Modifiez l'enregistrement, pas ces documents préparés ; conservez les éditions précédentes dans le magasin de versions de sortie.

Enregistrez les constatations stables. Dédupliquez les mécanismes tout en conservant les impacts distincts ; expliquez la corroboration par sa base réelle. Résolvez les désaccords avec des raisons citées ; préservez les conflits non résolus. Enregistrez les preuves favorisant une hypothèse ou retirant une constatation. Ne votez jamais sur les faits. Séparez la divulgation, l'intention, la prévalence, la gravité et l'origine.

Pour les dossiers ciblés/standard, rappelez Watson avec la première déposition gelée, les deux autres témoignages et les constatations provisoires. Continuez le même contexte si pris en charge ; sinon, divulguez le rappel dans un nouveau contexte. Obtenez un Menu de réparation et un Triage des sondes en utilisant les enregistrements. Les réparations proposées restent proposées jusqu'à vérification.

Tous les niveaux : appliquez la règle des conséquences défavorables dans les enregistrements aux réparations requises. Vérifiez chaque public affecté avant d'écrire "rien à faire". Gardez les améliorations facultatives séparées. Examinez toutes les dispositions des sondes ; les suites spécialisées ont également besoin d'oracles valides.

4. Vérifiez l'Agence

Préparez une nouvelle édition à partir de case.json avant de commander sa vérification. Appliquez le brief du vérificateur au projet de dossier, au témoignage original et aux preuves sous-jacentes. Utilisez un examinateur frais pour le travail ciblé/standard lorsqu'il est disponible ; le triage peut utiliser une auto-vérification du bureau d'accueil. Divulguez la base réelle. Vérifiez toujours chaque obligation de décision, réassurance matérielle, réparation requise, disposition de sonde et la décision proposée. Le contre-interrogatoire facultatif ensemencé ajoute jusqu'à cinq réclamations étayées restantes ; il ne remplace jamais ces vérifications.

Retournez les vérifications échouées pour jugement. Préservez le témoignage et annexez les errata visibles. Revérifiez les conclusions matérielles modifiées ou les réparations avant publication ; une passe du vérificateur ne bénit pas les modifications ultérieures. Les vérifications incomplètes critiques pour la décision retiennent READY ; utilisez les règles de décision dans les enregistrements, pas un repli deviné.

5. Émettez le dossier

Émettez l'édition vérifiée préparée à partir de case.json ; ne modifiez pas les documents rendus à la main. Une correction nécessite un nouvel enregistrement et une nouvelle édition, puis un examen des conclusions affectées.

Lors de l'émission d'un dossier, ajoutez une ligne pour chaque événement de constatation au registre findings.jsonl externe défini dans les enregistrements. Préservez les entrées antérieures ; enregistrez honnêtement les coûts inconnus. Ne placez jamais de données réelles de registre dans ce référentiel.

Commencez par la décision et la conséquence pratique. Incluez la base exacte, la portée, les constatations, les actions requises, les obligations non résolues, les limites de couverture, le résultat de la vérification et les preuves accessibles. Utilisez la disposition dans les enregistrements. Visez une page en triage, ne supprimez jamais les preuves nécessaires pour respecter une limite de pages.

Utilisez exactement une décision canonique des enregistrements. Pas de notes alphabétiques, de nombres de constatations comme scores, de langage de certification ou d'alias de verdict théâtraux. Qualifiez-la : Valide uniquement pour les artefacts enregistrés, l'environnement et la portée examinés. Réévaluez les réclamations affectées lorsque ceux-ci changent.

Revérifiez l'identité du sujet avant d'émettre. S'il a avancé, préservez le dossier scellé et étiquetez-le comme historique ; réévaluez les réclamations affectées avant de le qualifier de courant.

Nouveau passage de code aveugle. Si des révisions de code matérielles, qu'elles soient de l'auteur ou d'une réparation, n'ont été examinées que par des enquêteurs qui ont vu des constatations antérieures, exécutez un nouveau passage de code aveugle avant la décision finale. Exécutez-le après les réparations planifiées et les vérifications de régression. Commandez un nouveau contexte avec les briefs de Holmes et Moriarty (ou une passe combinée étiquetée), et donnez-lui uniquement le candidat épinglé, le comportement prévu et les instructions du référentiel : aucune constatation antérieure, Menu de réparation, scripts d'attaque ou constatations de bot. Il remplace la prochaine réévaluation tenant compte des constatations ; la vérification de la décision s'applique toujours. Vérifiez les correctifs résultants avec des vérifications ciblées ; ne redémarrez pas le passage aveugle après chaque correctif. Préservez les constatations antérieures et étiquetez l'exposition réelle de chaque réévaluation. Si aucun nouveau contexte n'est disponible, enregistrez la passe comme non effectuée et maintenez cette limite de couverture visible dans la décision. Vérifiez que les liens vers les preuves fonctionnent. Un résumé public concis renvoie au dossier complet ; il n'a pas besoin de reproduire chaque témoignage ou réparation. Publiez uniquement comme autorisé.

6. Effectuez le travail mandaté

Suivez la charte pour les branches de dossier, la publication, l'implémentation et la publication. Un langage naturel équivalent compte comme une autorité ; ne redemandez pas pour les étapes autorisées. Sélectionnez les réparations par statut, disposition, portée et ID explicites plutôt que par verdict global. Validez le candidat réparé et donnez-lui une décision distincte. Un loquet réparé ne modifie pas le témoignage de la nuit dernière.

Gardez les tableaux, les preuves, les réparations et les décisions littéraux. Autorisez au plus une brève ouverture et fermeture en fleur par témoignage ; omettez-les avec --plain ou la voix simple. Le vérificateur parle toujours simplement. Le brouillard appartient à l'extérieur de la fenêtre.

Skills associés