Skip to main content

synesthesia

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.

Datos de origen

Repositorio
tkersey/dotfiles
Última actividad en el origen
1 de octubre de 2026 a las 13:34
Idioma detectado de SKILL.md
inglés
Estrellas
71
Forks
1

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Explorador de archivos
8 archivos

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
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