fullseye

Using Fullseye as an AI assistant’s RAG (for Claude Code)

日本語 · English · 简体中文 · 繁體中文 · 한국어 · Deutsch

The recommended way to run Fullseye is as the knowledge base (RAG) of an AI coding assistant. Because every op carries a machine-readable Markdown note (docs/ops, a single source of truth), no extra vector database or embedding service is needed. Any environment that can grep is already a RAG.

Three tiers of adoption are provided. Tiers 0/1 have zero external dependencies (self-contained in the Fullseye repository).

Use from PyPI: in an environment where you pip install fullseye, the console script fullseye-rag is available. A checkout (clone / pip install -e .) pins the full docs/ops corpus to the skill; a wheel-only install pins the bundled OP_CATALOG.md (the all-op catalog for AI) instead (if you later want the full per-op notes, just clone the repo and re-run). Update with py -3.11 tools/update_fullseye.py (refuses a dirty tree, --ff-only, updates the skill over a backup, and leaves Studio settings untouched — designed not to wreck your environment).


Tier 0: just open the repository (zero steps)

Open a checkout of the Fullseye repository in Claude Code and you can search and reference docs/ops/INDEX.md and the per-op notes directly. The corpus is repository content (not bundled in the wheel), so if you only pip-installed, clone the repository as well.

docs/ops/2d/<category>/<op>.md   # call form, type contract, HALCON alias, references, related ops
docs/ops/3d/<category>/<op>.md
docs/ops/INDEX.md                # whole table of contents, auto-generated by walking the folder tree
docs/ops/2d/guides/<family>.md   # how-to guides for 13 families (math, diagrams, canonical citations)
docs/OP_INDEX.json               # machine-readable index of the registry

If you want to consult Fullseye while working in your own project, run the bundled setup script once:

py -3.11 tools/setup_claude_rag.py              # install (re-run = update)
py -3.11 tools/setup_claude_rag.py --uninstall  # remove

The bundled skill skills/fullseye-ops is copied to ~/.claude/skills/fullseye-ops, and the FULLSEYE_REPO = line in SKILL.md is automatically pinned to this checkout’s absolute path (so the AI knows where the corpus is no matter which project it is working in). It refuses to install on a checkout where the corpus (docs/ops) cannot be found (fail-closed).

From then on, on image-processing / geometric-vision topics Claude Code automatically invokes this skill and runs the flow: search (retrieve) docs/ops → pick ops whose types (sorts) connect and implement → verify with the bundled worked example. The skill body itself is the “how-to-use instructions for the AI”. To install it by hand, just copy skills/fullseye-ops into ~/.claude/skills/ (without the path pin, the AI looks up the repo location each time).

Tier 2 (optional): a clustered corpus — an advanced form with external tools

You can also build a “navigable corpus” that hierarchically clusters the 1,947 notes into topic clusters with an LLM summary per cluster. Internally we use the corpus2skill of a RAPTOR fork (TF-IDF + k-means + LLM summary), but this is an optional optimization, not a requirement. The only requirement is “take docs/ops as input and emit a per-cluster SKILL.md hierarchy”, so any equivalent tool can stand in.

Example of re-ingesting (after updating notes) — recorded honestly, exactly as we run it internally:

$env:RAPTOR_DIR="<path-to-raptor-checkout>"
py -3.11 raptor_corpus2skill.py --source <fullseye>/docs/ops --name fullseye_ops_corpus_v2 `
  --overwrite --max-depth 2 --max-clusters 6 --min-cluster-size 8   # needs ANTHROPIC_API_KEY

Caveat: a clustered corpus is a snapshot at ingest time. If you update docs/ops it goes stale unless you re-ingest (Tiers 0/1 never go stale because they always read the live notes).


Why this works (the design rationale)

  1. md = single source of truth: notes are deterministically auto-generated from the registry, and a CI drift test enforces “committed note == note generated from current code”. The document the AI reads and the actual code are always the same version (frontmatter version + fingerprint).
  2. Type (sort) contract: each note carries in:/out: and “related ops whose types connect”, so the AI can assemble a pipeline while type-checking it.
  3. Verifiable: every op has a ground-truth worked example (examples/ / examples_3d/), so the AI can run its own proposal and check it.
  4. End to end through to display: open Studio (py -3.11 studio.py) and a human can inspect what the AI assembled as image windows and 3-D views on the same screen (scripts can place multiple windows via dev_open_window, etc.).