Skip to content

Usage Examples

SynContext is shared project memory for Claude and other MCP-compatible clients. These examples show reviewer-runnable workflows using a synthetic project named reviewer-demo. Replace the sample project and content with your own project data when using SynContext in day-to-day work.

The examples avoid secrets, private production data, provider API keys, and internal governance tags. They use demo-user as a neutral source tag because source values must be lowercase ASCII governance-style identifiers.

For complete parameters and response fields, see API Reference. The expected results below intentionally describe only stable top-level response envelopes; detailed JSON can include IDs, timestamps, tier-specific fields, and result-limit metadata.

Example A: Store and Retrieve Shared Project Memory

Goal: Store a project update from one assistant, then have another assistant find and summarize it from the same SynContext project.

Prompt to store the update:

Use SynContext to store this project update.
Project: reviewer-demo
Title: Usage examples review
Category: status
Source: demo-user
Tags: docs,review,submission
Content: The usage examples draft is ready for review. The next pass should confirm that each example has a clear goal, runnable prompts, the expected tool sequence, and no secrets or private production data.

Tool sequence:

  1. hub_store_context with project_id, title, content, category, source, and tags.

Expected result: hub_store_context returns a top-level {stored, entry} envelope with the created entry metadata.

Prompt to retrieve it from another assistant:

Search my SynContext memory for the usage examples review, fetch the most relevant entry, and summarize what the next pass should confirm.

Tool sequence:

  1. search with query.
  2. fetch with the selected entry id.

Expected result: search returns a top-level {results} envelope. fetch returns the selected entry; large content may include result-limit metadata.

Example B: Run a Neutral War Room Debate

Goal: Use a War Room to keep a structured discussion and synthesis tied to the same demo project.

Prompt:

Create a SynContext War Room in project reviewer-demo titled "Documentation review strategy". Topic: Should the team publish usage examples as one concise page or split them into separate task-specific pages? Post one argument for the concise page, one argument for separate pages, then read the room and post a synthesis recommendation.

Tool sequence:

  1. hub_create_war_room with project_id, title, topic, and template.
  2. hub_post_war_message with room_id, content, source, and optional stance set to for.
  3. hub_post_war_message with room_id, content, source, and optional stance set to against.
  4. hub_read_war_room with room_id.
  5. hub_post_war_message with room_id, content, source, and optional stance set to synthesis.
  6. Optional: hub_resolve_war_room with room_id, resolution, create_decision, and decision_title.

Expected result: hub_create_war_room returns a top-level {created, war_room} envelope. Each hub_post_war_message call returns {posted, message}. hub_read_war_room returns the room, messages, total message count, and consensus data. If used, hub_resolve_war_room returns {resolved, war_room}.

Example C: Review and Log a Decision

Goal: Read recent project decisions, add a new neutral decision, then confirm it appears in decision history.

Prompt:

Use SynContext to review the latest decisions for project reviewer-demo. Then log a new decision titled "Usage examples publication format" with the decision: "The demo project will publish a concise usage examples page before splitting examples into separate pages." Include rationale that one page is easier for reviewers to scan, and alternatives including separate pages per workflow.

Tool sequence:

  1. hub_get_decisions with project_id and optional limit.
  2. hub_log_decision with project_id, title, decision, rationale, alternatives, and decided_by.
  3. hub_get_decisions again to confirm the new decision is present.

Expected result: hub_get_decisions returns a top-level {decisions, total} envelope. hub_log_decision returns {logged, decision}. Large decision histories may include result-limit metadata.

Verification Tips

Use a synthetic project for reviewer tests, such as reviewer-demo, and avoid content that contains secrets, credentials, private customer data, production logs, or internal deployment status. For public examples, keep prompts focused on goals, tool inputs, and the stable top-level result envelopes.