Hire an AI language server and indexing engineer
Tell it which languages and how big your codebase is. You get a design, draft code and tests to run.
What you give
- The languages in your codebase, and the size of each in files or lines
- What the tool must answer, such as definitions, references, hover text or call links, and who will use it
- Where it runs, such as laptops, a server or CI, and its memory limit (optional)
What you get
- A language server plan, one row per language, with what each can and cannot do
- A graph design with node and edge types and the rules that keep it consistent
- An index file format with one record per line
- An update plan using file watching, git hooks and caching
An example
You want one go-to-definition and find-references tool across a codebase with several languages.
You ask: “Tell it which languages and how big your codebase is. Use the material I attach and ask for anything essential that is missing.”
You get back:
- Goal and assumptions. What the tool answers, for whom, which languages come first and what the design assumes.
- Language servers. One row per language with the server, what it supports and how to confirm it.
- Graph design. Node and edge types and the rules that keep the graph consistent.
An example, not your task.
Hire this specialist
It is free and needs no account. Download the pack, give it to your AI and tell it the job. Your AI asks for anything it is missing, then does the work and checks it.
Related specialists
Details
Everything it can hand back
Your task sets the actual outputs. The specialist picks the methods that cover them.
- A language server plan, one row per language, with what each can and cannot do
- A graph design with node and edge types and the rules that keep it consistent
- An index file format with one record per line
- An update plan using file watching, git hooks and caching
- Speed targets for you to test, clearly marked as targets
- Draft code or config for the parts you ask for, and a test list
How it does the job well
- Follow the LSP specification for the version the chosen servers support. Check each server's reported abilities during start-up. Never assume a server supports a feature. Say "confirm this for your server and version".
- Plan the server life cycle: start, ready, shutdown, exit, and what happens when a server crashes.
- Graph rules to carry into the design: each symbol has exactly one definition node; every edge points to a node that exists; file nodes exist before the symbols they contain; import edges resolve to real files or modules; reference edges point to definition nodes.
- Use one ID for a symbol's definition location across the graph node, the index record, its references and its hover data. Each index line is one complete record.
- Updates must be all or nothing, so the graph is never half-changed. Cache widely, but clear exactly what changed.
- Read the existing code, its conventions and its tests before changing anything. Match the project's patterns.
- Make the smallest change that fully solves the request. Keep unrelated refactors out.
Mistakes it avoids
- Assuming a language server supports a feature without checking.
- Quoting speed targets as if they were results.
- An index where one symbol has two definitions, or an edge that points to nothing.
- Rebuilding everything on every file change.
- Claiming code works without running it or its tests.
- Inventing APIs, package versions or settings instead of checking the installed ones.
What a good result looks like
An example, not your task: You want one go-to-definition and find-references tool across a codebase with several languages.
- Goal and assumptions. What the tool answers, for whom, which languages come first and what the design assumes.
- Language servers. One row per language with the server, what it supports and how to confirm it.
- Graph design. Node and edge types and the rules that keep the graph consistent.
- Index format. The record types and fields, one record per line, sharing one ID with the graph.
- Update plan. How file changes trigger updates and how each update applies without leaving a half-written graph.
- Speed targets. Targets to test for each request type, and how to measure them.
How the work is checked
- The changed files build, and the relevant tests and linters pass. The commands and results are shown.
- Each change is explained in one line with its reason, and risky areas are named.
- Any check that could not run is reported as NOT_RUN with what it needs.
- States which checks passed, failed or could not run, and names missing inputs.
These checks have not been run against a model yet. Your AI uses them to check its own work.
Capabilities
- Set the goal. It states what the tool answers, for whom, and which languages come first. It asks once for missing facts, then marks them.
- Pick the language servers. It names a server per language and notes what each supports. It plans a check of each server's reported abilities, never an assumption.
- Design the graph and index. It sets node and edge types and the consistency rules. Each index line is one record that shares an ID with the graph node.
- Plan updates. It plans file watching, git hooks and caching, with updates that apply all at once or not at all.
- Plan tests and speed checks. It plans checks for consistency, server crashes and timing against targets you set.
How the role works
- Checks your task, context and available tools.
- Picks the methods needed and prepares a work plan.
- Carries out supported tasks, with each method's limits and review gates.
- Checks the real deliverables and corrects supported faults.
- Hands back files, evidence and unresolved gaps.
Your specialist's working setup
Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.
Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.
Use this specialist through MCP or the API
Call prepare_specialist with role_id lsp-index-engineer only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.
For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.
Complete ZIP: Download base specialist. API: GET /api/v1/specialists/lsp-index-engineer/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.
Inputs and helpful context
The specialist starts from the task brief. Only active methods require their inputs.
For the primary method, when used
- The languages in your codebase, and the size of each in files or lines
- What the tool must answer, such as definitions, references, hover text or call links, and who will use it
- Where it runs, such as laptops, a server or CI, and its memory limit (optional)
- What is slow or wrong today, with an example (optional)
- Your repository layout, such as a monorepo or several roots (optional)
Helpful context (optional)
- A list of the language servers your editors already use.
- A timed example of the slow request, so the design targets a real problem.
Tools and access
- Claude, ChatGPT or Gemini with file upload: It can read your repository layout and config files and match them to a server for each language.
Functions and deliverables
- Language server and indexing engineer: Plan a code search tool that gives go-to-definition and find-references across many languages, with language servers, a code graph and an index file.
- A language server plan, one row per language, with what each can and cannot do
- A graph design with node and edge types and the rules that keep it consistent
- An index file format with one record per line
- An update plan using file watching, git hooks and caching
- Speed targets for you to test, clearly marked as targets
- Draft code or config for the parts you ask for, and a test list
- Cross-tool search finder: Find where a decision or doc lives with one cross-tool search across your chat, email and files. You get one answer with sources.
- One merged answer across sources
- Links to each message, email or file
- Results ranked by how well they match
- A note on any tool that could not be searched
- AI tool definition writer: Describe a tool’s job and limits. Get its name, input schema, side-effect rules and test cases, with unclear or risky parts flagged.
- A name and description with use and non-use rules
- A checked parameter schema
- Confirmation, retry and error rules
- Test cases for tool choice and inputs
- Qdrant search speed tuner: Get a ranked list of Qdrant settings to change for faster search, faster uploads or lower memory, each with a test to run first.
- A short list of likely causes, most likely first
- Settings to change, each with why and what it might cost
- A test for each change, compared with your starting numbers
- A list of changes to avoid for your case
- AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
- A ready rules file for your project
- A list of which files to load for each task
- Rules for when to reset or trim the session
- A checklist for spotting drifting answers
Tasks you can use it for
- You want one go-to-definition and find-references tool across a codebase with several languages.
- Find-references in your editor is slow, wrong or missing on a large repository.
- You are building a code map or an AI coding helper that needs to know where each function is defined and used.
- You need an index that updates when files change, without a full rebuild.
Limits to check before starting
- You are new to a codebase and want to understand it. Use the Codebase onboarding planner or the Codebase history researcher.
- You want a code review of a change. Use the Code Reviewer agent.
- You want to build an editor plugin or command line tool for your team. Use the Developer tools engineer.
- Your graph is about documents and facts, not code. Use the Knowledge graph engineer.
Best way to use this role
Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.
- Download the pack and add it to your AI as a skill. If you cannot, paste SKILL.md and then references/source-agent.md into a new chat.
- List your languages, repository size and what the tool must answer. Say if some languages matter more than others.
- Type "Design the language server setup and index, then list how I test it." Your AI asks once for anything missing.
- Read the language server table first. Confirm each server exists for your language and your version before you build on it.
- Run the test list on a copy of your repository. Your AI cannot run servers or time them.
- Compare your measured times with the targets. Change the design only where the numbers say so.
Read it as data
Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/lsp-index-engineer for its role instructions and pinned sources.
This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.