# DESIGN.md - Agentic Design Ops ## Design Intent Agentic Design Ops should feel like a practical editorial system for design operations with AI agents. The reference is the lighter Myclaude / Designer Builder Hub language from the screenshots: cream canvas, oversized confident type, italic green emphasis, soft glass panels, and a homepage that feels like an organized learning hub rather than a generic SaaS landing page. The visual tone is: - editorial - practical - calm - structured - warm - personal but credible - design-led rather than engineering-first ## Reference Use the light Myclaude homepage language as the baseline: - warm cream page background - oversized Manrope headlines - italic green emphasis inside headlines - generous spacing - centered hero - soft white/glass panels - rounded but not childish cards - mono labels and workflow chips - muted grey body text - functional visuals such as card fans, workflow chains, and operating-system panels ## Brand Direction Working name: Agentic Design Ops Toolkit/product name: Design Harness The site should communicate: > Design operations workflows for designers working with AI agents. Avoid broad generic language like: - AI design news - ultimate prompt library - tools for designers - learn AI fast Prefer concrete operational language: - workflow - harness - context - critique loop - validation - source trust - design QA - product judgment - field note - operating system ## Layout Principles - First viewport should clearly state the thesis and show the IA visually. - Navigation should make the operating model obvious: Workflows, Harness, Case Studies, Reference, Field Notes, About. - The homepage can use expressive layout moments, especially card fans and split workflow sections. - Blog and field-note pages should feel more editorial: narrower reading widths, calmer typography, and stronger hierarchy. - Cards are for repeated items and navigation choices. - Avoid nested cards. - Avoid dark developer-dashboard styling. - Every page should answer: what can a designer do with this? ## Components Core components: - top navigation - centered hero - hero bust/avatar - fan navigation cards - section label - editorial split section - soft glass card - workflow chain - doc link strip - case study panel - reference panel - article/field-note preview - template hero - editorial hero - editorial article - sticky section navigation - terminal window - data table - note/callout - reference group ## Visual Rules - Light cream theme is primary. - Dark theme can come later, but must not drive the design. - No generic gradient hero. - No decorative blob/orb systems. - Soft shadows are allowed for glass panels and large navigation cards. - Cards can have larger radius when they intentionally match the Myclaude card language. - Letter spacing must be `0` for normal text; uppercase metadata can have tracking. - Use icons only when they clarify a category or action. ## Typography The system uses three font families: two main voices plus one utility mono. ### Manrope Manrope is the dominant font. Use Manrope for: - H1 and H2 display headlines - large homepage section headlines - body copy - navigation - buttons - cards ### Cormorant Garamond Cormorant Garamond is the editorial accent. Use Cormorant for: - field-note/article headings where a calmer blog tone is needed - quoted lessons - reflective editorial moments Do not use Cormorant as the main homepage voice. ### JetBrains Mono JetBrains Mono is the operational utility font. Use JetBrains Mono for: - labels - step numbers - workflow chips - file names - prompt/template names ## Type Scale Discipline Use named scales, not one-off massive clamps: - hero headline: `--type-hero` - subpage title: `--type-page-title` - homepage section title: `--type-section-title` - wide card title: `--type-card-title` - large body: `--type-body-large` - editorial article title: `--type-editorial-title` - editorial article deck: `--type-editorial-dek` Small cards should not inherit section-title sizing. Article templates can introduce a calmer Cormorant reading style later, but the hub homepage should stay Manrope-led. ## Article Template Modes There are two canonical article modes: - How-to / guide mode: use `article-template.html`. This is for practical explainers, workflow notes, setup guides, references, and pages that benefit from section navigation, terminal windows, tables, notes, and reusable snippets. - Editorial / essay mode: use `editorial-template.html`. This is for Medium-style writing: Planark stories, field notes, lessons learned, opinion pieces, and reflective build essays. It should stay narrow, paragraph-led, and calm, with no sticky sidebar. Do not merge these into one overloaded template. Pick the reading experience first, then add only the components that fit that mode. ## Template Visual Details The how-to / guide template intentionally follows the old Myclaude `article-template.html` card language. Use these canonical details: - Template hero shell: `--hero-gradient`, `--hero-border`, `--shadow-hero`, and `--radius-template`. - Template hero border: pale navy mixed with the standard rule color, not a dark blue outline. - Template hero radius: `32px`. - Template section heading: compact Manrope, `clamp(1.85rem, 3vw, 2.45rem)`, with a 1px top rule and a short trailing line. - Template section heading should never use homepage-scale heading tokens. - Section nav should be a quiet sticky table of contents, not a large glass card. The editorial / essay template intentionally does not use the card hero. It should feel closer to Medium/Substack: narrow column, generous paragraph rhythm, minimal metadata, no sidebar, and no dense component blocks unless the article truly needs them. ## Token Discipline Core design values live in `styles.css` and are documented in `docs/design-system/TOKENS.md`. Use tokens for: - fonts - type sizes - colors - radius - shadows - page gutters - section spacing - content widths Do not add one-off visual values directly into components unless the value is truly local and not likely to repeat. Reusable values should become tokens first, then be documented. When changing the visual system, update: 1. `styles.css` 2. `docs/design-system/TOKENS.md` 3. `docs/DESIGN-SYSTEM.md` if the system-level rule changed 4. this `DESIGN.md` if the visual direction changed ## Template Components The reusable article/template system is canonical. Use it for long-form guides, workflow explainers, field notes, and reference-heavy pages. Canonical classes: - `.template-hero` - `.template-layout` - `.section-nav` - `.section-heading` - `.terminal-window` - `.data-table` - `.note` - `.workflow-step` - `.checklist` - `.reference-group` The live example is `article-template.html`. Use it as the starting point before creating a new article layout. ## Content Rules Every workflow should include: - the problem - when to use it - required inputs - context the agent needs - prompt/task pattern - human review step - validation step - saved output - real example when available Every case study should distinguish: - what AI did - what the designer decided - what evidence validated the work ## Anti-Drift Rule If a page starts to feel like a generic AI resource directory, bring it back to design operations and real workflow proof.