Slopweaver

A local-first, zero-key org world model for Claude Code — the own-your-data alternative to hosted enterprise search.

Point Slopweaver at your team's tools and it builds a queryable world model of their work, entirely on your machine: it ingests GitHub, Slack, Linear and Notion, runs a tiered bronze → silver → gold synthesis, lets you ask grounded, cited questions of it — and can post the answer back to Slack through a gated, audited path.

/slopweaver:onboard
/slopweaver:ask "what has the team shipped recently, and what's blocked?"

No API keys. No accounts. No server. Your world model never leaves the machine — and the two places anything does are named on the tin, not buried.

Why it's built this way

Slopweaver v1 was a hosted SaaS: 17 connected tools, behavioural fingerprinting, acceptance-rate dashboards. It worked, and I stopped using it — because the thing I actually wanted was my own data, on my own disk, answerable by the model session I was already paying for. Hosting it added a data boundary, an account, and a bill, and bought me nothing I valued.

So this is the rebuild, local-first and keyless from the first commit. The predecessor is preserved, read-only, at slopweaver/slopweaver-archive — including the features that didn't survive the pivot.

Two consequences worth stating plainly, because they're the whole design:

• Zero-key. Language-model calls run on your existing sessions — Claude via the claude CLI, and the optional codex verbs via your existing Codex OAuth login. Embeddings run on-device. Connector tokens are yours, stored locally at 0600, never passed through argv.

• Local-first, with the exceptions named. Your world model lives under $SLOPWEAVER_HOME. What leaves it: the source reads you authorise, the Claude calls you already make, the Slack messages you send, and — only if you run slopweaver codex — the prompts and diffs those passes send to OpenAI. Read-only sandboxing protects your filesystem; it does not keep data local. Full threat model: docs/security.md.

Related MCP server: conversation-history-mcp

Who builds it

This repo has no security certification and has not been audited. Worth saying first, because you should discount anything I claim about it accordingly.

What's behind it instead: I spent about two years as a DevSecOps engineer at a fintech SaaS, where I delivered SOC 2 Type 2 and ISO 27001:2022, rolled out Zero Trust across the organisation (Cloudflare Zero Trust, MDM, CrowdStrike Falcon), ran vulnerability management and supply-chain hardening, coordinated external penetration testers and handed their findings to the SOC 2 auditors — and led incident response on a real account compromise: contained within minutes of detection, every critical secret rotated within hours, then signed commits and repository rulesets enforced org-wide so it couldn't recur. Before that, six years building production systems; alongside it, the hosted predecessor to this project.

That's the reason the security posture here is structural rather than asserted, and you can check each of these rather than take my word for it:

• Least privilege, described at its weakest. The Codex sandbox is documented as protecting your filesystem and explicitly not your privacy. The admit door is documented as routing and audit, and not content policy, because its gate list is still empty. Both are places the honest description is the less impressive one.

• Evidence over assertion. Every side effect is routed through one door that records its decision, and a shipped ratchet fails the build if any seam escapes it — the same instinct as collecting audit evidence rather than claiming a control exists.

• Supply chain. Dependencies are exact-pinned and enforced by a constraint check; knip prunes unused packages; commits are signed. The same tools, for the same reason.

• Secret hygiene as a build gate. A hygiene scanner fails the build on absolute paths, token shapes and raw workspace IDs, so neither I nor a fork can commit an org's secrets. Connector tokens are 0600, read from a no-echo prompt, and never passed through argv.

• Tests that can actually fail. Integration tests replay recorded API cassettes with zero mocks, and a lint lane bans unfalsifiable assertions outright.

If you find a claim anywhere in this repo that is stronger than the code behind it, that's a bug and I want to hear about it — open a private security advisory.

— Lachie James · LinkedIn · github.com/lachiejames

What it does today

slopweaver catalog prints the live command surface — the number moves every release, so it is not repeated here.

Read — build and query the world model

Write — act on what it knows

slopweaver slack post | reply | edit | delete | progress — post a schema-enforced card as a bot or a drip as yourself, reply in a thread, edit or delete only messages slopweaver posted, or drive a live progress message that animates and then replaces itself. Every one routes through the admit door, which returns pass/warn/hold and records the decision. --dry-run renders without sending.

slopweaver slack read-thread <permalink> — paste a Slack link, get the whole thread: every message with its Block Kit content, and every readable attachment downloaded so the model can actually read the image, PDF or doc the thread is about. Complete or it fails — a partial thread is never returned. A read: it posts nothing and writes nothing into the corpus.

slopweaver linear issue create | update — file a Linear issue from a typed form, rendered by code rather than hand-written: Problem, Solution, optional acceptance criteria, and the collapsed Prompt for AI agents block, with media positioned inside the prose where it belongs. The issue id is derived from the content, so a retry after a lost response reuses it instead of filing a duplicate, and update touches only issues slopweaver created — refusing if the description changed since it last wrote. Same door, same --dry-run.

Operate — see the truth cheaply

audit (a zero-token, no-network quality + cost snapshot) · doctor (env preflight) · connect check (reachability + the exact scopes a source needs) · identity show|resolve · secrets set (no-echo, 0600, never argv) · seed (a synthetic, identifier-free demo corpus) · catalog · init

Build — a second model on the hard parts

slopweaver codex plan | review points Codex at planning and adversarial diff review while Claude writes every line. Codex reads your repo, runs commands, reaches the network and writes into its own scratch directory — it cannot write to the repository, which is the one line that keeps the two agents apart. Passes stream what they are doing, so a misrouted one is killed in seconds rather than forty minutes. It enforces the shape that works: one falsifiable property per call with the diff supplied, for the measured reason that a bounded review beats an unbounded one (51 seconds versus 1h50m with no verdict). Every pass writes one immutable artifact, so an answer is never truncated or lost with the process. This is the one part of Slopweaver that sends data to OpenAI — see docs/security.md and docs/codex-orchestration.md.

Roadmap

Shipped is above; this is the direction. Ordered by intent, not dated — and each item exists because running the thing exposed the need, not because a matrix demanded a cell.

Next

• Address Slack precisely — resolve a channel by name instead of an id, and read a whole channel or DM live on demand. (Reading one thread by link has shipped: slack read-thread.)

• slopweaver status — the project's own state as a verb: what's merged, what's in flight, what the record claims versus what the tree actually contains.

• Catch-up — refresh + derive in one command, reporting the delta since last time and warning when a corpus is approaching an engine limit.

Then

• Write to the rest of the stack — GitHub pull requests and Notion pages, each through the same door as Slack and Linear.

• Proof objects — a graded, content-checked evidence artifact attached to what the agent claims.

• A belief layer — sourced, confidence-weighted facts with cite-or-abstain, so a wrong answer abstains instead of sounding confident.

• Feedback → gate — a correction becomes a proposed rule, you approve it, and it becomes a real gate plus a test on the door. This is where the door's empty gate list gets filled.

• Voice — per-person tone and anti-slop enforced on shape, never by scanning prose.

Later

• Long-form Slack canvases (deferred, not cancelled) · telemetry and dashboards · unattended operation, which needs everything above before it deserves to exist.

Install (as a Claude Code plugin)

/plugin marketplace add /path/to/slopweaver
/plugin install slopweaver@slopweaver-dev

On first session the plugin installs its own dependencies into its plugin-data dir (one-time, ~a minute) — you don't run npm install. Requires Node + Corepack/Yarn and the claude CLI (you already have it). Then run /slopweaver:onboard to build your first world model.

If your organisation restricts plugin marketplaces

Many do, and the block is invisible until you hit it — an enterprise policy can disallow adding personal marketplaces, so /plugin marketplace add simply doesn't take. Clone and load from disk instead:

git clone https://github.com/slopweaver/slopweaver.git
claude --plugin-dir ./slopweaver

That loads every skill and command in the repo for that session, namespaced the same way (slopweaver:ask, slopweaver:refresh, …). It's also the better loop if you're developing Slopweaver, since it always runs the code on disk rather than an installed copy. Pass --plugin-dir more than once to load several plugins; passing the same directory twice is tolerated. To make it permanent, set CLAUDE_LOCAL_PLUGINS in your shell profile rather than typing the flag each time.

Note the optional Codex SDK ships a platform binary (~300MB), so a first install is not instant. Embedding inference is pure WASM, so the same plugin works on macOS, Linux and Windows on any CPU architecture.

Trust

The biggest objection to any tool that ingests company data is "where does it go?" — for the world model, nowhere you don't already send it. Concretely:

• A shipped hygiene gate scans every tracked file for leak classes (secrets, absolute paths, raw workspace IDs) and runs in CI + a local pre-push hook, so neither you nor a fork can commit your org's secrets. It names no organisation; you scope your own private literals through a local denylist.

• The write path is disclosed, not implied. Slopweaver can post to Slack as a bot or as you. It can only edit or delete its own messages. There is no scheduler and no listener — every message is one command you ran.

• The claims are stated at their weakest. Codex's sandbox protects your repository, not your privacy. The admit door proves every write is routed and recorded, but its content gates are not built yet, so "gated" does not yet mean "content-checked".

• Grounded, not hallucinated. Every answer cites the records it's built from; a citation the model can't back is stripped, not shown.

Full threat model + data-flow: docs/security.md.

Development

Requires Node (see .nvmrc) and Yarn 4 (via Corepack — corepack enable once).

yarn install
yarn slopweaver doctor  # smoke-test the CLI
yarn validate           # the full local gate: lint + typecheck + tests + coverage ratchet

yarn validate is the one-command local CI, and the pre-push hook runs it. The static-analysis bar is deliberately high: Biome, Prettier, oxlint, ESLint (type-aware), knip, dependency constraints, plus seven bespoke ratchets that machine-enforce the house rules — including the hygiene gate, the door-coverage proof, and a testing-discipline lane that bans mocks and unfalsifiable assertions in tests.

Architecture: docs/architecture.md · Contributor rules: AGENTS.md.

License

MIT — see LICENSE.