Shared Context Collections

Share coding standards, business libraries, client context, and prompt templates across your team. Ensure consistent LLM responses that follow your organization's guidelines and reuse approved business knowledge without confusing it with current client truth.

What Are Shared Context Collections?

Shared Context Collections are reusable documentation packages that can be linked to multiple projects. When your LLM queries Snipara, it automatically receives your team's coding standards, reusable business knowledge, and project-specific client documentation in the right order.

┌─────────────────────────────────────────────────────────────┐
│  HOW SHARED CONTEXT WORKS                                   │
│                                                             │
│  Query: "How should I handle errors?"                       │
│                    ↓                                        │
│  1. Load Shared Context (30% of token budget)               │
│     → MANDATORY rules from team standards                   │
│     → BEST_PRACTICES patterns                               │
│     → GUIDELINES suggestions                                │
│                    ↓                                        │
│  2. Query Project Docs (remaining 70% of budget)            │
│     → Project-specific documentation                        │
│     → Search by query relevance                             │
│                    ↓                                        │
│  3. Return Combined Context                                 │
│     → Shared context FIRST, then project docs               │
│     → LLM follows team standards automatically              │
└─────────────────────────────────────────────────────────────┘

Business Library vs Client Context

The same shared-context system now supports business delivery workflows. Use Business Library for reusable knowledge and Client Context for the active project or client.

Snipara also keeps a Business Response Playbook as mandatory team context for business/client projects. New client projects created from the dashboard or with snipara_create_client_project automatically link to that playbook, so agents know how to rank current RFP files, client-specific context, reusable templates, and historical examples before drafting a response.

Context health uses the same metadata to identify stale snapshots, missing historical provenance, parser drift, and artifact quality issues. A direct customer sees those signals in the dashboard; an integrator can surface the same signals through their own product or MCP wrapper.

Snipara only applies Business Context freshness pressure to active client projects. Past client archives stay searchable as reusable precedent, and internal business projects keep their own work area without being treated as current client truth.

Collection Scopes

Collections can be scoped to different visibility levels:

Document Categories

Documents within a collection are categorized by importance. The category determines token budget allocation and priority:

Token Budget Allocation

In snipara_context_query, session context is included first when present. Shared context is then queried before local project documents with 30% of the remaining budget by default, configurable via shared_context_budget_percent.

Example: 4,000 max_tokens with no session context

Shared Context Budget (30% = 1,200 tokens):
├── MANDATORY:       480 tokens (40% of shared)
├── BEST_PRACTICES:  360 tokens (30% of shared)
├── GUIDELINES:      240 tokens (20% of shared)
└── REFERENCE:       120 tokens (10% of shared)

Project Docs Budget (70% = 2,800 tokens):
└── Ranked by relevance to query

Priority Order:
1. Collection priority (lower number = higher priority)
2. Category priority (MANDATORY > BEST_PRACTICES > ...)
3. Document priority within category
4. Query relevance for non-MANDATORY shared documents

If a shared category does not use its full allocation, remaining shared-context budget can be filled by other eligible shared documents. Project-specific context is treated as the more specific source when it conflicts with shared context.

MCP Tools

Five MCP tools are available for working with shared context:

snipara_shared_context({

  query: "How should I handle errors?",

  max_tokens: 4000,

  categories: ["MANDATORY", "BEST_PRACTICES"]

})

snipara_list_templates({

  category: "refactoring"

})

→ [{ slug: "extract-method", name: "Extract Method" }, ...]

snipara_get_template({

  template_slug: "security-review"

})

→ { prompt: "Review {{file_path}} for security issues...", variables: ["file_path"] }

snipara_list_collections()

→ {

  collections: [

    { id: "col_abc123", name: "Team Standards", access_type: "team_member" }

  ],

  count: 1

}

snipara_upload_shared_document({

  collection_id: "col_abc123",

  title: "Error Handling Standards",

  content: "# Error Handling\n\nAll errors must...",

  category: "BEST_PRACTICES"

})

→ { success: true, action: "created" }

Creating Collections

You can create and manage collections from the Snipara dashboard:

1. Open Workspace Contextfor reusable business and code context, or open a project's Context tab for project-linked collections
2. Click Create Collection and choose a scope (GLOBAL, TEAM, or USER)
3. Add documents with appropriate categories (MANDATORY, BEST_PRACTICES, etc.)
4. Optionally add prompt templates for common tasks
5. Link the collection to projects that should use it

Linking Collections to Projects

When linking a collection to a project, you can customize:

• Priority: Order in the inheritance chain (lower = higher priority)
• Token Budget %: Override default allocation percentage
• Enabled Categories: Filter to specific categories only
• Enabled/Disabled: Toggle collections on or off

Project: my-api
├── Collection: team-coding-standards (priority: 1)
│   ├── MANDATORY: Error handling rules
│   └── BEST_PRACTICES: API design patterns
├── Collection: security-guidelines (priority: 2)
│   ├── MANDATORY: Security requirements
│   └── GUIDELINES: Security tips
└── Project-specific docs (remaining budget)

Best Practices Discovery

Snipara can automatically discover common patterns across projects linked to a collection:

Discovered patterns appear in your collection where you can accept, reject, or modify them before they become official documentation.

Plan Availability

Example: Team Coding Standards

Here's an example of setting up a team-wide coding standards collection:

# Create the collection

Collection: team-coding-standards

Scope: TEAM

# Add MANDATORY documents

- error-handling.md (MANDATORY)

  "All errors must be logged with context..."

# Add BEST_PRACTICES documents

- api-design.md (BEST_PRACTICES)

  "Use RESTful conventions..."

# Link to projects

Project: api-service → team-coding-standards (priority: 1)

Project: web-app → team-coding-standards (priority: 1)

# Now all queries include team standards automatically!

Next Steps