PavedPath Code

Que fait PavedPath Code ?

PavedPath Code aide les agents à éviter de réinventer les solutions pour les problèmes de génie logiciel. Il recherche sur GitHub et dans les preuves open-source des chemins d'implémentation éprouvés, puis adapte le modèle le plus solide à la base de code locale avec des modifications minimales et vérifiables.

Utilisez GitHub comme source de preuves primaire, pas comme un simple dépôt de liens. L'objectif est de définir le problème local de code, de trouver des chemins déjà empruntés dans les dépôts publics, issues, pull requests, discussions, examples, notes de version et code source, d'évaluer la force de ces preuves, puis de traduire le modèle le plus solide en un correctif local mineur, un plan d'implémentation ou un plan de vérification.

Ceci est l'édition orientée code de PavedPath. Ne l'élargissez pas en un PavedPath généraliste. Elle est destinée au travail en génie logiciel : bugs, erreurs d'exécution, échecs de build/test/déploiement, problèmes de dépendances, utilisation de framework ou d'API, blocages d'intégration, modèles d'implémentation, sélection d'outils d'ingénierie et adaptation de solutions open-source.

Quand l'utiliser

• Erreurs d'exécution, de build, de test, de déploiement, de package, SDK, API, dépendance, framework ou d'intégration.
• L'implémentation d'une fonctionnalité est bloquée par un cas limite flou, un modèle d'utilisation manquant, un comportement de version ou un contrat d'API incertain.
• Un problème local ressemble à quelque chose que les mainteneurs ou d'autres utilisateurs open-source ont pu résoudre dans des issues, PRs, exemples, code, notes de version ou discussions.
• L'utilisateur demande si GitHub ou des projets open-source ont déjà résolu un problème d'ingénierie concret.
• Des exemples d'implémentation matures ou des projets réutilisables réduiraient l'incertitude pour une capacité spécifique.
• La réponse doit comparer des dépôts GitHub appropriés et expliquer comment adapter localement un chemin éprouvé.

N'utilisez pas PavedPath Code pour les corrections de copie, les refactoring purement locaux où la base de code dicte déjà la réponse, les décisions de vie non liées au code, les workflows de médias personnels, les méthodes d'étude, les décisions d'achat grand public ou les requêtes qui interdisent explicitement la recherche web/GitHub. N'inspectez pas les dépôts privés sauf si l'utilisateur autorise et délimite explicitement cet accès.

Workflow par défaut

1. Cadrez d'abord le problème local de code. Capturez l'objectif, le symptôme, la signature d'erreur, le chemin de reproduction, les versions, l'environnement d'exécution, les noms des dépendances/frameworks, les changements récents, les contraintes et les correctifs tentés. Si un fait vérifiable manque, inspectez les fichiers/logs locaux avant de demander.
2. Choisissez le mode de preuve. Pour les erreurs/régressions, recherchez d'abord les issues, PRs, versions et code. Pour les besoins de capacité ou d'outil, recherchez d'abord les candidats de dépôt. Pour l'implémentation de fonctionnalités, utilisez à la fois les candidats de dépôt et les preuves issues/PR/code.
3. Évaluez l'utilité des sous-agents. Avant une recherche GitHub substantielle, décidez si un travail conditionnel de sous-agent améliorerait la couverture, la qualité des preuves ou la couverture de révision. Si vous n'utilisez pas de sous-agents, indiquez brièvement la raison en rapportant le chemin de recherche.
4. Créez des recherches ciblées. Préférez le texte d'erreur exact, les noms de packages/API, les numéros de version, framework + symptôme, les noms de fichiers, les clés de configuration, les fragments de stack trace, les noms de commandes en échec ou la capacité + framework/runtime/API.
5. Trouvez des projets GitHub pertinents le cas échéant. Préférez les dépôts haute adéquation, haute étoiles (Stars), actifs, non archivés, avec des licences claires et des exemples réels. Abaissez le seuil d'étoiles lorsque l'ensemble haute étoiles est trop large ou ne correspond pas exactement au problème.
6. Recherchez des preuves open-source. Utilisez les issues, PRs, discussions, code, exemples, notes de version et documentation officielle des projets open-source pertinents. La recherche de dépôt est obligatoire lorsqu'un projet lui-même peut résoudre le problème.
7. Classez d'abord par adéquation au problème, avec les étoiles comme signal de maturité. Un dépôt avec beaucoup d'étoiles est un candidat solide pour l'inspection, mais les issues confirmées par le mainteneur, les PRs fusionnées, les correctifs publiés, les exemples officiels et le code correspondant exactement l'emportent sur les projets adjacents populaires. Utilisez research-rubric.md lorsque le classement est important.
8. Lisez en profondeur les projets et les preuves les plus solides. Utilisez extraction-playbook.md pour extraire les bases du projet, les surfaces réutilisables, la cause racine ou le modèle d'implémentation, les contraintes de version, les risques, les limites d'adaptation et les étapes de vérification.
9. Traduisez en travail local avec une adaptation minimale. Préservez le workflow éprouvé, l'API, la forme de configuration ou l'architecture là où cela s'applique. Adaptez uniquement les parties requises par les interfaces locales de l'utilisateur, la configuration, le modèle de données/auth, la cible de déploiement ou le langage/runtime.
10. Vérifiez avant de déclarer le succès. Utilisez des tests, des builds, des commandes de reproduction, des requêtes réelles, des logs, des vérifications de navigateur ou une inspection manuelle adaptée au problème local.
11. Si les preuves sont faibles, dites-le. N'étirez pas les correspondances faibles en une recommandation confiante. Marquez la recommandation comme étant basée sur les premiers principes ou locale uniquement lorsque les preuves open-source sont insuffisantes.

Sous-agents / Recherche parallèle

Les sous-agents sont des aides à la recherche conditionnelles, pas une exigence par défaut. Le contrôleur reste responsable du cadrage du problème, du contrôle de la portée, du classement des preuves, de l'adaptation locale et de la vérification finale.

Utilisez les sous-agents lorsqu'au moins l'une de ces conditions s'applique :

• Le problème couvre 2+ écosystèmes, frameworks, langages, outils, surfaces de déploiement ou communautés GitHub indépendants.
• La découverte de dépôts nécessite une large couverture de candidats sur plusieurs familles de requêtes.
• Les preuves issues, PR, discussion, code, version et exemple peuvent être réparties proprement par projet, version ou surface de recherche.
• Une recommandation finale bénéficie d'un examen indépendant des preuves, d'un examen des risques ou d'un examen de rejet de candidat.

N'utilisez pas de sous-agents lorsqu'au moins l'une de ces conditions s'applique :

• La tâche est une erreur étroite avec un package, dépôt, API ou surface de mainteneur évident.
• Le contexte du dépôt local, les logs, la configuration ou les détails de reproduction doivent être compris avant que la recherche externe puisse être délimitée en toute sécurité.
• Les limites de taux GitHub, les limites d'autorisation, les dépôts privés, les secrets, les données de production ou les logs sensibles rendraient la délégation risquée.
• Les sous-agents dupliqueraient principalement les mêmes recherches ou modifieraient les mêmes fichiers locaux.

Lorsque vous utilisez des sous-agents, le contrôleur doit :

• Définir la famille de requêtes, la portée des dépôts, la surface de preuve, les contraintes, la portée d'écriture autorisée et le résultat attendu de chaque sous-agent.
• Exiger des liens directs, des métadonnées vérifiées, une justification de l'adéquation au problème, des notes de risque et des raisons de rejet explicites.
• Maintenir les sous-agents en lecture seule, sauf si une phase d'implémentation distincte a une portée d'écriture autorisée étroite.
• Fusionner et dédoublonner les résultats avant le classement ; ne comptez pas les rapports répétés de la même issue, PR, chemin de code ou dépôt comme preuves indépendantes.
• Vérifier directement les affirmations les plus solides avec gh, des lectures de source, des tests, des logs, des requêtes réelles ou des documents officiels avant de finaliser.

GitHub CLI en premier

Utilisez la CLI GitHub (gh) comme interface de recherche et d'inspection par défaut. Préférez gh search repos, gh search issues, gh search prs, gh search code, gh repo view, gh issue view, gh pr view et gh api avant le web scraping ou les scripts personnalisés. N'ajoutez pas et ne comptez pas sur des scripts de recherche packagés pour ce skill.

Utilisez ces modèles de commande courts comme points de départ, puis ajustez la requête, le dépôt, les champs et les limites au problème local :

gh search repos "<query>" --archived=false --sort stars --order desc --limit 10 --json fullName,url,description,stargazersCount,forksCount,language,license,pushedAt,isArchived,openIssuesCount
gh search issues "<query>" --repo owner/repo --sort updated --order desc --limit 10 --json title,url,state,updatedAt,commentsCount,repository,body
gh search prs "<query>" --repo owner/repo --merged --sort updated --order desc --limit 10 --json title,url,state,updatedAt,commentsCount,repository,body
gh search code "<query>" --repo owner/repo --limit 10 --json path,url,repository,sha
gh repo view owner/repo --json nameWithOwner,url,description,stargazerCount,forkCount,licenseInfo,primaryLanguage,pushedAt,repositoryTopics,homepageUrl
gh api -X GET search/repositories -f q='<query> archived:false' -f sort=stars -f order=desc

Exécutez gh auth status uniquement lorsqu'une commande échoue avec 403, 429, une erreur d'autorisation de dépôt privé ou un message explicite gh non authentifié. Si GitHub renvoie 403/429, inspectez le contexte de limite de taux ou d'autorisation émis avant de réessayer, de réduire l'étendue ou de changer de point de terminaison. Ne collez ni ne persistez de jetons, cookies, contenus de dépôt privé ou identifiants dans les invites, fichiers, logs ou mémoire.

Stratégie de recherche

• Commencez par une approche étroite : chaîne d'erreur exacte, classe d'exception, sortie CLI, nom de package + méthode, clé de configuration ou fragment de stack trace.
• Ajoutez des contraintes : version du package/framework, langage, plateforme, cible de déploiement, bundler, base de données, fournisseur d'authentification ou runtime.
• Recherchez les surfaces dans cet ordre lorsque pertinent : issues/PRs/discussions, correctifs fusionnés, notes de version/changelog, exemples/modèles, code source, puis candidats au niveau dépôt.
• Pour les blocages d'implémentation sans erreur, recherchez la capacité souhaitée ainsi que les noms de framework/runtime/API.
• Pour les besoins en données de plateforme publique telles que les tendances, listes chaudes, recherche par sujet ou métriques d'engagement, ne commencez pas par le web scraping visuel. Recherchez d'abord des points de terminaison publics réutilisables, des crawlers open-source, des ensembles de données archivés et des preuves de champs API ; puis vérifiez la source choisie avec une requête réelle minimale et séparez clairement les données de liste chaude anonymes des données de recherche/topic connectées.
• Pour la découverte de projet réutilisable, recherchez les dépôts triés par étoiles, puis lisez en profondeur uniquement les candidats qui correspondent au problème local. Enregistrez les étoiles, forks, langage, licence, activité et contenu de base.
• Rétrogradez les correspondances qui sont anciennes, non adaptées à la version, archivées, non résolues, spéculatives ou basées uniquement sur des suppositions d'utilisateur.
• Utilisez les étoiles/forks uniquement comme contexte de maturité de soutien et comme arbitres en cas d'égalité entre des dépôts de qualité similaire. Ils ne priment pas sur l'adéquation au problème, les preuves confirmées par le mainteneur, les PRs fusionnées, les notes de version, les exemples officiels ou le code reproductible.
• Pour la sécurité, l'authentification, les paiements, l'infrastructure ou les opérations de production, recoupez les résultats open-source avec les documents ou dépôts officiels actuels lorsque les faits ont pu changer.

Norme de preuve

Pour chaque élément de preuve sérieux, identifiez :

• correspondance exacte : même erreur, comportement, API, version, environnement ou workflow ;
• force de la preuve : confirmation du mainteneur, PR fusionnée, correctif publié, exemple de code reproductible, fixture de test ou rapports indépendants répétés ;
• applicabilité : quelles conditions doivent correspondre localement pour que la solution s'applique ;
• valeur d'implémentation : correctif, configuration, utilisation de l'API, version de dépendance, workflow, test ou modèle opérationnel qui mérite d'être adapté ;
• bases du projet lorsqu'un dépôt est candidat : nom, URL, étoiles, forks, langage, licence, activité, contenu de base, justification de l'adéquation et coût d'adaptation ;
• risque : version obsolète, problème non résolu, contournement dangereux, problème de licence, impact sécurité/vie privée, inadéquation de déploiement ou changement trop large.

Contrat de sortie

Lorsque PavedPath Code affecte matériellement la réponse, incluez :

• profil du problème local : objectif, symptôme/erreur, versions/environnement et contraintes locales ;
• chemin de recherche : requêtes ou méthodes de découverte utilisées, surfaces GitHub/open-source recherchées, et si des sous-agents ont été utilisés ou ignorés ;
• trace de sous-agent lorsque des sous-agents ont été utilisés : portée de chaque sous-agent, surfaces de preuve, résultats clés, candidats rejetés, résultats de dédoublonnage et affirmations que le contrôleur a directement vérifiées ;
• candidats de projet lorsqu'un projet GitHub est pertinent : lien du dépôt, étoiles, forks, langage, licence, activité, contenu de base, justification de la correspondance et comment il peut être utilisé localement ;
• preuves clés : liens vers les issues, PRs, code, exemples, versions ou dépôts, avec justification de la correspondance ;
• solution recommandée : quoi réutiliser directement, quoi adapter localement, quoi éviter de copier, et pourquoi cela convient ;
• options rejetées ou risquées : pourquoi elles ne s'appliquent pas ou nécessitent de la prudence ;
• norme de vérification : test, build, commande de reproduction, requête réelle ou vérification manuelle requise pour confirmer le correctif ;
• étiquette de confiance lorsque les preuves sont faibles ou qu'aucune solution open-source solide n'a été trouvée.

Lorsque des solutions au niveau du dépôt sont pertinentes, incluez un tableau de projet compact. Pour les correctifs purement issues/PR/code, le tableau est optionnel, mais incluez le contexte du dépôt si cela affecte la confiance ou l'applicabilité.

Ne répondez pas uniquement avec des liens, des étoiles ou des classements de popularité. N'écrivez pas « modèle GitHub courant » sans preuve liée. Ne laissez pas les exemples externes outrepasser les contraintes locales.

Pour la recherche de candidats de site Web, SaaS, landing-page, thème ou modèle frontend, incluez à la fois l'URL du dépôt et l'URL de prévisualisation/démo en direct pour chaque candidat sérieux. Si aucune prévisualisation n'est disponible ou vérifiée, indiquez-le explicitement et rétrogradez le candidat.

Note de migration

github-solution-research a été renommé en PavedPath Code. Le comportement précédent est préservé ; il s'agit d'une mise à jour de nom et de positionnement pour l'édition orientée code de PavedPath. Les nouvelles installations doivent utiliser le nom de skill pavedpath-code et le répertoire actif de skill/instruction de l'environnement d'exécution de l'agent cible.

Limites de sécurité

• Préférez lire les modèles et réutiliser les interfaces publiques existantes plutôt que de copier du code. Si la réutilisation de code est nécessaire, vérifiez la licence et gardez les risques d'attribution/obligation visibles.
• Évitez les grandes réécritures d'une solution open-source existante. Conservez son flux éprouvé intact et apportez uniquement les adaptations locales requises par le problème de l'utilisateur.
• Évitez les grands extraits textuels de dépôts, README, issues, PRs ou documentation.
• Ne sauvegardez pas de jetons GitHub, cookies, contenus de dépôt privé ou identifiants dans les sorties, logs, skills ou mémoire.
• Ne transmettez pas de jetons, cookies, contenus de dépôt privé, logs sensibles, secrets, données de production ou identifiants aux sous-agents.
• Si l'accès réseau est indisponible, indiquez que la recherche open-source n'a pas pu être effectuée et marquez la recommandation comme locale uniquement.