J.A.R.V.I.S. Skill Registry

A local-first cognitive runtime for AI agents: persistent memory, dynamic skills, bounded context, tool/model routing and verified execution.

Live site · Get v0.1.0 · Quickstart · Documentation · Good first issues · Roadmap

Most agents can call tools. J.A.R.V.I.S. is being built to answer the harder questions around every call: what context is worth loading, which capability should act, how much resource should be spent, what evidence proves success, and what should be remembered afterward?

The target is not maximum autonomy. It is maximum verified usefulness per resource unit.

See the verified loop

Watch the 82-second capture · Inspect the exact commit and receipts

The loop is generated from captured local runtime evidence: bounded context admission, catalog-backed skill resolution, local model routing, execution receipts and independent verification receipts. The inference sequence uses a clearly labeled deterministic local fixture backend; it does not claim live-provider execution, hidden reasoning, or estimated token/cost savings.

Run it in three commands

J.A.R.V.I.S. uses a zero-dependency Python launcher for the local HUD:

git clone https://github.com/robertoatila/jarvis-skill-registry.git
cd jarvis-skill-registry
python jarvis.py

The launcher validates the checkout, starts the local server on http://127.0.0.1:8899 and opens the HUD. Provider-backed inference still requires explicit local provider configuration and authorization; the launcher does not silently invent credentials or bypass runtime policy.

Useful validation commands:

python jarvis.py --doctor     # prerequisites only; no network calls
python jarvis.py --test       # server self-test
python jarvis.py --full-test  # portable Python master battery

See QUICKSTART.md for configuration and troubleshooting.

v0.1.0 is public — with evidence attached

The first public milestone, Cognitive Runtime Foundation, is available as an immutable tagged release: J.A.R.V.I.S. v0.1.0.

The release workflow re-validates the exact tagged commit before publication and attaches machine-readable evidence. Current public baseline:

The context benchmark measures serialized UTF-8 bytes only. It does not claim provider-token savings, dollar savings, lower latency, answer-quality improvement or end-to-end agent superiority. Those require separate empirical measurement.

Why J.A.R.V.I.S. exists

Long-lived agents fail in predictable ways: context grows without discipline, model/tool choices are hard-coded, retries lose provenance, execution is confused with success, and memory becomes an unverified dump.

J.A.R.V.I.S. separates those concerns into explicit control planes:

What works today

This repository is active development, not a claim that the full autonomous target is already complete.

• Skill registry: catalog, governance, distribution and target-adapter tooling.

• Execution foundation: mission/task/attempt contracts, DAG execution, policy, persistence and scheduler components.

• Bounded inference: registered backends, capability/policy filtering, bounded context, confidence-controlled fallback and scoped cache/memory.

• Verification primitives: explicit requirements, evidence structures and independent state axes.

• Human interfaces: local HUD plus a Markdown/Obsidian cognitive vault.

• Cognitive control plane: current v0.2 development integrates Context/Cognitive governors, provenance-gated memory, fail-closed skill resolution and evidence-aware routing. Broader external autonomy and release-level evidence remain hardening work until the v0.2 gates are complete.

Current v0.2 development includes Node entry points for chat-session, runtime-observability and operational-cockpit contracts, plus a pinned Playwright/Chromium HUD smoke. These are current-development evidence surfaces and do not retroactively change the immutable v0.1.0 release evidence. See the v0.1.0 release evidence and the published release.

The execution model

observe
  ↓
plan
  ↓
resolve context / skill / tool / model
  ↓
execute
  ↓
verify with independent evidence
  ↓
measure cost / latency / risk
  ↓
learn what is safe and useful to retain

A task that ran is not automatically verified. A command that returned zero is not automatically useful. J.A.R.V.I.S. keeps execution state, verification state, recovery state and mission outcome separate so later decisions can reason from evidence instead of optimistic status flags.

Architecture

The trusted foundation owns contracts, authority, durable attempts, artifacts, verification and budgets. Cognitive execution builds above it. The efficiency layer decides which context, tools and models are worth spending within those limits.

Legacy five-layer distribution contract

The newer cognitive-runtime view sits above, rather than erasing, the repository's original five-layer distribution architecture. The canonical historical description remains in docs/ARCHITECTURE_5_LAYERS.md; LAYER 5 is the experience/integration surface.

The legacy distribution matrix models six targets, including Cursor IDE and Google Antigravity, alongside Codex, Claude, ChatGPT and generic targets. Those compatibility records are part of the registry/distribution subsystem; they are not evidence that every cognitive-runtime feature is empirically validated on every target.

Memory Fabric

The memory direction separates transient working context from durable episodes, verified facts and supported procedures. Structured records remain authoritative; the Obsidian vault is a human projection, not the source of truth.

Open the Cognitive Vault MOC.

Remote Second Brain — v0.2 development

The current v0.2 development branch connects the governed memory plane to a restart-safe Obsidian watcher and a thin Remote Companion without creating a second JARVIS runtime.

Implemented contracts include:

• hash/checkpoint-based observation of Markdown and Canvas without requiring Obsidian to be open;

• provenance-gated admission through the existing MemoryFabric, with high-authority note text rejected as execution authority;

• projection receipts that suppress JARVIS-authored managed regions from being re-ingested;

• an external capability catalog plus managed 20 - External Capability Matrix.md projection;

• explicit ChatGPT browser capability manifests that can record KNOWN/UNVERIFIED inventory but cannot grant executable capability;

• per-device one-time pairing, durable sessions, cursor replay and selective revocation;

• local/LAN transport plus an opt-in verified Tailscale adapter for approved devices on unrelated Wi-Fi or mobile data;

• a browser Remote Companion that reaches the same PC-side runtime, memory and provider configuration.

Start the resident host locally:

python -m tooling.remote_host --port 8899

or, with an already-running Tailscale node:

python -m tooling.remote_host --port 8899 --transport tailscale

Provider API keys and chat authorization remain on the home PC. The remote browser does not need or persist them.

Current limitations are explicit: per-user OS autostart is not implemented yet; the Tailscale adapter currently exposes private HTTP rather than provisioning HTTPS, so remote service-worker/PWA installation is not claimed; and raw device credentials are browser-session-lifetime only.

See the Remote Second Brain runbook and the ChatGPT capability bridge contract.

Experience system and visual contract

The local HUD now has a canonical visual contract in DESIGN.md and a reusable library in design-system/. The existing runtime remains vanilla HTML/CSS/JavaScript served by the zero-dependency Python server; this layer does not introduce Tailwind, shadcn/ui or a frontend build dependency.

When the HUD is running, the browsable showcase is available at http://127.0.0.1:8899/assets/design-system/index.html. It demonstrates the canonical tokens, component states, dark/light themes, retractable navigation patterns and the professional operational-progression model used by J.A.R.V.I.S.

New visual work should consume the --jv-* tokens and primitives instead of adding hard-coded colors, typography, spacing or radii. Agent-facing rules are summarized in AGENTS.md.

Try the local HUD

python jarvis.py

Then use the HUD to inspect the current registry/runtime. For provider-backed chat, configure a supported provider using the example configuration files first. If authorization or provider configuration is missing, the runtime should report the operation as blocked/unverified rather than pretending it succeeded.

The server source is tooling/jarvis_server.py and the HUD source is in ui/.

Evidence before claims

Architecture direction and validated behavior are deliberately separated. The machine-readable current status is evidence/current.json; it remains INCOMPLETE until the required direct evidence gates have fresh PASS reports. Start with the documentation map, then use the evidence source appropriate to the claim:

• Current machine evidence manifest

• v0.1.0 release

• Milestone Zero report

• Autonomous Intelligence Plan

• Server inference boundary

• v0.2 Plan 2 execution status

• Cognitive software upgrade record

Current gaps and validated changes are tracked in active plans/status ledgers rather than duplicated here. Historical material remains useful context, but it is not current validation evidence by itself.

Repository map

Contribute without learning the whole runtime

The easiest useful contributions are intentionally small:

1. Run python jarvis.py --doctor and python jarvis.py --full-test.

2. Pick a good first issue or help wanted task.

3. Add one skill, adapter, test, provider integration or reproducible bug case.

4. Open a PR with the evidence used to validate the change.

See CONTRIBUTING.md, CODE_OF_CONDUCT.md and SECURITY.md.

If the architecture is useful, star the repository so other agent-runtime builders can find it. If an assumption is wrong, a reproducible counterexample or focused issue is more valuable than a star.

Project status

v0.1.0 — Cognitive Runtime Foundation is released and remains the immutable public baseline. v0.2.0 is still a release-candidate program, not a final release: the implementation includes the direct validation architecture, repository-scale benchmark, receipt-driven HUD/browser smoke harness and claim audit, while full fresh gate execution is still required before promotion. Machine status lives in evidence/current.json; implementation plans and gate definitions live in docs/superpowers/.

See docs/launch/LAUNCH_PLAN.md, docs/launch/DEMO_90S.md and the roadmap.

License

The repository is licensed under the Apache License 2.0; see LICENSE. Catalogued third-party repositories and skills retain their own licenses and provenance requirements; inclusion in the registry is not blanket permission to execute or redistribute upstream material.