Replace the Scatter Prompt Template With Your Own

The auto-scatter hook sends every raw prompt to Claude Haiku with a system prompt that instructs it to decompose into 6 sinc bands. That system prompt is the default template I wrote — and it's designed for general-purpose use. But if you work in a specific domain, you can replace it with a template tuned for your work. The scatter quality goes up. The cost stays the same.

Where the Template Lives

In the scatter server code, there's a SCATTER_SYSTEM constant. That's the full Haiku system prompt. It's a string — you can replace it with any valid string and the server will use your version instead.

# In sinc_llm/scatter_server.py
# Replace this constant with your own

SCATTER_SYSTEM = """
You decompose user prompts into sinc JSON with 6 fragments.
Return ONLY valid JSON with this exact structure:
{
  "formula": "x(t) = Σ x(nT) · sinc((t - nT) / T)",
  "T": "specification-axis",
  "fragments": [
    {"n": 0, "t": "PERSONA", "x": "..."},
    {"n": 1, "t": "CONTEXT", "x": "..."},
    {"n": 2, "t": "DATA", "x": "..."},
    {"n": 3, "t": "CONSTRAINTS", "x": "..."},  // longest band
    {"n": 4, "t": "FORMAT", "x": "..."},
    {"n": 5, "t": "TASK", "x": "..."}
  ]
}
Infer all 6 bands from the raw prompt. CONSTRAINTS must be
the most detailed band. FORMAT must be specific (not 'helpful response').
"""

Domain-Specific Templates

The default template infers context generically. If you work in a specific area, you can bake that context into the scatter template. Here's an example for a Python/FastAPI backend engineer:

SCATTER_SYSTEM = """
You decompose prompts for a senior Python/FastAPI engineer.
Context defaults: Python 3.11, FastAPI, SQLAlchemy, PostgreSQL.
PERSONA default: senior backend engineer, opinionated, minimal.
CONSTRAINTS defaults: type hints required, existing tests must pass,
no new dependencies without explicit request, backward compatible.
FORMAT default: code diff with brief inline comments.

Decompose into sinc JSON (formula + T + 6 fragments, n=0 to n=5).
CONSTRAINTS must be the longest band. Return ONLY JSON.
"""

With this template, a prompt like "fix the auth middleware" produces CONSTRAINTS like "type hints required, existing tests must pass, no new dependencies, backward compatible, Python 3.11 syntax only" without you having to specify any of that. It's inferred from the template context.

What Makes a Good Custom Template

Four things matter:

Domain defaults — what stack, language, framework, or business context applies to most of your work. State this explicitly so the model doesn't have to infer it from scratch each time.

PERSONA defaults — who the model should be for your typical tasks. If you always want a "senior engineer with strong opinions on simplicity", put that in the template so the PERSONA band gets populated correctly on short prompts.

CONSTRAINTS defaults — your standing rules. "Never break backward compatibility." "Tests must pass." "No TODO comments in production code." These are things you'd catch in every code review but never write in individual prompts. Bake them into the template.

FORMAT defaults — what output format you almost always want. If you always want code diffs with inline comments, make that the default. You can override it in individual prompts when needed.

Template as Living Documentation

One unexpected benefit: writing a custom scatter template forced me to articulate my actual engineering standards. "What are my real CONSTRAINTS on every piece of code I write?" Writing them down for the template made them explicit and shareable. The template became documentation for how I work — useful for onboarding, useful for explaining my code review standards, useful for training.

If you're working on a team, a shared scatter template means consistent context injection across the whole team. Everyone's prompts get the same domain context, the same default constraints, the same format preferences. Reduces the "but I didn't know about that constraint" problem significantly.