Was macht PavedPath Code?
PavedPath Code hilft Agenten dabei, Softwareentwicklungsprobleme nicht neu zu erfinden. Es durchsucht GitHub und Open-Source-Belege nach bewährten Implementierungspfaden und passt das stärkste Muster mit minimalen, überprüfbaren Änderungen an die lokale Codebasis an.
Nutze GitHub als primäre Evidenzquelle, nicht als Link-Sammlung. Ziel ist es, das lokale Codeproblem zu definieren, nach Pfaden zu suchen, die bereits in öffentlichen Repositories, Issues, Pull Requests, Diskussionen, Beispielen, Release Notes und Quellcode beschritten wurden, die Stärke dieser Evidenz zu bewerten und dann das stärkste Muster in eine kleine lokale Korrektur, einen Implementierungspfad oder einen Verifikationsplan zu übersetzen.
Dies ist die codezentrierte Edition von PavedPath. Erweitere sie nicht auf den zukünftigen Allzweck-PavedPath. Sie ist für Softwareentwicklungsarbeit gedacht: Fehler, Laufzeitfehler, Build-/Test-/Deploy-Fehler, Abhängigkeitsprobleme, Framework- oder API-Nutzung, Integrationsblockaden, Implementierungsmuster, Auswahl von Engineering-Tools und Anpassung von Open-Source-Lösungen.
Wann verwenden
- Laufzeit-, Build-, Test-, Deploy-, Package-, SDK-, API-, Abhängigkeits-, Framework- oder Integrationsfehler.
- Eine Feature-Implementierung wird durch einen unklaren Grenzfall, fehlendes Nutzungsmuster, versionsspezifisches Verhalten oder unsicheren API-Vertrag blockiert.
- Ein lokales Problem ähnelt etwas, das Maintainer oder andere Open-Source-Nutzer möglicherweise in Issues, PRs, Beispielen, Code, Release Notes oder Diskussionen gelöst haben.
- Der Benutzer fragt, ob GitHub- oder Open-Source-Projekte bereits ein konkretes Engineering-Problem gelöst haben.
- Ausgereifte Implementierungsbeispiele oder wiederverwendbare Projekte würden die Unsicherheit für eine bestimmte Fähigkeit reduzieren.
- Die Antwort soll geeignete GitHub-Repositories vergleichen und erklären, wie man einen bewährten Pfad lokal anpasst.
Verwende PavedPath Code nicht für reine Textkorrekturen, rein lokale Refactorings, bei denen die Codebasis bereits die Antwort liefert, nicht-technische Lebensentscheidungen, Social-Media-Workflows, Lernmethoden, Kaufentscheidungen oder Anfragen, die ausdrücklich Web-/GitHub-Recherche verbieten. Überprüfe keine privaten Repositories, es sei denn, der Benutzer gewährt explizit Zugriff.
Standard-Workflow
- Formuliere zuerst das lokale Codeproblem. Erfasse das Ziel, Symptom, Fehlersignatur, Reproduktionspfad, Versionen, Laufzeit, Abhängigkeits-/Framework-Namen, letzte Änderungen, Einschränkungen und versuchte Korrekturen. Wenn eine ermittelbare Tatsache fehlt, überprüfe lokale Dateien/Logs vor dem Fragen.
- Wähle den Evidenzmodus. Für Fehler/Regressionen suche zuerst in Issues, PRs, Releases und Code. Für Fähigkeiten- oder Werkzeugbedarf suche zuerst nach Repository-Kandidaten. Für Feature-Implementierung nutze sowohl Repository-Kandidaten als auch Issue-/PR-/Code-Evidenz.
- Bewerte den Nutzen von Subagenten. Vor umfangreicher GitHub-Recherche entscheide, ob bedingte Subagentenarbeit die Breite, Evidenzqualität oder Prüfungsabdeckung verbessern würde. Wenn keine Subagenten verwendet werden, nenne den Grund kurz bei der Meldung des Suchpfads.
- Erstelle gezielte Suchen. Bevorzuge exakten Fehlertext, Paket-/API-Namen, Versionsnummern, Framework + Symptom, Dateinamen, Config-Keys, Stacktrace-Fragmente, fehlschlagende Befehlsnamen oder Fähigkeit + Framework/Runtime/API-Namen.
- Finde bei Bedarf geeignete GitHub-Projekte. Bevorzuge hochpassende, hoch bewertete, aktive, nicht archivierte Repositories mit klaren Lizenzen und echten Beispielen. Senke die Stern-Schwelle, wenn die Gruppe der hoch bewerteten Repositories zu breit ist oder das genaue Problem verfehlt.
- Durchsuche Open-Source-Evidenzquellen. Nutze Issues, PRs, Diskussionen, Code, Beispiele, Release Notes und offizielle Projektdokumente innerhalb relevanter Open-Source-Repos. Eine Repository-Suche ist erforderlich, wenn das Projekt selbst das Problem lösen könnte.
- Bewerte zuerst nach Problemtreffergenauigkeit, mit Sternen als Reifesignal. Ein hoch bewertetes Repository ist ein starker Kandidat für die Inspektion, aber von Maintainern bestätigte Issues, gemergte PRs, veröffentlichte Fixes, offizielle Beispiele und exakt passender Code schlagen beliebte benachbarte Projekte. Verwende research-rubric.md, wenn die Bewertung wichtig ist.
- Lies die stärksten Projekte und Beweise gründlich. Verwende extraction-playbook.md, um Projektgrundlagen, wiederverwendbare Oberflächen, Ursache oder Implementierungsmuster, Versionseinschränkungen, Risiken, Anpassungsgrenzen und Verifikationsschritte zu extrahieren.
- Übersetze in lokale Arbeit mit minimaler Anpassung. Bewahre den bewährten Workflow, die API, die Konfigurationsform oder die Architektur, wo es passt. Passe nur die Teile an, die für die lokalen Schnittstellen, Konfiguration, Daten-/Auth-Modell, Deployment-Ziel oder Sprache/Laufzeit des Benutzers erforderlich sind.
- Überprüfe vor der Erfolgsmeldung. Verwende Tests, Builds, Reproduktionsbefehle, echte Requests, Logs, Browser-Checks oder manuelle Inspektion, die zum lokalen Problem passen.
- Wenn die Evidenz schwach ist, sage es. Dehne schwache Treffer nicht zu einer selbstbewussten Empfehlung. Markiere die Empfehlung als grundsatzbasiert oder rein lokal, wenn Open-Source-Evidenz nicht ausreicht.
Subagenten / Parallel-Recherche-Richtlinien
Subagenten sind bedingte Forschungshilfen, keine Standardanforderung. Der Controller bleibt für Problemdefinition, Umfangskontrolle, Evidenzbewertung, lokale Anpassung und abschließende Verifikation verantwortlich.
Verwende Subagenten, wenn mindestens eines zutrifft:
- Das Problem erstreckt sich über 2+ unabhängige Ökosysteme, Frameworks, Sprachen, Tools, Deployment-Oberflächen oder GitHub-Communities.
- Die Repository-Erkundung benötigt breite Kandidatenabdeckung über mehrere Abfragefamilien hinweg.
- Issue-, PR-, Diskussions-, Code-, Release- und Beispiel-Evidenz kann sauber nach Projekt, Version oder Suchoberfläche aufgeteilt werden.
- Eine abschließende Empfehlung profitiert von unabhängiger Evidenzprüfung, Risikoprüfung oder Kandidatenablehnungsprüfung.
Verwende keine Subagenten, wenn eines der folgenden zutrifft:
- Die Aufgabe ist ein enger Fehler mit einem offensichtlichen Paket, Repository, API oder Maintainer-Oberfläche.
- Lokaler Repository-Kontext, Logs, Konfiguration oder Reproduktionsdetails müssen verstanden werden, bevor externe Recherche sicher eingegrenzt werden kann.
- GitHub-Ratenlimits, Autorisierungsgrenzen, private Repositories, Geheimnisse, Produktionsdaten oder sensible Logs würden die Delegation riskant machen.
- Subagenten würden größtenteils dieselben Suchen duplizieren oder dieselben lokalen Dateien bearbeiten.
Bei Verwendung von Subagenten muss der Controller:
- Die Abfragefamilie, den Repository-Umfang, die Evidenzoberfläche, Einschränkungen, den zulässigen Schreibumfang und die erwartete Ausgabe jedes Subagenten definieren.
- Direkte Links, überprüfte Metadaten, Problemtreffer-Begründung, Risikohinweise und explizite Ablehnungsgründe verlangen.
- Subagenten schreibgeschützt halten, es sei denn, eine separate Implementierungsphase hat einen engen zulässigen Schreibumfang.
- Ergebnisse vor der Bewertung zusammenführen und deduplizieren; wiederholte Meldungen desselben Issues, PRs, Codepfads oder Repositorys nicht als unabhängige Evidenz zählen.
- Die stärksten Behauptungen direkt mit
gh, Quellcode-Lektüre, Tests, Logs, echten Requests oder offiziellen Dokumenten überprüfen, bevor sie finalisiert werden.
GitHub CLI zuerst
Verwende die GitHub CLI (gh) als standardmäßige Such- und Inspektionsoberfläche. Bevorzuge gh search repos, gh search issues, gh search prs, gh search code, gh repo view, gh issue view, gh pr view und gh api vor Browser-Scraping oder benutzerdefinierten Skripten. Füge keine gebündelten Suchskripte für diesen Skill hinzu oder verlasse dich darauf.
Verwende diese kurzen Befehlsvorlagen als Ausgangspunkt und passe dann die Abfrage, das Repository, die Felder und die Grenzwerte an das lokale Problem an:
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
Führe gh auth status nur aus, wenn ein Befehl mit 403, 429, einem Autorisierungsfehler für ein privates Repository oder einer expliziten gh-Nicht-authentifiziert-Meldung fehlschlägt. Wenn GitHub 403/429 zurückgibt, überprüfe den ausgegebenen Ratelimit- oder Autorisierungskontext, bevor du es erneut versuchst, die Breite reduzierst oder Endpunkte wechselst. Gib keine Tokens, Cookies, privaten Repository-Inhalte oder Anmeldeinformationen in Prompts, Dateien, Logs oder Speicher weiter.
Suchstrategie
- Beginne eng: exakte Fehlerzeichenfolge, Ausnahmeklasse, CLI-Ausgabe, Paket + Methodenname, Config-Key oder Stacktrace-Fragment.
- Füge Einschränkungen hinzu: Paket-/Framework-Version, Sprache, Plattform, Deployment-Ziel, Bundler, Datenbank, Auth-Provider oder Laufzeit.
- Durchsuche Oberflächen in dieser Reihenfolge, wenn relevant: Issues/PRs/Diskussionen, gemergte Fixes, Release Notes/Changelog, Beispiele/Vorlagen, Quellcode, dann Repository-Ebene Kandidaten.
- Bei Implementierungsblockaden ohne Fehler suche nach der gewünschten Fähigkeit plus Framework-/Runtime-/API-Namen.
- Für öffentliche Plattformdaten wie Trends, Hotlists, Themensuche oder Engagement-Metriken beginne nicht mit visuellem Browser-Scraping. Suche zuerst nach wiederverwendbaren öffentlichen Endpunkten, Open-Source-Crawlern, archivierten Datensätzen und API-Feldevidenz; überprüfe dann die gewählte Quelle mit einem minimalen echten Request und trenne anonyme Hotlist-Daten klar von angemeldeten Such-/Themendaten.
- Für die Erkundung wiederverwendbarer Projekte durchsuche Repositories sortiert nach Sternen, lies dann nur Kandidaten gründlich, die zum lokalen Problem passen. Notiere Sterne, Forks, Sprache, Lizenz, Aktivität und grundlegenden Inhalt.
- Stufe Treffer herab, die alt, versionsungleich, archiviert, ungelöst, spekulativ oder nur auf Benutzervermutungen basieren.
- Verwende Sterne/Forks nur als unterstützenden Reifekontext und Entscheidungshilfe bei gleich gut passenden Repositories. Sie überschreiben nicht die Problemtreffergenauigkeit, von Maintainern bestätigte Evidenz, gemergte PRs, Release Notes, offizielle Beispiele oder reproduzierbaren Code.
- Für Sicherheit, Authentifizierung, Zahlungen, Infrastruktur oder Produktionsabläufe überprüfe Open-Source-Ergebnisse anhand der aktuellen offiziellen Dokumente oder Repositories, wenn sich Fakten geändert haben könnten.
Evidenzstandard
Identifiziere für jedes ernsthafte Evidenzelement:
- exakte Übereinstimmung: gleicher Fehler, gleiches Verhalten, gleiche API, gleiche Version, gleiche Umgebung oder gleicher Workflow;
- Evidenzstärke: Bestätigung durch Maintainer, gemergter PR, veröffentlichter Fix, reproduzierbares Codebeispiel, Test-Fixture oder wiederholte unabhängige Berichte;
- Anwendbarkeit: welche Bedingungen lokal übereinstimmen müssen, damit die Lösung anwendbar ist;
- Implementierungswert: Patch, Konfiguration, API-Nutzung, Abhängigkeitsversion, Workflow, Test oder Betriebsmuster, das sich anzupassen lohnt;
- Projektdaten, wenn ein Repository ein Kandidat ist: Name, URL, Sterne, Forks, Sprache, Lizenz, Aktivität, grundlegender Inhalt, Trefferbegründung und Anpassungskosten;
- Risiko: veraltete Version, ungelöstes Issue, unsicherer Workaround, Lizenzbedenken, Sicherheits-/Datenschutzauswirkungen, Deployment-Ungleichgewicht oder zu weitreichende Änderung.
Ausgabevertrag
Wenn PavedPath Code die Antwort wesentlich beeinflusst, füge hinzu:
- lokales Problemprofil: Ziel, Symptom/Fehler, Versionen/Umgebung und lokale Einschränkungen;
- Suchpfad: verwendete Abfragen oder Erkundungsmethoden, durchsuchte GitHub-/Open-Source-Oberflächen und ob Subagenten verwendet oder übersprungen wurden;
- Subagenten-Spur, wenn Subagenten verwendet wurden: Umfang jedes Subagenten, Evidenzoberflächen, wichtige Ergebnisse, abgelehnte Kandidaten, Deduplizierungsergebnisse und welche Behauptungen der Controller direkt überprüft hat;
- Projektkandidaten, wenn ein GitHub-Projekt selbst relevant ist: Repo-Link, Sterne, Forks, Sprache, Lizenz, Aktivität, grundlegender Inhalt, Trefferbegründung und wie es lokal verwendet werden kann;
- wichtige Evidenz: Links zu Issues, PRs, Code, Beispielen, Releases oder Repos mit Trefferbegründung;
- empfohlene Lösung: was direkt wiederverwendet, was lokal angepasst, was nicht kopiert werden sollte und warum es passt;
- abgelehnte oder riskante Optionen: warum sie nicht zutreffen oder Vorsicht geboten ist;
- Verifikationsstandard: Test, Build, Reproduktionsbefehl, echter Request oder manuelle Überprüfung, die zur Bestätigung des Fixes erforderlich ist;
- Vertrauenslabel, wenn die Evidenz schwach ist oder keine starke Open-Source-Lösung gefunden wurde.
Wenn Lösungen auf Repository-Ebene relevant sind, füge eine kompakte Projekt-Tabelle hinzu. Für reine Issue-/PR-/Code-Fixes ist die Tabelle optional, aber füge Repository-Kontext hinzu, wenn er das Vertrauen oder die Anwendbarkeit beeinflusst.
Antworte nicht nur mit Links, Sternen oder Popularitätsrankings. Schreibe nicht "häufiges GitHub-Muster" ohne verlinkte Evidenz. Lasse nicht zu, dass externe Beispiele lokale Einschränkungen außer Kraft setzen.
Für Website-, SaaS-, Landing-Page-, Theme- oder Frontend-Template-Kandidatenforschung füge für jeden ernsthaften Kandidaten sowohl die Repository-URL als auch die Live-Vorschau-/Demo-URL hinzu. Wenn keine Vorschau verfügbar oder verifiziert ist, gib dies explizit an und stufe den Kandidaten herab.
Migrationshinweis
github-solution-research wurde umbenannt in PavedPath Code. Das vorherige Verhalten bleibt erhalten; dies ist eine Namens- und Positionierungsaktualisierung für die codezentrierte Edition von PavedPath. Neue Installationen sollten den Skill-Namen pavedpath-code und das aktive Skill-/Anweisungsverzeichnis der Ziel-Agenten-Laufzeit verwenden.
Sicherheitsgrenzen
- Bevorzuge Lesemuster und Wiederverwendung bestehender öffentlicher Schnittstellen vor dem Kopieren von Code. Wenn Code-Wiederverwendung notwendig ist, überprüfe die Lizenz und halte die Verpflichtungen/Risiken der Namensnennung sichtbar.
- Vermeide umfangreiche Neuschreibungen einer bestehenden Open-Source-Lösung. Behalte ihren bewährten Ablauf intakt und nimm nur die lokalen Anpassungen vor, die für das Problem des Benutzers erforderlich sind.
- Vermeide lange wörtliche Auszüge aus Repositories, READMEs, Issues, PRs oder Dokumentation.
- Speichere keine GitHub-Tokens, Cookies, privaten Repository-Inhalte oder Anmeldeinformationen in Ausgaben, Logs, Skills oder Speicher.
- Gib keine Tokens, Cookies, privaten Repository-Inhalte, sensible Logs, Geheimnisse, Produktionsdaten oder Anmeldeinformationen an Subagenten weiter.
- Wenn kein Netzwerkzugriff verfügbar ist, gib an, dass keine Open-Source-Recherche durchgeführt werden konnte, und markiere die Empfehlung als rein lokal.