Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/dvcdsys/code-index/cix-workspacenpx skills add dvcdsys/code-index --skill cix-workspacegit clone --depth 1 https://github.com/dvcdsys/code-indexWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00110 | $0.03047 |
| Opus 5 | $0.00055 | $0.01523 |
| Sonnet 5 | $0.00022 | $0.00609 |
| Haiku 4.5 | $0.00011 | $0.00305 |
Grade A, and why
cix-workspace scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 238 lines — stays where its author put it; the contents beside it link to each section on GitHub.
cix workspace — Cross-Project Research Workflow
Some tasks are not contained in one repo. A request like "wire feature X through the platform" can touch a half-dozen repos in different languages and layers — a service, a shared library, the infra manifests, an API spec. Reading one repo gives you 1/N of the picture, and you don't know which N repos are involved until you look.
cix_workspace_search is the tool for that. It searches every repo in a named
workspace at once and tells you:
- Which repos are actually relevant to this request.
- Which code in those repos is the entry point.
- What changes need to land in each, and in what order.
Those three questions are the goal. Don't jump to implementation before you can answer all three with evidence.
There is no "current repo" here (Cowork has no opened working directory). A workspace groups several indexed repos on a server; infer the task's anchor repo from the request, and let the workspace supply the surrounding repos.
This skill only searches. The
cix_*MCP tools are read-only — there is no MCP tool to create a workspace or link/unlink repos. If the workspace you need doesn't exist yet, an operator sets it up with thecixCLI (cix ws create/add) or the dashboard; here you consume workspaces that already exist.
First: which server hosts the workspace?
A cix connection may reach more than one server (a local box, a remote
corporate backend, …). Each server hosts its own workspaces and projects — a
workspace named platform on one server is unrelated to anything on another.
cix_list_servers lists the configured servers. A workspace and all its repos
live on exactly one server. Decide which server you're on, then be consistent:
pass the same server argument to every call in the flow
(cix_list_workspaces, cix_workspace_search, and the per-project cix_search
drill-downs). Mixing servers mid-workflow silently returns empty or wrong-repo
results, because the project doesn't exist on the other server.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 238 lines · 110 tokens per session scan A ad5e01dc82b2
cix-workspace is a skill published in the GitHub repository dvcdsys/code-index (29 stars, last pushed 6d ago), licensed MIT. It adds 110 tokens to every session and 3,047 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
optimize-accuracy-first
Diagnose, design, implement, and validate system optimizations while treating correctness, retrieval quality, bounded behavior, and avoided downstream work as primary outcomes. Use for performance, latency, CPU, memory, storage, indexing, search, retrieval, caching, batching, concurrency, tokenizer, database, or…
using-jambavan
Use when Jambavan MCP tools (jambavanindex, jambavancontext, jambavanmemory) are available in the current session, or when you see .jambavan/ in the project root.
vibhishana-niti
Activate Vibhishana Niti — a severe senior-engineer discipline for shipping the minimum correct change. Use when the user asks for the smallest/simplest fix, a minimal diff, root-cause (not symptom) fixes, when a request seems larger than needed, or when they say "vibhishana niti". Deactivate when they say "normal…
root-cause-debugger
Use when investigating a bug, test failure, or unexpected behavior — before proposing any fix. Enforces observe/compare/hypothesize/fix phases to prevent guess-and-check thrashing. Escalates after 3+ failed fix attempts.
strict-reviewer
Use when reviewing a diff, PR, or set of changes — your own or someone else's. Applies a severe-senior-engineer review checklist (root cause vs. symptom, unrequested abstractions, missing tests/checks, unverified claims) instead of a superficial pass.
release-checker
Use before claiming tests pass, a build succeeds, a bug is fixed, requirements are met, or a release/PR is ready to ship. Demands fresh verification evidence instead of assumptions, confidence, or previous runs.