Intent-Based Context

get_context(mode="intent") is the canonical way to get task-relevant code context from Synapses. It uses your stated intent to adjust edge weights in the code graph, surfacing the most relevant relationships for your specific workflow.

How Intent Works

When you specify an intent, Synapses adjusts the weight of different edge types in the graph traversal:

• modify — boosts CALLS, CALLED_BY, IMPLEMENTS, TESTED_BY edges. You see the function, who calls it, what it calls, its interface contracts, and its tests.
• debug — boosts CALLED_BY, RETURNS, HANDLES_ERROR, DATA_FLOW edges. You see the caller chain, error propagation, and data flow paths.
• review — boosts TESTED_BY, IMPLEMENTS, VIOLATES, ANNOTATED edges. You see test coverage, interface conformance, rule violations, and documentation.
• add — boosts SIBLING, BELONGS_TO, IMPORTS, PATTERN edges. You see related functions in the same package, established patterns, and conventions.
• plan — boosts DEPENDS_ON, BELONGS_TO, IMPORTS at the package level. You see the high-level dependency structure.
• understand — balanced weights across all edge types. You get the broadest view.

Basic Usage

{
  "tool": "get_context",
  "mode": "intent",
  "arguments": {
    "task": "Add retry logic to the HTTP client",
    "intent": "modify"
  }
}

The response is a context packet containing:

• Relevant code snippets with file paths and line ranges
• Relationship information (callers, callees, interfaces)
• Applicable architectural rules
• Related memory episodes (if any)
• Annotations on key entities

Intent Examples

Modify: Refactoring a Function

{
  "tool": "get_context",
  "mode": "intent",
  "arguments": {
    "task": "Refactor parseConfig to support YAML in addition to JSON",
    "intent": "modify",
    "files": ["internal/config/parser.go"]
  }
}

You get:

• parseConfig source code
• All callers of parseConfig (so you know what breaks)
• The ConfigParser interface it implements
• Tests in parser_test.go
• Any architectural rules about the config package

Debug: Tracing a Bug

{
  "tool": "get_context",
  "mode": "intent",
  "arguments": {
    "task": "Debug why webhook delivery silently fails for large payloads",
    "intent": "debug"
  }
}

You get:

• The webhook delivery function and its full caller chain
• Error handling paths and return types
• Data flow from payload receipt to delivery
• Any previous failure episodes related to webhooks
• Timeout and size limit configurations

Review: Code Review

{
  "tool": "get_context",
  "mode": "intent",
  "arguments": {
    "task": "Review the new caching layer implementation",
    "intent": "review",
    "files": ["internal/cache/lru.go", "internal/cache/store.go"]
  }
}

You get:

• The implementation code
• Test coverage information
• Interface contracts the code must satisfy
• Architectural rule violations (if any)
• Annotations and documentation

Add: Writing New Code

{
  "tool": "get_context",
  "mode": "intent",
  "arguments": {
    "task": "Add a new RateLimiter middleware",
    "intent": "add",
    "files": ["internal/middleware/"]
  }
}

You get:

• Existing middleware implementations (as patterns to follow)
• The middleware interface/registration pattern
• Package structure and naming conventions
• Import patterns used by sibling files

Plan: Architecture Planning

{
  "tool": "get_context",
  "mode": "intent",
  "arguments": {
    "task": "Plan migration from REST to gRPC for internal services",
    "intent": "plan"
  }
}

You get:

• Package-level dependency graph
• Service boundaries and communication patterns
• Cross-package imports
• High-level architectural rules

validate(phase=“full”): Pre-Implementation Gates

validate(phase="full") is a variant that returns context specifically for evaluating whether a task should proceed. It is lighter than get_context(mode="intent") and focuses on constraints.

{
  "tool": "validate",
  "arguments": {
    "phase": "full",
    "task": "Replace the ORM with raw SQL queries",
    "intent": "plan"
  }
}

Returns:

• Architectural rules that may be affected
• Blast radius estimate (how many files/functions are touched)
• Existing ADRs related to the area
• Dependency analysis

Use validate(phase="full") before committing to a large change. If the blast radius is too high or rules would be violated, reconsider the approach.

Specifying Files

The files parameter anchors context to specific files or directories:

// Single file
{ "files": ["internal/auth/jwt.go"] }

// Multiple files
{ "files": ["internal/auth/jwt.go", "internal/auth/middleware.go"] }

// Directory (all files in it)
{ "files": ["internal/auth/"] }

When files is omitted, Synapses uses semantic search on the task description to find relevant code automatically.

Context Packet Structure

A context packet typically contains:

1. Primary entities — the most relevant functions/types
2. Relationship graph — edges connecting them
3. Annotations — human or agent notes on entities
4. Rules — architectural constraints that apply
5. Episodes — related memory entries
6. Metadata — file paths, line ranges, languages

The packet is pre-formatted for agent consumption — you can pass it directly into your prompt context without further processing.