Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/multiplex-term/multiplex/design-conventionsgit clone --depth 1 https://github.com/multiplex-term/MultiplexWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.01213 |
| Opus 5 | $0.00000 | $0.00607 |
| Sonnet 5 | $0.00000 | $0.00243 |
| Haiku 4.5 | $0.00000 | $0.00121 |
Grade A, and why
design-conventions scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Design conventions
Split from AGENTS.md — the TALLY identity in code. Visual rationale: DESIGN.md.
- Bundle id
app.multiplexterm.multiplex; device families are iPhone + iPad + Vision Pro in every configuration (one universal iOS binary — iPhone always runs the single-window shell). Min visionOS 1.0 / iOS 17. - Design tokens live in
Theme.swift— the TALLY identity: graphite chassis#17181A, screens darker than frames#0A0B0C, tally red#E5484Dspent ONLY on live state and always captioned. Use tokens; color is state, never decoration (actions are neutral chips). Every token is appearance-dynamic (Color(light:dark:)): light is the Frost chassis#E4E8EE, screens brighter than frames (DESIGN.md "Daylight").chassisstays an asset color so the launch screen hands off in either polarity. The appearance choice (ThemeStore.appearance: SYSTEM/LIGHT/DARK everywhere, plus GLASS on visionOS in every build) is applied byUIKitSceneRootViewController.applyAppearancethrough each scene window'soverrideUserInterfaceStyle— never a mechanism that stops at presentation boundaries (SwiftUI'spreferredColorSchemedid). GLASS pins dark traits, shares DARK's terminal-theme slot, and independently ridesGlassAppearanceTrait;GlassSelectionStatemirrors it only where SwiftUI ornament/glass hosts cannot inherit that custom trait. Three traps: a visionOS sheet/popover hosts in its own window and misses an override already in place; a presented controller's own override beats its window's; and visionOS can retain aUILabel's previously resolved dynamic ink after an in-place override. Presented chassis surfaces adoptAppAppearanceFollowing(followAppAppearance(themes)in Chassis.swift; a presenter with no store seeds from the scene window's applied style), and every override writer schedulesrefreshDynamicTextColorsAfterTraitPropagation()after trait delivery. Never write.unspecifiedover a scene window carrying a pinned override. Components inChassis.swift:ChassisLabel(compressed caps),ChassisChip/ChassisBadge(square actions),TallyLamp(captioned state lamp),ChassisSwitch+TallyFormBoolField(monochrome switches — never the system green pill).Font.monois the identity/data voice; body copy stays SF Pro. - Fixed-size chrome type always goes through
Font.mono/Font.ui, never raw.system(size:): iOS-on-Mac paints the iPad point grid at 77% with no opt-out, so both roles multiply byTheme.typeScale(1.3 there, 1.0 everywhere else);ChassisLabelscales size + kerning together, type-locked accents ride the same scale, and control geometry deliberately stays authored. Semantic styles keep Dynamic Type (preferredFont(forTextStyle:)PLUSadjustsFontForContentSizeCategory = truein UIKit) and get the Mac boost once at the scene root (traitOverrides .preferredContentSizeCategory); the two mechanisms never compound. One recorded exception to "geometry stays authored": the hold-CTRL Key Commands panel scales its keycap faces, row buttons, steppers, switches, and fields byTheme.typeScaletoo (KeyCommandMetrics) — a 26-pt keycap holding a scaled glyph read as a toy part on the Mac (2026-08-16); the agent editor's shared switch/arrow controls keep the authored size unless handed ascale. - visionOS hover: set
hoverStyle(square.rect(cornerRadius: 2)) on every custom button/menu — on the CONTROL itself, never a subview/label (a label-level shape is silently ignored and you get the default rounded platter). - Terminal surface colors are user preference, not identity: they come
from the selected
TerminalTheme, neverThemetokens. Each appearance keeps its own selection (ThemeStore.selected(for:); the dark slot keeps the legacy UserDefaults key and defaults to.tally, light defaults to.tallyFrost— the light trio is contrast-tested inTerminalThemeTests). Open terminals re-skin live, and a scheme flip re-resolves through the pane's traits (TerminalPaneUIKit).keyboardAppearancestays.default— the keyboard belongs to the chassis appearance, not the terminal theme. tmux's own status line is left to the user's config (nostatus-styleinjection). - Secrets never touch disk in plaintext — always
KeychainStore, keyed by host UUID. - Platform splits use
#if os(visionOS); iPad sits on chassis with a neutralsignaltint, visionOS keeps native glass for system controls. SYSTEM/LIGHT/DARK keep form sheets, wall, and terminal chrome on opaque TALLY chassis. The visionOS-only GLASS choice instead paints exactly one smoked material ground per window/sheet, clears full-bleed intermediates, and uses strata/line/open-pane tokens above it; never stack smoke layers. The app-lock veil remains opaque in every appearance.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 76 lines · 0 tokens per session scan A 6d4c9ea137b8
design-conventions is an agent published in the GitHub repository multiplex-term/Multiplex (10 stars, last pushed 5d ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 1,213 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
layer3-issue-detection
Layer 3 systematically scans ALL entry points from Layer 1 and applies issue detection rules. Unlike Layer 2 (which traces specific flows in depth), Layer 3 does a breadth-first scan to categorize issues across the entire codebase.
layer4-semantic-evaluation
Layer 4 evaluates workflows from the user's perspective. While Layers 1-3 analyze code structure, Layer 4 asks: "Does this workflow help the user achieve their goal?".
layer2-methodology
Layer 2 takes entry points from Layer 1 and traces the complete user journey.
mobile-architect
Mobile architecture expert. Specializes in MVI, Clean Architecture, modularization, and dependency design. Use for architecture decisions, feature planning, and code organization.
Native SwiftUI Builder
Builds complex custom SwiftUI views using standard SwiftUI components with TTBaseUIKit design tokens (XView/XSize/XFont). Does NOT use TTBaseSUI wrapper components.
kmp-architect
KMP architecture expert. Designs shared module structures, expect/actual patterns, navigation, and DI for Kotlin Multiplatform projects.