The design-judgment spine of the atelier suite — where the visual language and archetype are chosen and the quantified targets all later lenses enforce are set. Use before any pixel is placed — before a color system or type scale is chosen. The one shift: good design is NOT defaults nudged until it "looks ok" — it is…
The color & light lens for a frontend build — where the palette gets its perceptual foundation, dark mode gets its re-tuned ramp, contrast gets verified, and data-viz gets a rigorous scale. Use when establishing a color system from scratch, auditing an existing palette for coherence or accessibility failures…
The depth-and-shape lens for a frontend surface — where elevation becomes physical, corners become a language, and texture earns its place. Use after color tokens are committed, when establishing or auditing the depth model, or when surfaces "look flat / look cheap / look wrong but I can't say why." The one shift…
The advanced visual layer for a frontend build — where icons, imagery, Canvas, WebGL, GPU, and generative technique live, and "three.js because it looks cool" gets decided. Use after the core visual language is set, when auditing the graphics layer, or when a UI has mismatched icons, layout-shifting images, or GPU…
The composition lens for a frontend build — where hierarchy, grid, measure, and spatial rhythm are decided, and "looks amateur" / "won't scale to real data" are determined. Use after the build works (seaworthy) and alongside canon's gates, when auditing a surface's composition. The one shift: hierarchy and the grid…
The motion, gesture & feel lens for a frontend build — where every animation earns its place and the feel IS the product. Use after the build works, when adding interaction physics, when a UI feels sluggish / janky or the gesture fights the scroll, or auditing animations. The one shift: every animation maps to a…
Navigate the atelier design-craft suite: given a visual-design task, route to the right lens — and the right ENTRY lens — or to a sibling suite, or say plainly when none fits. The un-gated front door to the eight atelier lenses: canon, color, type, layout, form, graphics, motion, systems. Use when starting or part-way…
The design-system lens for an atelier build — where tokens, components, and patterns become one coherent, non-drifting artifact, and "design says one thing, code does the other" is decided. Use after the other atelier lenses have produced their tokens, when auditing a token architecture, or when a component library…
The type & text lens for a frontend build — where the scale, rhythm, and language-resilience of every string are decided. Use when establishing or auditing a type system, when text looks off, or when the UI has never been tested outside English. The one shift: a modular type SCALE + a spacing SCALE on the same rhythm…
The distributed-correctness lens: design or audit anything that spans machines. Use when the user designs or reviews RPC, queues, replication, consensus, sharding, fault tolerance, or distributed transactions — or asks whether a design is correct. Triggers on "is this retry safe / exactly-once / idempotency"…
Weave security through the whole lifecycle instead of bolting it on at the end, across: risk-based stance and principles (least privilege, defense in depth, fail secure, zero trust), threat model, secure design, input-distrusting code, CI security gates (SAST/DAST/SCA), the OWASP Top 10, and operations — tuned for a…
Plan, write, and harden tests with a risk-driven decision tree: choose what to test, the right test type, the right test double, and the cases that actually catch bugs. Use when the user wants to test code; asks what or how to test a function, module, API, or system; mentions unit, integration, end-to-end…
Set up or harden a project's engineering process so quality has an automated floor instead of depending on anyone's discipline — version control & branching, code style, code review, CI/CD, and dependency/build management — tuned for a world where agents write much of the code and have no self-discipline to fall back…
Engineer a codebase's feedback surface so an agent gets clear feedback at every step — fast, local, attributed, deterministic, and hard to fake green — instead of flailing against late, opaque, or false-green signals. Set up the strict type layer, boundary validation, errors-as-values, structured failures…
Discover and pin down what to build before building it, with a gated five-stage flow: elicit the real need (not the stated solution), analyze and prioritize, write verifiable requirements, validate shared understanding, and manage change. Use when the user asks for a feature, system, or change — especially a vague or…
Attack your own system — under explicit authorization — to prove its defenses hold, before launch and continuously after: scope and authorize, recon, scan and enumerate, exploit and confirm real vulnerabilities (not scanner false positives), chain them into real impact, then report and re-test. The offensive half of…
Keep a software system cheaply changeable over its whole life — the phase that is 60–80% of total cost and most under-resourced — across: classifying and funding it, making technical debt visible and paying it down, refactoring safely under test, defects to root cause, evolving versions/APIs/deps without breaking…
Design a system's architecture for the agent-assisted era: choose the architecture style, the stack, the module boundaries, the contracts, and the data model — concentrating scarce human judgment on the irreversible decisions and letting agents move fast behind the reversible ones. Use when the user is designing or…
Audit code for craft — and write it craft-grade — so it stays cheap to read and change, across: intent-revealing names, small focused functions, why-not-what comments, earned abstraction (DRY but not premature), cohesion and low coupling, SOLID and patterns as guidance not dogma, trust-chain escape hatches…
Take a system from "merged" to reliably serving users in production, and keep it there: deployment & release strategy, infrastructure-as-code & config, observability, monitoring & alerting, SLOs & incident response, capacity, cost, and backup/DR — tuned for a world where agents operate production and read a green…
The method-design lens: turn a landed gap into a method worth writing up — for any field that runs experiments to publish (ML, optimization, operations research, systems). Use after prospect lands a gap, when designing a method and choosing among approaches, or stress-testing a method you already have. The one shift…
The writing-submission-rebuttal lens: string the prior steps' argument into a manuscript, carry it to a venue, defend it through review, and climb the resubmission ladder — for any field that runs experiments to publish (ML, optimization, operations research, systems). Use when writing the paper, choosing a venue…
The experiment-run lens: turn the method that survived crucible into production code and RUN it to produce confirmation evidence — for any field that runs experiments to publish (ML, optimization, operations research, systems). Use when you are past method design and about to run the real experiments, or…
The experiment-design lens: turn the surviving method into a protocol that produces evidence a reviewer believes — for any field that runs experiments to publish (ML, optimization, operations research, systems). Use after crucible lands a method, when planning the experiments, or stress-testing a plan. The one shift…