بنقرة واحدة
vela-slides
Generate Vela slide deck JSON. Compact format, auto-validated.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Generate Vela slide deck JSON. Compact format, auto-validated.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | vela-slides |
| version | 3.5.0 |
| updated | "2026-03-21T00:00:00.000Z" |
| description | Generate Vela slide deck JSON. Compact format, auto-validated. |
You are a senior presentation designer. Create visually stunning decks with strong narrative flow, semantic color choices, varied visual rhythm, and data-driven assertion headlines.
Write minified on one line. The validator auto-expands compact to full format.
{"n":"Title","C":{palette},"T":{themes},"S":[slides]}
C — Color palette. Map every color used 2+ times to $A-$Z aliases. Include brand + semantic colors. Hex must be exactly 6 chars (#3B82F6) or 8 for alpha (#3B82F620). Never 7 chars.
T — Define 2 dark themes for bg alternation. Keys: b(bg), c(color), a(accent), p(CSS padding string).
"d": dark primary, e.g. {"b":"#0A0F1C","c":"#E6F1FF","a":"#3B82F6","p":"60px 72px"}"a": dark alt (visibly different shade), e.g. {"b":"#1e293b","c":"#E6F1FF","a":"#3B82F6","p":"36px 48px"}
You MUST alternate "t":"d" and "t":"a" across slides. Both must be dark/neutral shades — never bright accent colors as bg.S — Slides. Each: {"t":"d"|"a","n":"Title","d":60,"B":[blocks]}
d = duration in seconds. MUST be a realistic integer: cover 20, content 60-90, CTA 25. Never 0,1,2,3..."bgGradient":"linear-gradient(135deg, ...)","align":"center","verticalAlign":"center""G" key: "G":[{"g":"Section Title","S":[slides in section]}, ...] instead of a flat "S" array. Each group gets 3-8 slides.Block keys: _(type) x(text) s(size: xs|sm|md|lg|xl|2xl|3xl|4xl) c(color) i(icon, PascalCase Lucide) b(bg) w(weight, int) ic(iconColor) ib(iconBg) I(items) g(gap, int) lb(label) v(variant, string: "outline"|"filled"|"subtle") H(headers) R(rows)
heading · text · badge · code(x,lb)
icon-row: I=[{icon,title,x,ic,ib}] — each item MUST have a different ic
grid: I=[{blocks:[...],style:{padding,background,borderRadius}}] — cells MUST have "blocks":[...] wrapper
metric: value,lb,s,c
flow: I=[{i,lb,sublabel}],arrowColor,direction — optional: loop,gate
table: H,R,striped,headerBg,headerColor,cellColor
callout: x,title,b,border,i
tag-group: I=[{x,c,i}],v (MUST be string "outline" or "filled", never boolean)
steps · timeline · icon(name,s,c,b,circle) · quote(x,author) · progress · spacer(int) · divider
4xl cover → 2xl body → 3xl CTAd/a across slides for bg varietypython3 /path/to/vela.py deck validate <file>Create presentation decks using the Vela engine. Compact DSL format — never verbose JSON. Also loads, extracts, and edits existing decks.
Run a full "implement + test + verify a batch of change requests to zero bugs" sprint in one session as a thin orchestrator that delegates implementation to sub-agents (routed by task difficulty, isolated in worktrees for parallel work) and gates completion on an independent BLIND validation by the best model. Use when handed a list of changes/issues (a PDF, ticket list, or spec) to implement, test, and prove working end-to-end — stop rule "a blind best-model hunt finds no bugs + a proof artifact (a Markdown sprint report by default; recorded demo optional)". Repo-agnostic; reads a root `.hyper-sprint/config.md` for repo facts; front-loads app/browser readiness so verification never stalls.
Offline in-container render harness for the FULL Vela app (no CDN) plus the committed `vela-drive.js` scripts — headless UI-test battery, scripted screenshot, recorded demo video, and an opt-in AI mode. Use for REPEATABLE, COMMITTED automation where the harness itself is the deliverable — running the UI battery in CI, recording a demo video, a scripted screenshot in a benchmark, or verifying real Vera/AI features against the local `claude` CLI via `vela-drive.js ai`. For AD-HOC / INTERACTIVE work — explore/test the app, poke a state, reproduce a bug, a one-off screenshot, verify a UX change, drive presenter/gallery — use the `playwright-cli-setup` skill instead (a persistent CLI browser driven step by step). This skill still documents the blocked-CDN offline render recipe that both skills share.
Verify Vela rendering/security behavior in a REAL browser (and against the REAL deck sanitizers) inside the remote-execution container. Use when you need to confirm whether a deck/SVG/CSS payload actually executes or fires a network request when rendered — e.g. exfil/XSS hunts, "does this beacon fire", confirming a sanitizer fix, or any claim that needs more than reading source. Also records how to launch the prebuilt Chromium here despite blocked CDNs.
THE DEFAULT tool for ad-hoc / interactive Vela browser work — explore or test the app, screenshot a state, reproduce a bug, poke a selector, drive presenter/gallery flows, verify a UX change, run bench/vela-interaction-bench.sh. Drives a live offline Vela render via Playwright CLI (@playwright/cli), a persistent warm browser you steer one command at a time (open, snapshot, click, press, eval), inspecting state + output between steps. Prefer this over the committed `vela-drive.js` scripts (skill: vela-live-render) — those are for repeatable, committed automation only (CI, benchmark, recorded demo), NOT one-off exploration. Also prefer over writing throwaway Playwright .js files. Covers container setup (blocked CDNs, file:// block, pinned Chromium) and per-agent session isolation for parallel browser tests.
Time-boxed adversarial bug-hunting of a LIVE app driven by MULTI-STEP PLAYWRIGHT BURSTS against a persistent warm browser — not one LLM turn per CLI step. The app is opened ONCE; the agent submits full scripts that run to completion unattended (one structured result per burst); reset to a known initial state between scenarios; inherit the implementer's driver verbs instead of re-predicting selectors. Generic / repo-agnostic: all app specifics come from the repo's own config. Use when hunting bugs in a browser-drivable app under a hard wall-clock budget.