Feature: Cross-project knowledge sharing for docs/solutions/

[flacoste]

Summary

The ce:compound → docs/solutions/ → learnings-researcher → ce:plan/ce:review pipeline builds a valuable knowledge store per repo. But learnings from one project are invisible when working in another project. The learnings-researcher only searches the current repo's docs/solutions/.

For users who work across multiple related projects (e.g., multiple Obsidian vaults with similar agent/skill workflows, a main app + supporting repos, or a monorepo user who splits into multiple repos), lessons learned in one project should be discoverable in the others.

Use Case

I maintain multiple Obsidian vaults with Claude Code skills. Over 40+ documented solutions in one vault cover patterns like:

• Agent/skill design (gate language, delegation, compliance)
• MCP integration patterns (KanBox, Slack, email)
• Token optimization (CLI bypass, subagent delegation, batch pre-computation)
• Enrichment workflow patterns

When I start a new vault or work in a different codebase with similar patterns, none of these learnings are discoverable. The learnings-researcher searches only the local docs/solutions/, finds nothing, and the agent starts from scratch.

Current Workarounds

Approach	Limitation
Symlink docs/solutions/ from another repo	learnings-researcher only searches docs/solutions/, not docs/shared-solutions/ or other paths
Copy files on project init	Snapshot in time — diverges immediately, no sync
User-level ~/.claude/CLAUDE.md with path hint	Fragile — depends on agent choosing to read an external path
Symlinked .claude/rules/	Rules are loaded into every conversation (context cost), no structured search via frontmatter

None of these integrate with the compound pipeline — the learnings-researcher doesn't know to look outside docs/solutions/.

Suggested Approaches

Option A: Configurable solutions_paths (lightweight)

Allow AGENTS.md (or CLAUDE.md) to declare additional solution directories the learnings-researcher should search:

# In AGENTS.md or a plugin config
solutions_paths:
  - docs/solutions/           # local (default)
  - ~/src/other-project/docs/solutions/  # cross-project

The learnings-researcher searches all listed paths. Results from external paths are tagged with their source so the agent knows they may need adaptation.

Option B: ce:compound-export / ce:compound-import (curated)

• ce:compound-export — Curate a subset of docs/solutions/ into a portable bundle (strip repo-specific file paths, keep patterns and guidance)
• ce:compound-import — Import a bundle into a new project's docs/solutions/, adapting references to the local codebase

This is more work but produces cleaner cross-project docs since repo-specific details (file paths, component names) are adapted.

Option C: Global solutions directory (simple)

Support a user-level ~/docs/solutions/ (or configurable path) that the learnings-researcher always searches in addition to the local docs/solutions/. Users manually symlink or copy their most portable learnings there.

Related Issues

• Enhancement: Add project scaffolding for docs/solutions/ schema + agentic feedback loops #111 — Project scaffolding for docs/solutions/ (same theme: bootstrapping the knowledge store)
• Closed-Loop Self-Improvement System #171 — Closed-loop self-improvement (proposed knowledge seeding, but repo-local)

Impact

Without cross-project sharing, the compound philosophy ("each unit of work makes subsequent units easier") resets to zero at project boundaries. The first project compounds knowledge beautifully; the second project starts from scratch even when the same user has already solved similar problems.

[tmchow]

I like this and aligned with what we've been talking about. I think for many sources, it'll be best for us to create separate agents as there are nuances to each one that may warrant different processing and context. For example, I'm building a slack researcher right now.

I think it could be interesting to expand it to just file paths in some preference setting but I worry about this getting out of hand with point to a root folder with way too many documents for example. Any thoughts about this?

[flacoste]

I think it could be interesting to expand it to just file paths in some preference setting but I worry about this getting out of hand with point to a root folder with way too many documents for example. Any thoughts about this?

Good question — I think the volume concern is solvable if we control what goes into the shared location rather than controlling what gets read from it. The grep pre-filter in learnings-researcher already handles scale well; the real problem is relevance, not volume.

Here's what I'm thinking:

A ce:compound-export step + a shared-learnings-researcher agent

The pipeline would extend naturally from what already exists:

1. ce:compound — document what happened (already exists)
2. ce:compound-refresh — consolidate within the repo (already exists)
3. ce:compound-export (new) — extract generalizable patterns into a shared location
4. shared-learnings-researcher (new) — search the shared location from any project

Export as the curation gate

ce:compound-export is the key piece that addresses your volume concern. It's a judgment call, not a bulk copy — it looks at docs/solutions/ and asks: "which of these are transferable patterns vs. repo-specific incidents?" For example:

• Generalizable: "Subagent skills need explicit stop signals or they over-help" → export
• Repo-specific: "KanBox pagination uses cursor not offset" → stays local

The exported docs get stripped of repo-specific file paths and component references, keeping the pattern and the lesson. This means the shared location stays curated and relevant regardless of how large any individual project's docs/solutions/ grows.

shared-learnings-researcher as a separate agent

This fits your pattern of source-specific researchers (like the Slack researcher). It:

• Searches a configurable shared solutions path (default ~/.claude/shared-solutions/, overridable in settings)
• Uses the same grep-first pre-filtering as learnings-researcher
• Tags results with their source project so the consumer knows to adapt
• Runs in parallel alongside the local learnings-researcher in ce:plan / ce:review / ce:ideate

The separation keeps the local researcher fast and focused, while the shared researcher handles cross-project schema variation independently.

Config

Minimal setup — a setting for the shared solutions path:

{
  "shared_solutions_path": "~/.claude/shared-solutions/"
}

Default works out of the box. Users who want version control can point it at a git repo.

Why this over just configurable paths

Pointing learnings-researcher at raw external docs/solutions/ directories has two problems: (1) your volume concern — someone points at a huge tree, and (2) relevance — docs from a Rails app reference BriefSystem and rails_controller, which are noise in a different project. The export step solves both by curating and normalizing at write time.