RFC: Separate templates and skills into standalone repos

[webup]

Problem

When a user installs agentseek-cli globally via uv tool install and runs commands like agentseek create or agentseek skills add, the CLI clones the full ob-labs/agentseek repo (~30s) even though it only needs:

• templates/ for create
• skills/ for add

The rest of the repo (contrib packages, docs, examples, CI configs) is dead weight for these operations.

Current behavior

Command	What happens	What it actually needs
agentseek create langchain/default	Clones full repo to ~/.cookiecutters/agentseek/ (cached after first run)	Only templates/langchain/default/
agentseek skills add --all	Clones full repo via npx-skills	Only skills/ directory
agentseek skills list	Cloned full repo Now uses embedded catalogue (fixed in #66)	Nothing (offline)

Current mitigations

• agentseek skills list uses an embedded catalogue — zero network (feat(cli): smarter skills list and add defaults #66)
• agentseek create caches the clone in ~/.cookiecutters/ — only slow on first run
• --depth 1 is used by both cookiecutter and npx-skills

Options

Option A: One repo per template (LangChain model)

LangChain uses separate repos for each template (e.g. langchain-ai/react-agent, langchain-ai/retrieval-agent). We could do the same:

ob-labs/agentseek                          <- framework, CLI, contrib
ob-labs/agentseek-skills                   <- all skills (tiny, fast clone)
ob-labs/agentseek-template-research        <- one template
ob-labs/agentseek-template-sandbox         <- one template
ob-labs/agentseek-template-content-builder <- one template

Pros: Each template is independently versioned, starred, forked; create only clones what is needed; community can contribute templates without touching core.
Cons: Many repos to maintain; template index needed in CLI; harder to run cross-template tests.

Option B: Grouped template repos by framework

ob-labs/agentseek              <- framework, CLI, contrib
ob-labs/agentseek-skills       <- skills only
ob-labs/agentseek-templates    <- all templates in one repo (or per framework type)

Pros: Fewer repos than A; templates still independent of core.
Cons: Still clones all templates when you only need one.

Option C: Keep monorepo, optimize fetches

Use GitHub tarball API or git sparse-checkout to download only the needed subtree.

Pros: Single repo, single PR for everything.
Cons: Custom fetch logic; sparse checkout support varies across git versions.

Option D: Hybrid — separate skills only, keep templates

ob-labs/agentseek           <- framework, CLI, contrib, templates
ob-labs/agentseek-skills    <- skills only

Pros: Skills install becomes instant; templates stay co-located with tests; only one new repo.
Cons: Still clones full monorepo for create (mitigated by cache).

Considerations

• Templates are tightly coupled to CLI tests today — separating them requires test restructuring
• Skills are loosely coupled and change independently — strongest case for separation
• LangChain one-repo-per-template model works well for discoverability (each repo has its own README, stars, issues) but creates maintenance burden
• An index.json registry (like we have in templates/index.json) can point to external repos while keeping create seamless

Decision

Deferred. Recording for future discussion when the repo grows or community contributions increase.

[PsiACE]

option b looks great to me, so this repo can only focus on the core/contrib code.

and merge cli and agentseek code in a single package also a good choice. i will design the acts to make sure we only have one reasonable entrypoint