We get a lot out of CE's learning capture, but our repo layout makes the file-based corpus hard to use.
We work out of a central planning repo. Sessions clone whichever service repo the work is in, but CE itself is invoked from the planning repo. So the learnings a session produces are about the cloned repo, while <root>/solutions/ lives in the planning repo — the corpus and the code it describes are never in the same checkout. Keeping a markdown copy in step across that boundary means it drifts, and a drifted corpus is worse than an empty one: CE retrieves a stale snapshot that reads as authoritative.
We've built a central knowledge store for this, served over MCP. It has its own review gate, retrieval, and provenance. We'd like CE to read from it and write to it rather than the docs directory — and we'd very much rather not maintain a fork to do it.
Proposal
A config entry naming a backend for learnings. Unset, behaviour is byte-identical to today; <root>/solutions/ stays the default.
learnings_backend: mcp # files (default) | mcp
learnings_retrieval_tool: <tool> # called instead of grepping <root>/solutions/
learnings_capture_tool: <tool> # called instead of writing a solution file
Declarative on purpose — configuration.md says config shouldn't carry credentials, CLI commands, or harness flags, so CE would only ever name tools the harness has already registered and authenticated. CE wouldn't configure a server or handle a credential.
Retrieval looks self-contained
If the backend returns the same distilled findings shape learnings-researcher.md already produces, ce-plan, ce-code-review, ce-ideate, and ce-optimize shouldn't need changes at all.
Capture has a real question in it, so here's our proposed answer
Rather than leave it open: when a backend is configured, the backend owns lifecycle.
ce-compound hands the learning over and stops. It doesn't run the overlap-driven update-in-place decision, because the backend is better placed to know its own corpus. ce-compound-refresh reports that lifecycle is externally owned rather than trying to classify entries it can neither enumerate nor mutate.
We're not asking you to make ce-compound-refresh work over MCP — that would be a port of the whole skill. We've implemented your five-outcome model (Keep / Update / Consolidate / Replace / Delete, plus a stale mark for "couldn't tell") in our own store, precisely because it's the right model. What we need from CE is the documented hand-off, not the mechanism.
Things we don't think need to change
CONCEPTS.md stays repo-local — it's shared vocabulary, not a learning.- The grounding-validation pass still works; it validates claims against the current tree rather than against the store.
- The Discoverability Check's advice would presumably need to point somewhere other than
<root>/solutions/ when a backend is set.
Prior art
This feels like the same move docs_root made for artifact location, applied to learnings source and sink.
Offer
We're glad to do the work if this is a shape you'd accept, and happy to split it — retrieval first, capture as a follow-up — if you'd rather review it in two pieces.
Would welcome a steer on naming, on whether MCP tool references in config are the right seam, and on whether the lifecycle hand-off above is how you'd want it drawn.
We get a lot out of CE's learning capture, but our repo layout makes the file-based corpus hard to use.
We work out of a central planning repo. Sessions clone whichever service repo the work is in, but CE itself is invoked from the planning repo. So the learnings a session produces are about the cloned repo, while
<root>/solutions/lives in the planning repo — the corpus and the code it describes are never in the same checkout. Keeping a markdown copy in step across that boundary means it drifts, and a drifted corpus is worse than an empty one: CE retrieves a stale snapshot that reads as authoritative.We've built a central knowledge store for this, served over MCP. It has its own review gate, retrieval, and provenance. We'd like CE to read from it and write to it rather than the docs directory — and we'd very much rather not maintain a fork to do it.
Proposal
A config entry naming a backend for learnings. Unset, behaviour is byte-identical to today;
<root>/solutions/stays the default.Declarative on purpose —
configuration.mdsays config shouldn't carry credentials, CLI commands, or harness flags, so CE would only ever name tools the harness has already registered and authenticated. CE wouldn't configure a server or handle a credential.Retrieval looks self-contained
If the backend returns the same distilled findings shape
learnings-researcher.mdalready produces,ce-plan,ce-code-review,ce-ideate, andce-optimizeshouldn't need changes at all.Capture has a real question in it, so here's our proposed answer
Rather than leave it open: when a backend is configured, the backend owns lifecycle.
ce-compoundhands the learning over and stops. It doesn't run the overlap-driven update-in-place decision, because the backend is better placed to know its own corpus.ce-compound-refreshreports that lifecycle is externally owned rather than trying to classify entries it can neither enumerate nor mutate.We're not asking you to make
ce-compound-refreshwork over MCP — that would be a port of the whole skill. We've implemented your five-outcome model (Keep / Update / Consolidate / Replace / Delete, plus a stale mark for "couldn't tell") in our own store, precisely because it's the right model. What we need from CE is the documented hand-off, not the mechanism.Things we don't think need to change
CONCEPTS.mdstays repo-local — it's shared vocabulary, not a learning.<root>/solutions/when a backend is set.Prior art
This feels like the same move
docs_rootmade for artifact location, applied to learnings source and sink.Offer
We're glad to do the work if this is a shape you'd accept, and happy to split it — retrieval first, capture as a follow-up — if you'd rather review it in two pieces.
Would welcome a steer on naming, on whether MCP tool references in config are the right seam, and on whether the lifecycle hand-off above is how you'd want it drawn.