PullNexus

GitHub-backed registry and CLI for local AI resources. Search, pull, and submit reusable skills, tools, templates, datasets, and workflow artifacts.

Quickstart

pip install pullnexus

Search the registry:

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

Browse what's available:

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

Start a submission:

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

Current registry: 156 resources across 10 resource types: skills, tools, templates, playbooks, policies, prompts, datasets, environments, evals, and repositories.

1. Vision

Local models are improving quickly, but the surrounding workflow is still fragmented. Useful prompts, JSONL examples, tool definitions, templates, hardware notes, and evaluation sets are scattered across repositories, gists, and chat logs.

PullNexus packages those artifacts into a consistent registry format that can be searched from a CLI today and extended by other clients over time. The practical goal is simple: find a relevant resource, inspect its metadata, pull it if it is installable, or use it as reference material for your own local setup.

It is a small, open distribution layer for local AI workflows rather than a model host, hosted agent platform, or prompt gallery.

2. Why Now

Several pieces have matured at the same time:

• Local inference tools such as Ollama, llama.cpp, LM Studio, and vLLM are now normal parts of developer workflows.
• More people are keeping inference local because pricing, privacy, and latency matter in day-to-day use.
• The reusable material around those workflows still lacks a standard home. Models and datasets have hubs; operational artifacts usually do not.
• Most adjacent tools solve runtime orchestration or model hosting, not discovery and reuse of smaller building blocks like skills, playbooks, templates, or evals.

That makes a typed, pull-oriented registry useful even at a modest scale.

3. How It Works

1. Resources are indexed in skills/index.json with typed metadata.
2. The CLI can search the registry, filter by type/category/tag, and pull installable resources.
3. Contributors can submit through GitHub or generate a draft folder with the interactive wizard.
4. Resources stay versioned, tagged, and reviewable in the repository.
5. The same schema can support richer clients and integrations later.

Contribution Workflow

Resources do not need to start as "skills." A useful JSONL conversation set, deployment playbook, model template, policy document, tool reference, or environment profile can all go through the same registry format.

In practice, many entries come from real project work: something becomes reusable, gets documented, and is added to the registry with metadata and optional supporting files.

CLI Surface

Current public commands:

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

Some resource types are installable file packages; others are reference entries that point to external repositories, datasets, or documentation.

4. What a Skill Actually Looks Like

Here's the folder structure for a skill — this is what people submit:

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

Example 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
}

The structure is intentionally plain so that review, reuse, and validation stay straightforward.

5. Current Surface

Available today

• GitHub-backed registry with 156 indexed resources across 10 resource types
• Public CLI commands for search, pull/install, listing, and submission scaffolding
• Interactive submission wizard that generates resource folders and validates metadata
• Schema support for skills, tools, templates, policies, playbooks, prompts, datasets, environments, evals, and repositories
• Local/remote registry fetching so the CLI can degrade gracefully when GitHub is unavailable
• Skill folders built around plain files: metadata, JSONL examples, README, and optional eval/tool definitions

MCP Assistant Mode

Any AI assistant connected to the PullNexus MCP server can use the live registry mid-conversation instead of replying from generic background knowledge alone.

• Search the registry while the conversation is happening
• Recommend specific resources based on the user's stack, problem, or goal
• Pull installable resources locally without leaving chat
• Submit compatibility feedback after a workflow succeeds or fails

Example prompt for a strong before/after 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?

Without PullNexus, most assistants give broad advice about RAG frameworks and chunk sizing. With PullNexus MCP connected, the assistant can search the live registry, recommend concrete resources like local-rag-starter-pack and rag-eval-baseline, and offer to pull them into a local folder immediately.

Other good demo prompts are ones that include a real stack plus a failure mode: local RAG debugging, agent orchestration, MCP integration, or Python debugging all work well.

Near-term work

• Expose the additional packaged command surfaces more cleanly in the main CLI
• Improve MCP/client integration documentation
• Tighten validation, review, and compatibility reporting around submitted resources
• Improve registry browsing and filtering UX
• Add more automation around publishing and quality checks

6. Positioning

PullNexus sits between raw repositories and full platform products. It is not trying to host models or replace agent runtimes. Its job is narrower: keep reusable local-AI resources in one searchable format with enough metadata to make them easy to discover and reuse.

7. Challenges & Mitigations

8. Governance

PullNexus is currently maintained by one person. Decisions about the registry format, contribution rules, and moderation are made openly in the repository through issues and pull requests. That keeps the project straightforward: fast decisions, public rationale, and a clear paper trail.

If the project grows into a true multi-maintainer effort, governance can expand into a lightweight maintainer model with documented roles and decision rules. For now, the priority is simple: keep the standards clear, keep the process public, and keep the project useful.

9. Registry Highlights

A few entry points worth knowing about:

• autonomous-agent-training-pack — 160+ synthetic JSONL examples, 16 themes, ready-to-use train/val/test splits
• synthetic-general-training-pack — 110+ general-purpose training examples for coding, reasoning, docs, and web
• agent-role-orchestrator / agent-role-coder / agent-role-reviewer — system prompts for a full multi-agent local setup
• local-agent-system-blueprint — beginner guide to building a local autonomous agent system
• multi-agent-roles-template — JSON role config for a 5-agent local system out of the box
• vibe-coder-workflow — the full self-taught builder loop, from vague idea to working code
• qwen3-35b-12gb-llama-server — community-contributed llama-server config for Qwen3 on 12GB VRAM
• kv-cache-vram-best-practices — VRAM optimization policy for KV cache tuning
• n8n-mcp-workflows / autonomous-agent-payments — MCP ecosystem entries

Search the registry to browse all 155 entries: pullnexus list-skills

10. Near-Term Roadmap

11. About the Maintainer

PullNexus is maintained by a developer who has spent roughly a year and a half working on real AI-assisted projects. The project grew out of repeated reuse problems: useful prompts, JSONL examples, deployment notes, and tool references kept showing up in ad hoc formats with no clear place to standardize them.

That is why the repository is biased toward practical artifacts and plain files. The goal is not to present a grand platform vision first; it is to make reusable local-AI material easier to package, review, find, and use.

Search the registry. Pull what fits. Submit what helped.