Organize with collections

A collection is a project — a named group of related documents (an FRD, its specs, the design docs, the vendor API reference). Collections keep retrieval focused: instead of searching your entire library, your agent can scope to just the project at hand.

List your projects

List my LLMtoMD collections.

This calls list_collections and shows each project with its document count.

File documents under a project

Most add operations accept a project name. When you convert or save, just say where it goes:

Convert https://docs.vendor.com/api and put it in my "Vendor API" project.

Save this README under my "Billing service" project.

If the project doesn't exist yet, refer to it by name and create it from the dashboard, or ask your agent to file documents under a consistent name as you go.

Scope search and ask to a project

This is where collections pay off — retrieval stays on-topic:

Search my "Billing service" project for the dunning flow.

Based on my "Vendor API" project, what's the pagination scheme?

Both search_documents and ask_documents accept a collection, so answers come only from that project's documents.

Load a whole project as context

At the start of a session, pull an entire project in with the load_project prompt:

Load my "Billing service" project from LLMtoMD.

Your agent now has the project's documents as working context — useful when you're about to make a series of related changes and want the spec in front of it the whole time.

A workflow that works well

1. Start a project for each real body of work (a service, a client, a research area).
2. Convert/save its source documents into that collection as you gather them.
3. load_project at the start of a coding session.
4. ask/search scoped to the project whenever a requirement is unclear.

This turns LLMtoMD into per-project memory your agent consults instead of guessing.

Related

• Search & ask — scoped retrieval.
• Tools reference — list_collections, load_project.