- name
- synesthesia
- description
- Translate software and architecture into sensory models and back into precise engineering meaning. Use for explicit sensory explanations or renditions, compare-by-feel requests, concrete representational ambiguity, and reuse or revision of established sensory mappings and durable mapping/boundary events. Not an automatic architecture, performance, or UX audit; literal requests for syntax or appearance alone do not imply sensory intent.
- metadata
- {"version":"4.2.0","activation_cost":"low","default_depth":"adaptive"}
# Synesthesia
## Mission
Make software structure perceptible: let architecture become space, interaction
become texture, execution become rhythm, and load become pressure when those
representations illuminate the subject. Translate the resulting insight back
into precise engineering meaning without flattening away the sensory experience.
**Explore representations freely; make claims literally.**
Sensory models are instruments for discovery, explanation, and comparison—not
evidence, proof, or implementation authority. Vividness and rigor are compatible.
An explicit architecture-to-senses request deserves an actual sensory rendition,
not merely a technical paraphrase with a metaphor attached.
## Activation and ownership
Activate for explicit sensory intent, including a rendition of an already
understood architecture; compare-by-feel requests; or a concrete structural,
temporal, interaction, or boundary ambiguity that recoding may illuminate.
The root or an owning workflow may identify that ambiguity. Name the competing
interpretations and the distinction or discriminating observation being sought;
generic uncertainty alone is not enough. No unresolved defect is required for
explicit explanation or rendition.
Also activate to reuse, correct, reject, retract, reopen, or remember an
established sensory mapping or activation boundary. A durable event may accompany
any representational mode; it is not a competing primary mode.
Do not activate merely because work concerns architecture, performance,
readability, flakiness, onboarding, UX, refactoring, handoff, or closeout. Interpret
intent, not keyword matches: “what does valid JSON look like?” ordinarily asks for
literal syntax. Respect literal-only requests. Do not use this lens for exact
syntax, legal/compliance interpretation, or security sign-off.
The owning workflow retains selection, implementation, measurement, proof, and
closure. Return useful insight to the relevant owner: measured performance to
the active optimization workflow, structural architecture to `$universalist`,
local comprehension/refactoring to `$complexity-mitigator`, and accepted memory
transport to `$memory-source-notes`. Do not create a dedicated Synesthesia
subagent or activate sibling skills merely to complete this pass. In explicitly
requested team mode, a read-only lane needs exact artifact state, evidence, a
representational question, and an accountable engineering translation.
## Reasoning contract
```text
literal evidence and question
-> sensory exploration and rendition
-> relationships, dissonances, or candidate mechanisms
-> engineering translation and challenge
-> clearer understanding, comparison, discriminator, or next move
```
Start from inspected code, architecture, tests, traces, logs, behavior, or an
explicitly supplied system description. Distinguish observed facts, stipulated
example facts, unknowns, and hypotheses; do not invent unseen runtime behavior.
Let the representation help discover the technical hypothesis. Do not require
a finished diagnosis before exploration or restrict the search to recoloring
an existing explanation. A representation can suggest a possibility without
establishing it. Recoding cannot manufacture missing evidence: identifying the
measurement that would distinguish two hypotheses is a useful result.
**Reversible means task-relative accountability, not lossless reconstruction.**
Every material sensory claim must have recoverable engineering meaning grounded
in evidence or marked assumptions. Preserve the relation that matters; expose
what the analogy omits and which conclusions must not be imported from it.
Choose modalities for their structural affordances. Explore alternatives as
useful; present a coherent selection, usually one or two. This is not a search
cap or a reason to suppress requested richness. Additional modalities earn their
place through independent dimensions or consequential interactions—even when
they answer the same question. Do not stack synonyms or impose a universal
color/sound/texture dictionary. Use [modality-selection.md](references/modality-selection.md)
when selection or combination needs care; use its linked examples for an
architecture-to-senses rendition.
Keep mappings consistent within the analysis. Compare alternatives on the same
axes without making one sound better by changing the vocabulary. Endorsed
vocabulary is a scoped correspondence, not evidence that its technical referent
is present in a new system. Verify applicability on each use.
## Modes and accountability
Choose the primary mode from the user's goal; a useful explanation may accompany
a diagnosis or comparison without another invocation.
| Mode | Deliver | Challenge |
|---|---|---|
| Explain / render | A genuine sensory model, its literal correspondences, and a clearer mental model | Name omitted properties and likely misconceptions; do not demand a new bug, experiment, or action list |
| Diagnose | A sensory model that suggests or distinguishes technical hypotheses and improves investigation order | Separate observations from hypotheses; give material diagnostic claims a falsifier or discriminating test |
| Compare | Shared axes, grounded differences, trade-offs, and decision implications | Hold evidence and mappings stable; expose missing evidence and misleading aesthetic associations |
| Implementation lens | The route-shaping sensory observation and literal engineering move | Preserve contracts and uncertainty, then return control to the implementation owner |
A well-chosen sensory representation can be valuable because it makes existing
structure easier to understand or remember. It need not discover a defect or
change code to justify an explicit explanatory request.
## Output and stopping
Match the requested richness. For sensory requests, show the architecture's
space, motion, rhythm, texture, contrast, or pressure—not just the translation
back out of them. Keep engineering correspondences near enough to recover and
important limits visible. Directness excludes empty ornament, not vividness.
Use prose, a diagram, a comparison, or an optional compact mapping card as the
task warrants. A card can connect evidence, sensory representation, translation,
limits/uncertainty, diagnostic falsifier, and explanation/decision delta; it is
not mandatory headings or a demand to expose exploratory reasoning.
Stop when the requested representation and its correspondences are complete,
further recoding adds no useful distinction, or a technical owner has the next
move. Literal sufficiency is a reason to skip an unsolicited sensory pass, not
to refuse an explicit rendition. If evidence is insufficient, bound the model
or name the missing artifact rather than asserting a diagnosis. Implement code
literally; do not narrate an entire implementation in metaphor.
## Durable memory
Ordinary sensory output is not persisted. Explicit durable endorsement,
correction, rejection, retraction, reopening, or a reusable mapping/boundary
request can qualify without repetition. Otherwise require accepted operational
use in at least two independent contexts that changed diagnosis or explanation.
Assistant novelty and task-local approval alone are not durable user authority.
When this gate is live, read [memory-admission.md](references/memory-admission.md)
before capture or admission. Synesthesia owns canonical capture and semantic
eligibility; `$ledger` owns custody; `$memory-source-notes` owns derived transport.
Preserve scope, source evidence, identities, engineering meaning, and verification.
Canonical success, admission success, and digest status remain separate: a later
failure never rolls back an earlier successful write. Keep routine no-ops internal.
Never hand-write source notes, edit compiled memory, or symlink live memory
extension instructions. Do not globalize repository vocabulary without authority.
Ver en GitHub