NeatContext plugins

Extract domain knowledge and save useful work from Claude Code, GitHub Copilot, Kimi Code, Codex, or pi conversations as structured, reusable context that you can use in later sessions or share with others.

<strong>▶ Watch the NeatContext demo</strong>

Why NeatContext?

Domain knowledge is what helps an LLM answer accurately for your team—your systems, constraints, decisions, terminology, and ways of working.

You naturally build that knowledge while doing hard work with a coding agent. Long conversations about debugging, planning, incidents, and implementation already contain discoveries that will matter again. NeatContext extracts the durable knowledge from those conversations and saves it as a structured context.

Connect that context in a new session or during later work, and the coding agent can start with the knowledge it needs instead of asking you to explain everything again. You can also share the context with teammates, so the whole team benefits from what one person learned.

Install

Claude Code

claude plugin marketplace add https://github.com/XTSoftwareLabs/neatcontext-plugins.git
claude plugin install neatcontext@neatcontext --scope user

GitHub Copilot (CLI and VS Code)

See NeatContext for GitHub Copilot.

Kimi Code

See NeatContext for Kimi Code.

Codex

See the Codex marketplace README.

pi

See NeatContext for pi.

Quick start: reuse a complex investigation

The walkthrough below uses Claude Code.

Suppose you work through a difficult production issue with Claude:

You: Some orders take ten minutes to update, but overall queue lag looks normal.
     Help me investigate.

Claude: Let's correlate Order API traces, the order-events consumer metrics,
        and the order-projection worker logs. Start with per-partition lag
        instead of the aggregate metric.

You: Grafana shows that partition 17 is falling behind while the others are
     healthy. Tempo traces show the Order API publishes events without delay.

Claude: Check the Loki logs for the order-projection workers on partition 17.
        Look for deserialization time, payload size, and the producing service.

You: The worker logs show 12-second deserialization times for large events from
     catalog-sync. Its logs confirm that bulk updates for tenant-42 all use the
     same partition key. Splitting those updates cleared the lag.

Claude: The root cause was a hot partition: large catalog-sync events blocked
        later order events, while the aggregate lag metric hid the problem. For
        similar issues, check per-partition lag, traces from the producing
        service, worker deserialization logs, payload size, and partition keys
        before scaling consumers.

This is the useful work you may want to save. Run /neatcontext:save event-partition-investigation: