The auto-scatter hook sends every raw prompt to Claude Haiku. A system prompt tells Haiku to split the prompt into 6 sinc bands. That system prompt is the default template I wrote. It works for general use. But if you work in one specific area, you can swap it out. Use a template built for your work. The scatter quality goes up. The cost stays the same.
In the scatter server code there is a SCATTER_SYSTEM constant. That constant holds the full Haiku system prompt. It is just a string. Replace it with any valid string. 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').
"""The default template guesses context for any topic. If you work in one area, put that context right into the scatter template. Here is 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" fills in CONSTRAINTS for you. It adds things like "type hints required, existing tests must pass, no new dependencies, backward compatible, Python 3.11 syntax only". You do not have to write any of that. The template fills it in.
Four things matter:
Domain defaults: what stack, language, or framework you use most. Write it out clearly. The model will not have to guess it each time.
PERSONA defaults: who the model should act like for your usual tasks. If you always want "a senior engineer who values simplicity", write that in the template. Then the PERSONA band fills in right, even on short prompts.
CONSTRAINTS defaults: your standing rules. "Never break backward compatibility." "Tests must pass." "No TODO comments in production code." You catch these things in every code review. But you never write them in each prompt. Put them in the template instead.
FORMAT defaults: what output shape you almost always want. If you always want code diffs with inline comments, make that the default. You can still override it in a single prompt when you need something different.
One surprise: writing a custom scatter template made me name my real engineering standards. I had to ask: what are my actual CONSTRAINTS on every piece of code I write? Writing them out made them clear and easy to share. The template became a record of how I work. It helps with onboarding. It explains my code review standards. It is useful for training, too.
If you work on a team, a shared scatter template gives everyone the same starting point. Every prompt gets the same domain context, the same default constraints, the same format preferences. That cuts down on the "I did not know about that constraint" problem.
// Production AI Engineering
sinc-LLM designs, audits, and stabilises production AI infrastructure: from vendor evaluation and cost accountability to incident controls and MCP architecture.
See what we do →