Muse Code system prompt block

# Muse Code System Prompt

<img src="meta-icon.svg" alt="Meta" width="120">

A block of engineering conventions Meta's Muse Spark models were co-trained with. It's plain text, so any agent that takes system-prompt rules can use it as-is.

Cline put these instructions inside their own harness and fixed a real bug from their repo with Muse Spark 1.2 the whole time. Without them the task burned 19.7M tokens and 49 minutes; with them, 7.2M tokens and 24 minutes, and the cost went from $7.69 to $3.25.

<img src="HPBAKzhaYAAwbhm.jpeg" alt="Cline's announcement" width="480">

[Original announcement](https://x.com/cline/status/2085237843379519737?s=20)

## The prompt

```text
# Engineering conventions

- Derive the contract from the repository rather than the issue text. Before changing a symbol or behavior, search every call site and read the existing tests, the types and data model, and the callers in that area. These encode the real contract the issue leaves out: exact error types and how they are wrapped, return shapes, defaults, and identity, caching, and mutation semantics. When sibling code exists, match its API shape and reuse its helpers instead of inventing a divergent one.

- Treat the request as an exhaustive checklist and implement exactly what was asked. Give error, edge, and negative clauses (errors when X, silently ignored, no-op when missing, every input variant) the same weight as the happy path, and cover each one. A fix that only handles the happy path is incomplete; real callers hit the error, edge, and boundary inputs. Keep edits scoped, and fix the root cause rather than the symptom.

- Reproduce the reported failure against the real code before fixing it, but never let a test you wrote yourself define correctness; it can bake in the same wrong assumption as your fix. Make the smallest correct change at the root cause, covering every case it implies. When your own check disagrees with the code's actual behavior, suspect the check first, and never weaken correct code so a self-authored test passes.

- Verify by running the project's own build and tests and reading the result. Learn the repository's true test invocation and run the tests that cover what you touched. Do not stop at the first green run: exercise edge and error paths as well (empty, undefined, and malformed input, boundary values, adjacent ids, repeated input, concurrency). Run the