Skip to main content
Most teams integrate Niadra with a coding assistant at their side. Two files serve it:
  • The niadra skill, at /skill/niadra/SKILL.md: the script an assistant follows to connect a repository to Niadra. Find the model call and where the customer’s identifier comes from, pick the right adapter from the table, wire the five primitives, test against the emulator and go through the final checklist. It follows the skill format Claude Code, Cursor and Codex read (a SKILL.md with name and description in its front matter).
  • llms.txt, at /llms.txt: the whole documentation as a plain-text list of pages, with the block “If you are an AI agent integrating Niadra” and the link to the skill. Every page of this documentation is also served as Markdown at the same address with .md at the end, and the button at the top of each one copies it to your assistant.

​
Load the skill

The skill is the same for the three assistants: it does not depend on the editor, only on the assistant being able to read the repository and run the emulator. It asks for a sandbox key in the NIADRA_API_KEY variable and never writes it to a file.

​
What the skill does and does not do

It connects the agent the repository already has: it does not swap the model, rewrite the prompt or choose the vendor. It insists on three rules assistants tend to get wrong on their own: the customer never comes from the model, Niadra never fails the agent (so no retries of your own around the calls), and the instructions stay before the context, so they remain the prefix the provider caches. For the assistant to query the memory while it works, not only integrate it, connect the space’s MCP server to the editor: Claude Code, Claude Desktop, Cursor and VS Code.

​
Next steps

Integrations

the adapter table the skill consults.

Quickstart

the sandbox key the skill asks for.