Grow domain knowledge out of your daily AI work with the free, open-source NeatContext plugin — for Claude Code, Codex, Kimi Code, and pi. When it outgrows one machine, NeatContext Desktop manages it for the whole team.
MIT-licensed plugin Your AI, selected context Local-first by default
STEP 01 · FREE AND OPEN SOURCE
You already build domain knowledge.
Every session with an AI agent, you explain your systems, your rules, your decisions — then it's gone. The NeatContext plugin turns those conversations into domain knowledge you keep and reuse.
Saving and reconnecting domain knowledge from inside Claude Code.
Install in seconds — MIT licensed, source on GitHub.
In your terminal
claude plugin marketplace add https://github.com/XTSoftwareLabs/neatcontext-plugins.git
claude plugin install neatcontext@neatcontext --scope user
Once that knowledge is real, it needs owners and boundaries. NeatContext Desktop turns a growing pile of files into Contexts each team can connect to — and serves only the ones you choose.
Contexts per teamGroup profiles and knowledge folders by team, service, or customer.
One team libraryShared read-only and distributed like any other repo.
Read-only toolsAllowlisted MCP connectors for the internal systems you rely on.
Activity logsA per-Context record of exactly what was served, kept locally.
Connects ChatGPT Desktop, Claude Desktop, Claude Code CLI, and Codex CLI.
09:07 UTC: checkout-api starts throwing 5xx and INC-1001 opens. The Infra Team on-call asks an AI client the same question with and without NeatContext: “What should we check first, and what is the safe action?”
Connected AI · grounded by NeatContextinfra-team profile · knowledge/infra-team attached
Root cause found: the 08:58Z pool-size cut. Revert it with a RELOAD.
Evidence, checked with read-only tools
The deploy log shows default_pool_size 100 → 40 on pgbouncer at 08:58Z — minutes before the first checkout-api 5xx.
Logs confirm the pool saturated at 40/40 with clients queuing — the exact signature of postmortem INC-0977.
The Postgres primary is healthy and far below max_connections=200 — the ceiling is the pool setting, not the database.
Safe actions
Revert default_pool_size to 100 and RELOAD pgbouncer — zero dropped connections.
Do not fail over the primary — the TSG forbids failover for saturation; it would drop every in-flight connection and widen the outage.
Watch the pool drain and confirm checkout-api 5xx returns to baseline.
Cites the exact runbook and TSG linespostgres-connection-pool.md:38-42db-failover-tsg.md:6-9inc-2026-0511-pool-sizing-regression.md:40-44
✳
AI client · without NeatContextNo profile · no runbooks · no team context
Elevated 5xx can have many causes — here is a general checklist.
Review recent application deployments and roll back if anything looks suspicious.⚠The app deploy is innocent — the change that matters is the 08:58Z pgbouncer pool-size cut, which only the team's deploy log and runbook point to.
Check database health; if connections are stuck, restart the database or fail over to a replica.⚠Failing over a saturated-but-healthy primary drops every in-flight connection across every service — db-failover-tsg.md forbids exactly this.
Increase max_connections on Postgres to relieve the pressure.⚠Wrong knob: the pgbouncer pool ceiling is the constraint. Raising max_connections just moves the failure into the database.
Check the logs for errors and escalate to the appropriate team if the issue persists.
∅ No sources cited — generic best practice, nothing to verify.
EXAMPLE 02 · KNOWLEDGE PER TEAM
Different team, different knowledge, a different right answer.
The same INC-1001, handled differently by each team. Grounded in a team's own knowledge, the connected AI gives each its right move: for Payments a hand-off with evidence, for Infra the fix.
Not a Payments root cause — hand off to Infra Team, with evidence.
Evidence, checked with read-only tools
First pool error at 09:02:08Z predates our 09:05:00Z checkout-api deploy — rolling back would fix nothing.
Stripe is healthy: status green, health probe 200 OK — the payment provider is ruled out.
Dominant error is pgbouncer: pool 'billing' is full (40/40) — shared infrastructure we consume but do not own.
Safe actions
Escalate to Infra Team with the incident link, the first pool-error log line, and the deploy timeline — the same play that resolved INC-0931 in 19 minutes.
Interim relief only: disable stripe_webhook_auto_retry — a flag flip, no restart needed.
Do not restart invoice-worker before 10:00Z — daily settlement is mid-flight, and interrupting it can double-charge customers.
Grounded in payments-team knowledgecheckout-api-5xx.md:37-46service-ownership.md:28-42inc-2026-0418-checkout-5xx-handoff.md:35-41
Infra Team · infra-team + knowledge/infra-team
Root cause: the 08:58Z default_pool_size 100 → 40 cut on pgbouncer.
Evidence, checked with read-only tools
demo_list_deployments shows our default_pool_size 100 → 40 change at 08:58Z; the first checkout-api 5xx follows at 09:02:08Z.
billing-postgres logs show pool 'billing' is full (40/40) with clients queued — the exact INC-0977 signature.
The primary is healthy (CPU ~60%, well under max_connections=200) — the pool ceiling we set is the constraint.
Safe actions
Revert default_pool_size to 100 and RELOAD pgbouncer — in INC-0977 the pool drained in ~90 seconds with zero dropped connections.
Do not fail over the billing-postgres primary — the TSG forbids failover for saturation; it would widen the outage.
Confirm checkout-api 5xx returns to baseline, then alert on pool utilization above 80%.
Grounded in infra-team knowledgepostgres-connection-pool.md:38-42db-failover-tsg.md:6-9inc-2026-0511-pool-sizing-regression.md:40-44
✳
The same AI client without NeatContext, asked by either team
“Check the logs, review recent changes, verify database health, and escalate to the appropriate team if needed.”
One checklist for every team. Without payments-team or infra-team knowledge it cannot decide ownership like Payments — or name the exact pool-size revert like Infra.
CONTEXT CHANGES EVERYTHING
Give your AI the knowledge it's been missing.
Keep working in the AI client you already use. Add the operational context only your team knows.
01
◇
Shape your domain
Let the NeatContext plugin turn finished sessions into focused Markdown profiles per service, product, or customer.
02
▱
Organize in Desktop
Group profiles and local knowledge folders into Contexts, and add allowlisted read-only internal tools.
03
⌁
Open your AI client
Connect a Context, ask there, and inspect NeatContext's local activity log when needed.
BUILT FOR REAL OPERATIONS
Lightweight by design. Flexible by nature.
Start with the free plugin and a folder of runbooks. Add Contexts, knowledge, and internal tools only when you need them.
⌁
Use your existing AI
Open a fresh, Context-pinned session in a supported local AI client.
◇
Profiles are Markdown
Easy to write, review, version, and change as your systems evolve.
⇄
Connect instantly
Add read-only MCP tools for the operational systems your team relies on.
＋
Extend as you grow
No rigid catalog. Compose the right context for each workflow and domain.
YOUR DESKTOP
MDLLMMCPKB
LOCAL-FIRST, ALWAYS
Your context stays under your control.
Profiles, Context definitions, runtime files, and activity logs stay on your machine by default. NeatContext hands selected paths and tools to your chosen client without hosting your incident data or running another model.
Local profiles and linked knowledge
Allowlisted read-only tools
No NeatContext model or model credentials
READY WHEN YOU ARE
Turn local knowledge into useful answers.
Start free with the plugin. Move to the desktop app when your team needs to manage it.
