How do I install the Neatcontext Extensions skill?

Run npx skillmds@latest add xtsoftwarelabs/neatcontext-extensions in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Neatcontext Extensions safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Neatcontext Extensions?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Neatcontext Extensions free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Neatcontext Extensions?

XTSoftwareLabs (@xtsoftwarelabs) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Neatcontext Extensions by xtsoftwarelabs

Name: Neatcontext Extensions
Author: XTSoftwareLabs

Neatcontext Extensions

Report which extensions the connected NeatContext context expects, and whether this machine provides them. Use when the user asks what a context can reach, why an extension tool is missing, or how to connect one here.

File contents

Context extensions

The bundled CLI path and Kimi session id below are expanded by Kimi Code at skill activation. Run:

KIMI_PLUGIN_ROOT="${KIMI_SKILL_DIR}/../.." kimi __plugin_run_node "${KIMI_SKILL_DIR}/../../src/kimi/neatcontext-cli.mjs" -- --session-id "${KIMI_SESSION_ID}" extensions

Relay the report. Two separate things are being reported, and the difference matters:

What the context expects — the extension it declares and the capability that provides. This travels with the context and is the same on every machine it reaches.
What this machine provides for it. That is local, hand-written, and lives in the bindings file the report names. Nothing configures it automatically, and nothing inside a shared context can configure it.

If something is reported as not configured, show the example binding from the report and say where the file goes. Tell the user to keep credentials in the environment and name them under envFrom rather than writing them into the file.

If an extension is reported as unavailable or failed, relay the reason exactly as given — a command that is not there, a server that did not answer — and do not guess at a fix beyond what the report says.

Say plainly that the context still works: its profile and knowledge folder are served whether or not any extension is configured.

To record that this context expects something new:

KIMI_PLUGIN_ROOT="${KIMI_SKILL_DIR}/../.." kimi __plugin_run_node "${KIMI_SKILL_DIR}/../../src/kimi/neatcontext-cli.mjs" -- --session-id "${KIMI_SESSION_ID}" extensions add <id> --capability "<what it lets this context do>"

Add --tools a,b to narrow it to specific tools, and --important when the context leans on it. That records what the context wants; it connects nothing on its own. extensions remove <id> drops the declaration and leaves any local binding alone, and extensions test <id> starts one on purpose and names the tools it really offers.

---name: neatcontext-extensionsdescription: Report which extensions the connected NeatContext context expects, and whether this machine provides them. Use when the user asks what a context can reach, why an extension tool is missing, or how to connect one here.---# Context extensionsThe bundled CLI path and Kimi session id below are expanded by Kimi Code at skill activation. Run:```textKIMI_PLUGIN_ROOT="${KIMI_SKILL_DIR}/../.." kimi __plugin_run_node "${KIMI_SKILL_DIR}/../../src/kimi/neatcontext-cli.mjs" -- --session-id "${KIMI_SESSION_ID}" extensions```Relay the report. Two separate things are being reported, and the difference matters:- What the **context** expects — the extension it declares and the capability that provides. This travels with the context and is the same on every machine it reaches.- What **this machine** provides for it. That is local, hand-written, and lives in the bindings file the report names. Nothing configures it automatically, and nothing inside a shared context can configure it.If something is reported as not configured, show the example binding from the report and say where the file goes. Tell the user to keep credentials in the environment and name them under `envFrom` rather than writing them into the file.If an extension is reported as unavailable or failed, relay the reason exactly as given — a command that is not there, a server that did not answer — and do not guess at a fix beyond what the report says.Say plainly that the context still works: its profile and knowledge folder are served whether or not any extension is configured.To record that this context expects something new:```textKIMI_PLUGIN_ROOT="${KIMI_SKILL_DIR}/../.." kimi __plugin_run_node "${KIMI_SKILL_DIR}/../../src/kimi/neatcontext-cli.mjs" -- --session-id "${KIMI_SESSION_ID}" extensions add <id> --capability "<what it lets this context do>"```Add `--tools a,b` to narrow it to specific tools, and `--important` when the context leans on it. That records what the context wants; it connects nothing on its own. `extensions remove <id>` drops the declaration and leaves any local binding alone, and `extensions test <id>` starts one on purpose and names the tools it really offers.

Frequently asked questions