PullNexus

GitHub-basiertes Register und CLI für lokale KI-Ressourcen. Suchen, ziehen und übermitteln Sie wiederverwendbare Skills, Tools, Vorlagen, Datensätze und Workflow-Artefakte.

Schnellstart

pip install pullnexus

Das Register durchsuchen:

pullnexus search "fine-tune 35B on consumer GPU"
pullnexus search "local agent loop" --type skill

Verfügbare Ressourcen durchstöbern:

pullnexus list-skills --type dataset
pullnexus pull local-rag-starter-pack

Eine Übermittlung starten:

pullnexus submit --interactive --type skill
# or open an issue: github.com/MRWillisT/PullNexus/issues/new/choose

Aktuelles Register: 156 Ressourcen in 10 Ressourcentypen: Skills, Tools, Vorlagen, Playbooks, Richtlinien, Prompts, Datensätze, Umgebungen, Evals und Repositories.

1. Vision

Lokale Modelle verbessern sich schnell, aber der umgebende Workflow ist immer noch fragmentiert. Nützliche Prompts, JSONL-Beispiele, Tool-Definitionen, Vorlagen, Hardware-Hinweise und Evaluierungssets sind über Repositories, Gists und Chat-Protokolle verstreut.

PullNexus verpackt diese Artefakte in ein konsistentes Registerformat, das heute über eine CLI durchsucht und im Laufe der Zeit von anderen Clients erweitert werden kann. Das praktische Ziel ist einfach: Finden Sie eine relevante Ressource, prüfen Sie deren Metadaten, ziehen Sie sie, falls sie installierbar ist, oder verwenden Sie sie als Referenzmaterial für Ihr eigenes lokales Setup.

Es ist eine kleine, offene Distributionsschicht für lokale KI-Workflows und kein Modell-Host, keine gehostete Agentenplattform und keine Prompt-Galerie.

2. Warum jetzt?

Mehrere Aspekte sind gleichzeitig gereift:

• Lokale Inferenz-Tools wie Ollama, llama.cpp, LM Studio und vLLM sind mittlerweile fester Bestandteil von Entwickler-Workflows.

• Immer mehr Menschen halten die Inferenz lokal, da Preisgestaltung, Datenschutz und Latenz im täglichen Gebrauch wichtig sind.

• Dem wiederverwendbaren Material rund um diese Workflows fehlt noch ein Standard-Zuhause. Modelle und Datensätze haben Hubs; operative Artefakte meist nicht.

• Die meisten angrenzenden Tools lösen Laufzeit-Orchestrierung oder Modell-Hosting, nicht die Entdeckung und Wiederverwendung kleinerer Bausteine wie Skills, Playbooks, Vorlagen oder Evals.

Das macht ein typisiertes, Pull-orientiertes Register selbst in bescheidenem Umfang nützlich.

3. Funktionsweise

1. Ressourcen werden in skills/index.json mit typisierten Metadaten indexiert.

2. Die CLI kann das Register durchsuchen, nach Typ/Kategorie/Tag filtern und installierbare Ressourcen ziehen.

3. Mitwirkende können über GitHub einreichen oder mit dem interaktiven Assistenten einen Entwurfsordner generieren.

4. Ressourcen bleiben im Repository versioniert, getaggt und überprüfbar.

5. Dasselbe Schema kann später reichhaltigere Clients und Integrationen unterstützen.

Beitragsworkflow

Ressourcen müssen nicht als "Skills" beginnen. Ein nützlicher JSONL-Konversationssatz, ein Deployment-Playbook, eine Modellvorlage, ein Richtliniendokument, eine Tool-Referenz oder ein Umgebungsprofil können alle dasselbe Registerformat durchlaufen.

In der Praxis stammen viele Einträge aus der tatsächlichen Projektarbeit: Etwas wird wiederverwendbar, wird dokumentiert und mit Metadaten sowie optionalen Begleitdateien zum Register hinzugefügt.

CLI-Oberfläche

Aktuelle öffentliche Befehle:

pullnexus search rust debugger --type skill
pullnexus list-skills --category automation
pullnexus pull local-rag-starter-pack
pullnexus submit --interactive --type playbook

Einige Ressourcentypen sind installierbare Dateipakete; andere sind Referenzeinträge, die auf externe Repositories, Datensätze oder Dokumentationen verweisen.

4. Wie ein Skill tatsächlich aussieht

Hier ist die Ordnerstruktur für einen Skill – das ist es, was Leute einreichen:

skills/python-advanced-debugging/
├── skill.json          → Metadata (name, description, tags, version, license)
├── examples.jsonl      → JSONL conversation pairs or training examples
├── README.md           → Human-readable explanation and usage notes
├── eval.jsonl          → Test cases to verify the skill behaves as expected
└── tools/              → Optional MCP tool definitions

Beispiel skill.json:

{
  "name": "python-advanced-debugging",
  "version": "1.2.0",
  "description": "Expert techniques for memory leaks, pdb, and tracing in Python",
  "tags": ["python", "debugging", "development"],
  "license": "CC0-1.0",
  "evaluation_cases": 12,
  "mcp_compatible": true
}

Die Struktur ist absichtlich einfach gehalten, damit Überprüfung, Wiederverwendung und Validierung unkompliziert bleiben.

5. Aktueller Stand

Heute verfügbar

• GitHub-basiertes Register mit 156 indexierten Ressourcen in 10 Ressourcentypen

• Öffentliche CLI-Befehle für Suche, Ziehen/Installieren, Auflisten und Einreichungs-Scaffolding

• Interaktiver Einreichungsassistent, der Ressourcenordner generiert und Metadaten validiert

• Schema-Unterstützung für Skills, Tools, Vorlagen, Richtlinien, Playbooks, Prompts, Datensätze, Umgebungen, Evals und Repositories

• Lokales/Remote-Register-Abrufen, sodass die CLI bei Nichtverfügbarkeit von GitHub elegant degradieren kann

• Skill-Ordner basierend auf einfachen Dateien: Metadaten, JSONL-Beispiele, README und optionale Eval-/Tool-Definitionen

MCP-Assistentenmodus

Jeder KI-Assistent, der mit dem PullNexus MCP-Server verbunden ist, kann das Live-Register mitten im Gespräch nutzen, anstatt nur aus allgemeinem Hintergrundwissen zu antworten.

• Durchsuchen Sie das Register während des Gesprächs

• Empfehlen Sie spezifische Ressourcen basierend auf dem Stack, dem Problem oder dem Ziel des Benutzers

• Ziehen Sie installierbare Ressourcen lokal, ohne den Chat zu verlassen

• Übermitteln Sie Kompatibilitätsfeedback, nachdem ein Workflow erfolgreich war oder fehlgeschlagen ist

Beispiel-Prompt für eine aussagekräftige Vorher/Nachher-Demo:

I’m building a fully local RAG pipeline for PDFs with Ollama. Retrieval quality is bad, chunking feels wrong, and I want something concrete I can inspect or install. What should I use?

Ohne PullNexus geben die meisten Assistenten allgemeine Ratschläge zu RAG-Frameworks und Chunk-Größen. Mit verbundenem PullNexus MCP kann der Assistent das Live-Register durchsuchen, konkrete Ressourcen wie local-rag-starter-pack und rag-eval-baseline empfehlen und anbieten, diese sofort in einen lokalen Ordner zu ziehen.

Andere gute Demo-Prompts sind solche, die einen echten Stack plus einen Fehlermodus enthalten: lokales RAG-Debugging, Agenten-Orchestrierung, MCP-Integration oder Python-Debugging funktionieren alle gut.

Kurzfristige Arbeiten

• Die zusätzlichen gepackten Befehlsoberflächen sauberer in der Haupt-CLI freilegen

• Dokumentation zur MCP/Client-Integration verbessern

• Validierung, Überprüfung und Kompatibilitätsberichterstattung rund um eingereichte Ressourcen verschärfen

• UX für das Durchsuchen und Filtern des Registers verbessern

• Mehr Automatisierung rund um Veröffentlichung und Qualitätsprüfungen hinzufügen

6. Positionierung

PullNexus positioniert sich zwischen rohen Repositories und vollständigen Plattformprodukten. Es versucht nicht, Modelle zu hosten oder Agenten-Laufzeiten zu ersetzen. Seine Aufgabe ist enger gefasst: Wiederverwendbare lokale KI-Ressourcen in einem durchsuchbaren Format mit genügend Metadaten zu halten, um sie leicht auffindbar und wiederverwendbar zu machen.

7. Herausforderungen & Minderungsstrategien

8. Governance

PullNexus wird derzeit von einer Person gepflegt. Entscheidungen über das Registerformat, die Beitragsregeln und die Moderation werden offen im Repository durch Issues und Pull Requests getroffen. Das hält das Projekt unkompliziert: schnelle Entscheidungen, öffentliche Begründungen und eine klare Nachvollziehbarkeit.

Sollte das Projekt zu einer echten Multi-Maintainer-Bemühung heranwachsen, kann die Governance zu einem leichtgewichtigen Maintainer-Modell mit dokumentierten Rollen und Entscheidungsregeln erweitert werden. Vorerst ist die Priorität einfach: Standards klar halten, den Prozess öffentlich halten und das Projekt nützlich halten.

9. Register-Highlights

Einige Einstiegspunkte, die man kennen sollte:

• autonomous-agent-training-pack — 160+ synthetische JSONL-Beispiele, 16 Themen, sofort einsatzbereite Train/Val/Test-Splits

• synthetic-general-training-pack — 110+ allgemeine Trainingsbeispiele für Programmierung, Schlussfolgerung, Dokumentation und Web

• agent-role-orchestrator / agent-role-coder / agent-role-reviewer — System-Prompts für ein vollständiges lokales Multi-Agenten-Setup

• local-agent-system-blueprint — Anfängerleitfaden zum Aufbau eines lokalen autonomen Agentensystems

• multi-agent-roles-template — JSON-Rollenkonfiguration für ein lokales 5-Agenten-System direkt einsatzbereit

• vibe-coder-workflow — die vollständige autodidaktische Entwicklerschleife, von der vagen Idee bis zum funktionierenden Code

• qwen3-35b-12gb-llama-server — von der Community beigesteuerte llama-server-Konfiguration für Qwen3 auf 12GB VRAM

• kv-cache-vram-best-practices — VRAM-Optimierungsrichtlinie für KV-Cache-Tuning

• n8n-mcp-workflows / autonomous-agent-payments — Einträge für das MCP-Ökosystem

Durchsuchen Sie das Register, um alle 155 Einträge zu sehen: pullnexus list-skills

10. Kurzfristige Roadmap

11. Über den Maintainer

PullNexus wird von einem Entwickler gepflegt, der etwa anderthalb Jahre an echten KI-gestützten Projekten gearbeitet hat. Das Projekt entstand aus wiederkehrenden Problemen bei der Wiederverwendung: Nützliche Prompts, JSONL-Beispiele, Deployment-Hinweise und Tool-Referenzen tauchten immer wieder in Ad-hoc-Formaten auf, ohne dass es einen klaren Ort gab, um sie zu standardisieren.

Deshalb ist das Repository auf praktische Artefakte und einfache Dateien ausgerichtet. Das Ziel ist nicht, zuerst eine große Plattformvision zu präsentieren; es geht darum, wiederverwendbares lokales KI-Material einfacher zu verpacken, zu überprüfen, zu finden und zu nutzen.

Durchsuchen Sie das Register. Ziehen Sie, was passt. Reichen Sie ein, was geholfen hat.