You are given a task to build or extend a Slidev presentation with SlideBlocks. The required stack is: - Slidev - Markdown slides - Vue components - `slides.md` as the main entry ## First-Run Project Routing Before writing presentation files, inspect the current workspace, the user's supplied files, and the available file-writing capabilities. Choose exactly one route below. Do not combine routes or initialize a second project inside an existing Slidev project. ### Source precedence Use sources in this order: 1. the user's explicit instructions, 2. the user's existing Slidev project, PowerPoint, notes, assets, data, and citations, 3. the selected SlideBlocks block or complete-deck prompt as a structural, interaction, and visual reference, 4. clearly marked placeholders for information that is still missing. User-provided PowerPoint or project content takes priority over example block or deck facts. Never mix the example subject matter into the user's presentation unless the user explicitly asks for that content. ### Route 1 — PowerPoint migration Choose this route whenever the user supplies a `.ppt` or `.pptx` file and asks to migrate, redesign, extend, or continue it. - Treat the PowerPoint as source material, not as the target runtime. - Complete a faithful content migration before applying the selected block or deck style and before creating new slides. - PowerPoint migration overrides demo-only slide-count rules. Preserve every source slide or account for it explicitly in the migration map. - If the user explicitly asks to migrate into an existing Slidev project, integrate there while preserving its current content. Otherwise create a sibling or workspace project folder named `-slidev`. - Follow the full PowerPoint Migration Contract below. ### Route 2 — Existing Slidev project Choose this route when the workspace already contains a Slidev entry such as `slides.md` together with a Slidev package configuration. - Reuse the existing package manager, lockfile, theme, scripts, and project structure. - Do not initialize a new project and do not replace the complete deck unless the user explicitly asks. - Preserve existing slides, assets, components, presenter notes, configuration, and unrelated dirty work. - Modify only presentation-related files such as `slides.md`, `components/`, `layouts/`, `public/`, and `styles/`. - Integrate the selected block or deck according to the artifact-specific scope later in this prompt. ### Route 3 — Empty dedicated folder Choose this route when the current folder is empty, writable, and clearly dedicated to the requested presentation. - Create the Slidev project directly in the current folder. Do not create an unnecessary nested `slideblocks-demo/` directory. - Use the current package manager when one is specified. Otherwise a supported initializer is: ```bash npm init slidev@latest ``` - In a non-interactive environment, create the minimal files directly instead of waiting on an initializer prompt. - Ensure `package.json` includes `dev`, `build`, and `export` scripts and the required `@slidev/cli`, `@slidev/theme-default`, and `vue` dependencies. ### Route 4 — No project folder or unrelated workspace Choose this route when no project folder was supplied, or when the current repository is unrelated to Slidev. - If a writable workspace exists, create one isolated folder using the artifact-specific project name later in this prompt; use `slideblocks-demo` only as a final fallback name. - Do not modify unrelated application files or install Slidev dependencies into an unrelated app root. - If no writable filesystem or project workspace is available, stop before implementation and clearly ask the user to create or attach a folder. Do not claim that the project was saved. - After a folder becomes available, continue with Route 3 inside that folder. ## PowerPoint Migration Contract When Route 1 applies, migrate the source presentation as an inspectable, content-preserving rebuild: 1. Do not move, rename, overwrite, or delete the original PowerPoint file. Treat it as read-only input. 2. Inspect every source slide, including title, body text, page order, speaker notes, images, charts, tables, equations, citations, hyperlinks, and meaningful transitions or builds. 3. Render or export reference images of the original slides when tooling permits, so visual comparisons are possible. Reference renders are evidence, not the final editable implementation. 4. Extract reusable media into a local folder such as `public/imported/` with stable descriptive filenames. Preserve provenance and do not fabricate missing assets. 5. Create `migration/source-map.md`. For every source slide, record its destination Slidev slide or slides, preserved content, rebuilt elements, extracted assets, notes status, and any unresolved item. 6. First complete a faithful migration pass. Then apply the selected SlideBlocks visual system, interaction pattern, or complete-deck structure as a second pass. 7. Rebuild text, formulas, diagrams, tables, and charts as editable Markdown, KaTeX, Vue, HTML, or data-driven SVG whenever practical. Do not use full-slide screenshots as the final deck merely to imitate the source. 8. If an embedded object cannot be reconstructed reliably, preserve it as a clearly documented local image or placeholder and report the limitation. Do not silently drop it. 9. For legacy binary `.ppt` files, use an available safe converter to produce `.pptx` or PDF reference material. If no converter is available, ask the user for a `.pptx` or PDF export rather than pretending the file was migrated. 10. Verify content completeness against `migration/source-map.md` before adding new creative material. ## Project Handoff Contract The task is not complete until a first-time user can find, open, run, edit, and export the saved project. - Write the complete project to disk. The editable source of truth is the project folder containing `slides.md`, `components/`, and local assets—not a chat response and not an exported PowerPoint. - Create or update a project-root `README.md` in the user's language. It must identify the main entry file and give exact commands for the detected package manager. - The README must include installation, local presentation, production build, PDF export, PPTX export, project structure, output locations, and how to resume editing with an agent. - Include commands equivalent to `npm install`, `npm run dev`, `npm run build`, `npm run export`, and `npm run export -- --format pptx`, adapted to the actual package manager and scripts. - Execute every command documented in `package.json` and the project README at least once against the installed Slidev version. If the CLI rejects an option, correct the script and documentation before handoff or report the exact unresolved blocker. - After the last source or style change, rerun tests and the production build, record that final result, and regenerate every requested export. Never validate or hand off an artifact produced from an earlier source state. - If PDF, PPTX, or PNG export is requested, install or document the required `playwright-chromium` dependency and verify the requested output file exists. - Explain that Slidev's PPTX export is an image-based compatibility copy: text is not natively editable/selectable and interactive behavior remains available only in the Slidev web version. - In the final response, report the absolute project path, the main entry file, files created or modified, the exact command to reopen the presentation, the local URL or server output, build/export results, and every remaining placeholder or migration limitation. - If files could not be written or verification did not run, say so directly. Never say that a project was saved, opened, migrated, built, or exported without checking the corresponding artifact or runtime state. ## Visual Quality Contract Treat the copied component source as a starting point for a real Slidev slide, not as a fixed webpage card. You may make style-only changes to improve fit and presentation quality while preserving the component props, content rules, and data behavior. - Do not keep a default large card or frame around the whole slide. Unless the user explicitly asks for a framed card, remove or neutralize root-level outer `border`, heavy `border-radius`, shadow, and card-like background styles on the top-level block section. - Choose typography by subject. Product and interface decks may use `font-family: -apple-system, BlinkMacSystemFont, "SF Pro Display", "SF Pro Text", "Helvetica Neue", Arial, sans-serif;`. Academic and scientific decks should use the scholarly typography profile below. - Use a restrained type scale with `clamp()` for titles, subtitles, values, labels, and notes so short text feels intentional and long text does not overflow. - Prefer concise rewriting within the provided facts over awkward title wraps, tiny unreadable text, or clipped content. - When a page uses a full-bleed background, apply it to the actual slide layout or root stage and verify that default layout padding does not expose unintended canvas strips in live, reduced-motion, print, or export states. - Verify sufficient contrast for inline code, command chips, badges, and other nested text in live and export states; inherited text color must not make these labels disappear against their local background. - After running the deck, visually check for overflow, clipped text, awkward title wraps, oversized values, and misaligned connectors. ### Visual-First Communication and Legibility - Avoid paragraph-length prose on slides. Keep each English descriptive statement to 20 words or fewer whenever accuracy permits; move necessary detail to presenter notes. - Prefer diagrams, plots, images, direct annotations, spatial grouping, and progressive disclosure over prose when they communicate the relationship more clearly. - Use visible text mainly for titles, short claims, labels, annotations, ordered steps, lists, and necessary qualifications. - Treat audience legibility as non-negotiable. Primary text must remain readable without zoom at a 1280 × 720 viewport; reduce, restructure, or stage content before shrinking type. - Every displayed formula needs a nearby visible interpretation stating what it computes or why it matters. Define non-obvious symbols locally. - Every chart needs a nearby visible takeaway or direct annotation identifying the trend, comparison, threshold, or exception the audience should notice. - Keep explanations visually attached to the formula, chart feature, or object they describe; use proximity, highlighting, or leader lines when the target is ambiguous. ### Icon Usage - Use icons only when they improve recognition, navigation, or information structure—not to fill empty space. - Prefer clean, editable SVG icons. Search Lucide first, then Alibaba Iconfont when a suitable symbol is unavailable. - Keep one consistent icon language across the deck: matching stroke weight, corner style, fill mode, optical size, and color. - Small icons should support labels, steps, metrics, and diagrams. Do not place an icon beside every sentence or use generic icons instead of meaningful visuals and evidence. ### Illustration Usage - Use an illustration only when it clarifies an abstract idea, state, process, or memorable claim—not to fill empty space or replace evidence. - Let one illustration communicate one cognitive action. Translate the idea into a concrete physical action, object, or spatial relationship with one dominant subject and clear negative space. - Match the deck's visual language. Avoid generic stock metaphors, crowded scenes, and repeated template compositions. - Prefer generated illustrations without baked-in text. Add titles, labels, and callouts as editable Slidev HTML or SVG; use native SVG instead when structural precision matters. ### Collision-Free Layout and Attention Hierarchy - Axis titles, tick labels, units, and legends must not intersect one another or cover plotted marks. Reserve explicit plot margins and a clear legend zone; do not solve collisions by shrinking type. - Legends, captions, descriptive labels, and callouts must not cover data marks or the main visual subject. Place them in reserved whitespace; use leader lines when the target would otherwise be ambiguous. - Treat figures, equations, and text as mutually reserved layout regions. A figure, image, or panel must never overlap, cover, or visually intrude into an equation or explanatory text in any interaction or export state. - Every visible text box must remain fully inside its assigned container and the slide safe area in every interaction, reduced-motion, and print/export state. Shorten, reflow, or restructure content before it clips, overflows, or crosses a border. - Use separator lines only when they communicate a boundary that whitespace or alignment cannot. Do not add redundant horizontal rules inside an already isolated panel or between tightly coupled content. - Set layer order deliberately: background maps and decorative context first; structural guides, nodes, and connector rails next; primary evidence and readable labels above them. No mask, ornament, or background marker may occlude active text or the main visual subject. - For a horizontal word sequence, keep all terms on one baseline and use simple typographic arrows centered in the available gaps. Do not build a rule-plus-arrow connector unless the line length encodes information. - Keep formula and explanatory rails subordinate to the dominant visualization. Show only the equation needed for the current inference and one short interpretation; stage derivations and secondary metrics or move them to presenter notes. - After fonts load, verify positive clearance with DOM bounds. Axis text, legends, annotations, containers, and the slide safe area must remain collision-free at the real viewport and export size. ### Continuous Product-Film Motion Use this profile when the user asks for a launch film, cinematic product story, or a deck whose object and camera should remain continuous across pages. Do not impose it on ordinary document-like slides. - Mount one persistent visual stage and let Slidev navigation update scene state. Disable the normal page transition so the product, camera, and lighting do not remount or flash between slides. - Preload recurring imagery. At the end of a transition, commit the incoming scene behind the transition layer before removing that layer; do not expose a black frame, stale frame, replayed image reveal, or one-frame layout jump. - Define a source focal anchor and a destination focal anchor for every adjacent pair. Carry the viewer through the product or a shared element with camera scale, translation, perspective, masks, or a physical seam; never use a full-slide opacity crossfade as the main transition. - Adjacent transitions may use different recipes, but they must share one motion language: consistent easing, decisive acceleration, a readable held beat, and a stable final frame. Tune timing from captured intermediate frames rather than from the end state alone. - Treat title copy as part of the camera choreography. Clear outgoing copy decisively and reveal incoming copy as one complete group at the intended focal beat. Do not sweep a clipping mask across live glyphs when that exposes incomplete characters, and never leave old and new titles competing on screen. - Let the visual prove the claim. Page count needs visible page motion, refresh rate needs an obviously moving comparison or sample, and a feature hotspot needs a real camera focus on that component; a static label is not evidence of the advertised behavior. - Keep persistent chrome sparse. Do not add blinking progress bars, cursors, footers, navigation rails, or repeated microcopy unless they communicate necessary state or provide an essential control. - Reduced-motion mode must snap to the complete final composition. Overview, print, and export must render the same stable scene content without timers, autoplay, or hidden transition-only dependencies. ### Academic and Scientific Slides Use this profile when the slide reports research, evidence, equations, scientific instruments, paper results, or an academic argument. Explicit user direction and a block's intentional art direction may override stylistic defaults, but never legibility, mathematical correctness, or evidence integrity. - Default to a pure white canvas. A near-white tint such as `#EAF1E3` may be used sparingly for a status or conclusion region. Do not introduce a dark presentation background unless the user explicitly requests one. - Start from a restrained palette: dark ink `#102D45`, primary academic blue `#2F6EA6`, dark blue `#123C61`, muted text `#667680`, and rules `#CBD4D9`. Use additional colors only for genuine semantic distinctions. - Treat semantically coupled labels as one visual unit. A timeline year and its action verb, for example, should share the same accent color and comparable emphasis. - Avoid top navigation bars and decorative chrome. Use a quiet bottom strip only when sources, caveats, controls, or slide numbers are necessary. - Use `"STIX Two Text", "Times New Roman", Times, serif` for scholarly titles, scientific claims, equations, and important numerical results. Use `Arial, "Helvetica Neue", Helvetica, sans-serif` for labels, metadata, controls, plot ticks, and compact annotations. - For a 1600 × 900 Slidev canvas, start around 52–64 px for the slide title, 26–34 px for the primary claim, 16–22 px for explanatory body text, 28–36 px for a display equation, 15–18 px for plot ticks and legends, 18–22 px for axis labels, and 10–12 px only for sources or controls. Account for Slidev scaling: primary information must remain readable at a 1280 × 720 viewport. - Do not create information density by shrinking text. Remove redundant prose, navigation, framing, repeated labels, and decorative cards before reducing type size. - Build a paper-like hierarchy: claim → evidence → quantitative result → interpretation → source. Prefer one dominant figure and one disciplined supporting column over a grid of equally weighted panels. - Treat the title, subtitle or kicker, and any divider as one header block. Leave a clearly perceptible breathing band before the first active body content; the body must not appear attached to or crowded against the header. - Enlarge plot titles, axes, legends, and annotations until the figure can be understood at normal presentation distance. Axes and legends are part of the scientific argument, not disposable footnotes. - For satellites, instruments, telescopes, aircraft, or other equipment, prefer an accurate transparent-background cutout or vector schematic over a rectangular screenshot with baked-in surroundings or captions. - Keep closing and Q&A slides deliberately sparse. Give the thanks and question prompts dominant scale, omit repeated deck titles and nonessential decorative rules, and preserve one unobstructed visual anchor. ### Mathematical Typesetting - Render mathematical expressions with Slidev's KaTeX support using `$...$` or `$$...$$`. For trusted dynamic expressions inside Vue components, use the KaTeX API and load its stylesheet. - Never simulate mathematical notation with nested HTML, Unicode substitutes, manually positioned `sub` or `sup` elements, negative margins, compressed line heights, or CSS transforms. - Use field-standard semantic notation consistently, including roman subscripts when appropriate: `M_{\mathrm{BH}}`, `r_{\mathrm{p}}`, `a_{\mathrm{ang}}`, `d_{\mathrm{ring}}`, `\Delta\alpha\cos\delta`, `\Delta\delta`, and `M_\odot`. - Use KaTeX for inline symbols, metric labels, axis variables, and display equations, not only for the largest formula. - Give fractions, superscripts, and subscripts real vertical space. Style the equation through its container instead of transforming KaTeX internals. - After fonts load, verify that each rendered equation's bounding box does not intersect its explanation, divider, or following content at both the slide canvas size and the export size. - Require a visibly positive breathing gap between every displayed equation and its adjacent title, label, interpretation, or other text; non-intersection alone is insufficient. Verify the post-font DOM-bound gap at the canvas and export sizes. ### Evidence-Driven Visibility and Interaction - Reveal an equation, model, conclusion, or derived quantity only at the state where the evidence first supports it. - Before that state, hide the entire future-evidence block completely. Do not leave ghosted formulas, partial borders, dim explanatory text, or low-opacity future conclusions competing with the active state. - Preserve a hidden block's layout footprint when needed to prevent surrounding content from jumping, while using `opacity: 0`, `visibility: hidden`, `pointer-events: none` where relevant, and an appropriate `aria-hidden` state. - Each interaction state should have one unambiguous focal point. Persistent context may be muted; future evidence must not be previewed accidentally. - Motion must explain evidence accumulation, causality, scale, or comparison. Prefer restrained 180–320 ms state transitions and avoid decorative motion. - Direct timeline selection should stop autoplay. Support keyboard stepping and replay when useful, respect `prefers-reduced-motion`, and render a complete stable final state for print and export. ### Scientific Figure and Visual QA - Prefer data-driven SVG plots, vectors, or reconstructed scientific diagrams over screenshots of plots. Clearly distinguish model curves, measured points, inferred quantities, and illustrative geometry. - Use conventional variables and units on axes, keep tick labels readable, and include an unobtrusive source or credit for observational images and research data. - Preserve complete source figures when every panel contributes evidence. Use an uncropped frame such as `object-fit: contain`; do not use `cover` when it removes a panel, legend, scale, or lower edge. - Keep figure-specific credits and quantitative annotations adjacent to the figure they qualify. Do not detach them into a remote footer or general note when that makes provenance or interpretation ambiguous. - For a focus-centred Kepler ellipse in its orbital plane, generate the path from `x(E) = a(cos E - e)` and `y(E) = a sqrt(1 - e^2) sin E`; this construction places the gravitating body at the physical focus `(0, 0)`. Derive both the path and the focus marker from the same orbital elements and transform. - A linear sky projection preserves the physical origin but does not generally preserve the Euclidean foci of the apparent 2D ellipse. Label the central marker `projected dynamical focus`; never relocate it to a focus inferred from an SVG ellipse or bounding box. If a visibly classical focus is required, show a separate face-on orbital-plane schematic. - For segmented timelines, scales, and progress rails, treat nodes as segment boundaries: center each segment label between adjacent node centers, place its supporting value or unit below the rail, and position the rail midway between the two text rows with balanced vertical gaps. Keep both gaps compact enough that the labels and rail read as one connected control rather than detached captions. Never anchor both text rows against one node or let the rail cross a label. - Give timelines a reserved safety band. In every state, require `contentBottom + safeGap <= timelineVisualTop`, with at least 24 px at the native slide canvas and more for large filled regions. Timeline labels must also clear the footer. - Treat vertically stacked regions as one coordinated layout. Require `titleBlockBottom + breathingGap <= contentTop`; if a title wraps, gains an image, or the body moves, recompute the downstream body, conclusion, timeline, and footer positions together instead of shifting one region into the next. - Avoid high-specificity `font: inherit` resets on controls: the shorthand can overwrite local size, weight, style, and line height. Inherit only `font-family` when descendants define their own typography, then verify the computed styles. - Inspect every interactive state, not only the final state. At the real viewport, check title wrapping, font fallback, equation bounds, axes, legends, source strips, clipping, contrast, and layout shifts. - Use DOM bounding boxes for dynamic safe-zone checks rather than relying on visual estimates. Normalize measured gaps by the Slidev scale factor when the canvas is transformed. - Verify reduced-motion behavior and the static export separately. A successful build alone is not sufficient evidence that the slide is finished. Do not convert this task into a PowerPoint-first workflow, React slides, Reveal.js, Remotion, image-only slides, or raw HTML without Slidev. Do not invent facts, metrics, dates, customer names, quotes, or citations. Use clearly marked placeholders when source information is missing. After implementation, run the Slidev dev server or build command, report files created or modified, and explain every placeholder. ## Artifact-Specific Scope — Starter Recipe - Default isolated project folder: `mini-technical-product-deck-slidev`. - Outside PowerPoint migration, create exactly the recipe slide count unless the user explicitly asks for more. - During PowerPoint migration, preserve and account for every source slide first. Use the recipe as an opening structure or design system without truncating the migrated presentation to the recipe slide count. ## Recipe: Mini Technical Product Deck # Mini Technical Product Deck Create a three-page Slidev deck: 1. Live Execution Trace Hero: state the thesis through a replayable evidence path. 2. SlideBlocks Architecture: explain how the workflow or system operates. 3. Verified Metric Cards: show verified proof points or bracketed placeholders. Keep all slides in the Minimal Light style. Use only information supplied by the user. If source information is missing, write bracketed placeholders instead of inventing details. Create a runnable three-slide Slidev deck using the included SlideBlocks components. The deck structure is: 1. Live Execution Trace Hero (`blocks/hero/live-execution-trace`) 2. SlideBlocks Architecture (`blocks/architecture-flow/data-pipeline`) 3. Verified Metric Cards (`blocks/metric-cards/verified-metrics`) Use the user's provided README, notes, product description, or research context as the only source of facts. Do not invent metrics, dates, customer names, quotes, citations, or traction claims. Use bracketed placeholders for missing values. ## Components To Install ### Live Execution Trace Hero Block: Live Execution Trace Hero ID: blocks/hero/live-execution-trace Family: Hero Variant: live-execution-trace Author: SlideBlocks contributors Description: Open a scientific review with a replayable observation-to-evidence trace driven by Vue state. Use cases: research-process, scientific-review Tags: opening, scientific-workflow, interactive Target file: components/LiveExecutionTraceHero.vue Input constraints: - maxTitleLength: 64 - maxSubtitleLength: 140 - maxEvents: 8 - maxLanes: 4 - supportsReplay: true Copy this component to `components/LiveExecutionTraceHero.vue`: ```vue ``` Usage pattern: ```md --- layout: default --- ``` Block-specific instructions: Use this block as a one-slide hero pattern within the project route selected by the shared prompt. ## Block Metadata Block: Live Execution Trace Hero Family: hero Variant: live-execution-trace Best for: research-process, scientific-review ## Deck Task Add or update one slide that uses this block. Preserve every other slide and follow the shared PowerPoint-migration override when source slides are being migrated. Copy the Vue component into `components/LiveExecutionTraceHero.vue` and write `slides.md` as the main entry. Use the component once on a single slide. Build the trace from the user's real research or technical evidence when it is available. Each event needs a unique `id`, one of the four lanes (`observe`, `process`, `analyze`, or `validate`), a short `title`, concise `detail`, a normalized `at` value from 0 to 1, and zero to three predecessor ids in `from`. Use `status="retry"` only for a supplied quality-control failure, and use `status="verified"` only when the user has supplied validation evidence. Keep the event count at eight or fewer. Preserve the replayable behavior. The trace should autoplay when the slide opens, allow a visible event to be clicked for inspection (click for inspection), replay from the button or the `R` key, and render the complete final state for reduced-motion or exported output. Do not invent observations, metrics, dates, instruments, methods, findings, failures, quotes, citations, or external validation. Use visibly bracketed placeholders such as `[Observation]`, `[Processing step]`, or `[Validation evidence]` when source information is missing. After implementation, run the Slidev dev server or build command, report files created or modified, and explain every placeholder. Agent rules: Use when a scientific or technical review needs to show how an observation became a reproducible finding, not merely state the conclusion. Rules: - Keep content inside a 16:9 safe area. - Keep the fixed four-lane system: observe, process, analyze, and validate. - Use no more than eight events; every event id must be unique. - Every `from` reference must point to an existing earlier event. - Use a retry state only when the source material includes a failed quality-control step. - Use a verified state only when the source material includes supporting validation evidence. - Preserve the user's exact observations, instruments, methods, findings, and sequence when provided. - Do not invent observations, metrics, dates, instruments, methods, findings, failures, quotes, citations, or external validation. - Keep titles to two short lines and details to one concise sentence. - Preserve autoplay, replay, click-to-inspect, and a complete final state for reduced-motion or export. ### SlideBlocks Architecture Block: SlideBlocks Architecture ID: blocks/architecture-flow/data-pipeline Family: Architecture Flow Variant: data-pipeline Author: SlideBlocks contributors Description: Introduce the SlideBlocks browse, copy, generate, and verify loop with a Mermaid-style architecture diagram. Use cases: agent-workflow-report, technical-product-intro, system-walkthrough Tags: slideblocks, mermaid, architecture Target file: components/SlideBlocksArchitecture.vue Input constraints: - maxGroups: 5 - maxServices: 15 - requiresMermaidArchitecture: true Copy this component to `components/SlideBlocksArchitecture.vue`: ```vue ``` Usage pattern: ```md --- layout: default --- ``` Block-specific instructions: Use this block as a one-slide architecture pattern within the project route selected by the shared prompt. ## Block Metadata Block: SlideBlocks Architecture Family: architecture-flow Variant: data-pipeline Best for: agent-workflow-report, technical-product-intro, system-walkthrough ## Deck Task Add or update one slide that uses this block. Preserve every other slide and follow the shared PowerPoint-migration override when source slides are being migrated. Copy the Vue component into `components/SlideBlocksArchitecture.vue` and write `slides.md` as the main entry. Use the component once on a single slide. Use this block when the deck needs to explain how SlideBlocks connects a browsable block registry, live Slidev previews, copyable prompts, a coding agent, and a verified Slidev deck. Keep the slide focused on the Mermaid architecture diagram, with at most one small explanatory title line above it. Do not add footers, summary cards, or long explanatory text unless the user explicitly asks for it. Do not invent metrics, dates, names, quotes, citations, customer claims, or external validation. Use visibly bracketed placeholders such as `[Author]`, `[Date]`, or `[Verified result]` when source information is missing. After implementation, run the Slidev dev server or build command, report files created or modified, and explain every placeholder. Agent rules: Use when the deck needs to explain the SlideBlocks product architecture, especially the path from block browsing to copyable prompts to generated Slidev decks. Rules: - Keep content inside a 16:9 safe area. - Preserve the user's exact product, project, or research name. - Do not invent metrics, dates, names, quotes, citations, or customer claims. - Keep Mermaid service labels short and readable. - Keep the slide focused on the Mermaid architecture diagram, with only a compact title if needed. - If text wraps awkwardly or overflows, reduce copy before reducing visual quality. ### Verified Metric Cards Block: Verified Metric Cards ID: blocks/metric-cards/verified-metrics Family: Metric Cards Variant: verified-metrics Author: SlideBlocks contributors Description: Show two to four key metrics with one explicit takeaway and strict no-fabrication rules. Use cases: weekly-reports, product-proof-points, research-summaries Tags: metrics, evidence, kpi Target file: components/MetricCards.vue Input constraints: - minItems: 2 - maxItems: 4 - maxLabelLength: 32 - maxNoteLength: 90 Copy this component to `components/MetricCards.vue`: ```vue ``` Usage pattern: ```md --- layout: default --- ``` Block-specific instructions: Use this block as a one-slide metric pattern within the project route selected by the shared prompt. ## Block Metadata Block: Verified Metric Cards Family: metric-cards Variant: verified-metrics Best for: weekly-reports, product-proof-points, research-summaries ## Deck Task Add or update one slide that uses this block. Preserve every other slide and follow the shared PowerPoint-migration override when source slides are being migrated. Copy the Vue component into `components/MetricCards.vue` and use it once in `slides.md`. Use this Metric Cards block when the user has two to four verified metrics or wants clearly marked placeholders for missing metrics. Do not invent numbers, percentages, dates, revenue, customers, latency, traffic, or market sizes. If a value is not present in the user's source material, use a bracketed placeholder like "[metric needed]". Include one takeaway sentence that explains how to read the metrics without exaggerating the evidence. After implementation, run the Slidev dev server or build command, report files created or modified, and explain every placeholder. Agent rules: Use when the slide needs proof points, KPI status, research measurements, or weekly report highlights. Do not use for raw tables, large dashboards, or unsupported claims. Rules: - Use 2-4 cards. - Every real value must be traceable to user-provided content. - Use bracketed placeholders for missing values. - Keep notes short and factual. - Never fabricate metrics to make the slide look complete. ## Deck Output Requirements - Outside PowerPoint migration, create exactly three slides unless the user explicitly asks for more. - During PowerPoint migration, preserve every source slide and use the three-slide recipe as a pattern rather than a truncation rule. - Keep the slides visually consistent with the Minimal Light component styles. - Use bracketed placeholders for missing proof points. - Do not invent facts, metrics, dates, customer names, quotes, or citations. - Run the Slidev dev server or build command and report the result.

{{ title }}

SlideBlocks Architecture

{{ title }}

Beautiful Slidev blocks for AI agents.

Browse

Copy

Present