Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

create-visual-card

Estrellas0

Forks0

Actualizado7 de junio de 2026 a las 16:53

Generate a magazine-quality visual card as a single self-contained HTML file (embedded CSS, Swiss-grid + bold-type design system), then screenshot it to a shareable PNG and hand back both files. Use this whenever the user wants content turned into a visually rich card or shareable image — even if they don't say the word "card." Triggers: make/create/generate/design a visual card, info card, knowledge card, quote card, social card, summary/takeaway/cheatsheet card; 信息卡, 知识卡片, 金句卡, 语录卡, 做张卡片, 设计一张卡片, 把这段内容做成卡片, 把要点排成一张图, 总结成一张图, 小红书封面, 公众号封面图, 朋友圈配图. Prefer this over generic HTML/frontend skills when the goal is one decorative card image (for multi-section reports use hai-visual-report).

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

Puiching-Memory

Puiching-Memory/jittor-GPNUT1-JGRec

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Diseñadores gráficosArtes, diseño, entretenimiento, deportes y medios·SOC 27-1024

Explorador de archivos

3 archivos

SKILL.md

readonly

Más de este repositorio

mismo repositorio

ast-grep-rule-crafter

Puiching-Memory/jittor-GPNUT1-JGRec

Produces a ready-to-run ast-grep YAML rule that searches, lints, or auto-rewrites code via tree-sitter AST patterns, delivered with positive + negative fixtures and an exact validation command. Use for lint rules, codemods, code modernizations, and API migrations with auto-fix. Trigger whenever the user mentions ast-grep, sg scan, sgconfig, tree-sitter patterns, AST matching, structural search-and-replace, or a codemod — and ALSO when they describe the task without naming the tool, e.g. "find every call to X and rewrite it", "replace all console.log with logger across the repo", "write a lint rule for this pattern", "upgrade all usages of the old SDK", or "migrate this API everywhere". Chinese triggers: 写 ast-grep 规则, 结构化搜索替换, 批量改写代码, 代码迁移规则, codemod, 写个 lint 规则, 语法树匹配, 自动改写代码.

2026-06-070

clean-code-reviewer

Puiching-Memory/jittor-GPNUT1-JGRec

Produces a severity-rated (高/中/低) Clean Code findings report across 7 dimensions (naming, function size/SRP, duplication/DRY, over-engineering/YAGNI, magic numbers, structural clarity, project conventions), each with a location and a behavior-preserving refactor suggestion — never changing functionality. Use whenever the user asks for a code review, quality check, refactor advice, or code-smell / Clean Code analysis, OR points at a file/function/diff and asks if it is well-written, too long, too repetitive, over-engineered, or poorly named — even casually, and even if they never say "review" ("I just wrote this, look it over", "does this look good before I commit"). Trigger on 代码体检, 代码质量, 重构检查, 代码审查, 这段代码写得怎么样, 帮我看看代码有没有问题, 有没有坏味道, 这函数是不是太长了, 命名规范吗, 魔法数字, 重复代码, 过度设计, and English like "is this code clean", "any code smells", "check this file".

2026-06-070

entity-model-auditor

Puiching-Memory/jittor-GPNUT1-JGRec

Audit and design entity data models into a field-by-field markdown report: a target-vs-current audit table per entity, a classification of every field (table column / config blob / runtime-computed / remove), a grouped migration change list, and design-decision justifications — each field run through five cuts (exist? store or compute? column or config? system or content? what form to store?). Use this whenever the user reasons about what fields an entity should have or where they should live, even if they never say "audit": designing a data model, checking PRD fields against a DB schema or backend types, deciding store-vs-compute or column-vs-jsonb, judging whether a field is redundant, spotting a bloated/over-modeled entity, or planning a schema migration. Trigger even when they just paste a PRD, schema, or Prisma/SQLAlchemy model and ask "are the fields right", "what's missing", "should this be a column or jsonb", "is this field even needed". Also on 实体建模, 数据模型审核, 字段审查, 字段太多了, 这个表设计得对吗, PRD 对齐, 模型设计, 该存还是

2026-06-070

geju

Puiching-Memory/jittor-GPNUT1-JGRec

Produces a bold, high-altitude direction judgment (格局判断): a sharp thesis on the right target model, a kill-list of what to delete / merge / split / reframe, a Conservative-vs-Clean-vs-Staged options table, and a verification path (first proof point + falsifier) that keeps the bold call testable. Use whenever the user wants to think bigger, open the design space, or challenge a conservative / incremental / over-compatible proposal — proactively, even when unnamed. Triggers: 打开格局, 格局太小, 你格局小了, 拔高一点, 站高一点, 别太保守, 太碎了, 别老想着兼容, 别被重构难度绑架, 大方向; and English "too incremental / too safe", "play it bigger", "greenfield this", "what if there were no legacy". Once the bold direction needs feasibility / landing pressure-testing, route to goudi.

2026-06-070

goudi

Puiching-Memory/jittor-GPNUT1-JGRec

Pressure-tests an ambitious proposal and returns a grounded landing judgment (go / shrink / pause / reject / validate-first) with one minimum-viable first move, an explicit cut list, success/failure signals, and a stop rule. Use whenever a discussion has more vision than executable grounding, or the user asks how to land/ship a bold idea, define the smallest first step, scope down, pressure-test feasibility, price risk, or set a stop/rollback rule — even if they never name the skill. Triggers on 苟帝, 落地, 先落地, 怎么落地, 别太飘, 太理想化, 收一收, 砍范围, 可执行, 可验证, 最小可行, MVP, 止损, 回滚, 风险有多大, and on "make this real / be realistic / what do I do first / is this plan feasible" — including right after a geju or architecture session. Use geju instead when the goal is to open the frame and think bigger.

2026-06-070

hai-architecture

Puiching-Memory/jittor-GPNUT1-JGRec

Produce an evidence-grounded architecture review or design-decision critique — an architecture map, the painful complexity center, 3-6 chosen review lenses, ranked findings with file:line evidence, why-not alternatives, and a red/blue adversarial check — grounded in John Ousterhout's "A Philosophy of Software Design" (APoSD). Trigger whenever the user asks about architecture or system-design quality: module/package boundaries, abstraction depth, deep vs shallow modules, information hiding, dependency direction, change amplification / blast radius, ownership, error boundaries, or whether to split / merge / combine modules — including 架构审查, 架构 review, 模块边界, 依赖方向, 抽象太浅, 复杂度太高, 这个设计合不合理, or an APoSD / Ousterhout / "philosophy of software design" review. Be pushy: trigger even when they only say "is this structure ok", "these modules feel tangled", "should I split this", "review my system design", or "why does touching X force edits everywhere", not just when they say "architecture review". For naming use hai-nami

2026-06-070

name

create-visual-card

description

Create Visual Card

Generate magazine-quality visual information cards as self-contained HTML files, then render them to a shareable PNG.

Output

A single .html file with embedded CSS, rendered to a .png. The card width must equal the screenshot width argument (default 1024px) so the .card element fills the frame with no uneven margins — keep .card { width }, the screenshot command's width arg, and this value in sync.

For the final handoff format, read references/output-template.md after generating and checking the card, and fill every field it lists.

Design System

The font <link>, :root color variables, and noise-texture SVG live in the Template Skeleton below (the copy-pasteable artifact). This section holds only the decisions the skeleton can't encode: type scale, spacing, and density intent.

Type Scale

Role	Size	Weight	Notes
Super title	72-84px	900	Core visual hook, lh: 1.0, ls: -0.04em
Section	56px	700	lh: 1.1
Sub section	32px	700	lh: 1.2
Body	18-20px	400	lh: 1.6, color: #1a1a1a
Caption	15-16px	400	lh: 1.5, color: #555
Tag/meta	13px	700	ls: 0.15em, uppercase

Spacing

Container padding: 40-50px
Paragraph gap: ≤ 1.5em
Component gap: 30-40px

Visual Decorations

Noise texture: SVG data-URI at 4% opacity (in skeleton)
Heavy divider: 4-6px solid bar in accent color, width ~100px
Background blocks: rgba(0,0,0,0.03)
Base background: #f5f3ed (warm paper)

Layout Strategy

Pick layout by content density — this drives the whole composition:

Low density (few key points): "Big character" — blow up titles to 80px+, core data to 120px+. Let typography be the design.

Medium density: Balanced sections with accent bars and background blocks.

High density (lots of data): Multi-column newspaper grid, 2-3 columns, vertical dividers.

Workflow

Analyze content density (high/medium/low) in one sentence.
Choose layout strategy based on density (see Layout Strategy above).
Write complete HTML with embedded CSS to the workspace, starting from the Template Skeleton.
Screenshot the .card element using the bundled script (path is relative to this skill's directory):
```
node scripts/screenshot.mjs <file>.html .card 1024
```
It uses Playwright to open the file directly (no server), renders at 2x DPR, writes <file>.png next to the HTML, and prints that path to stdout — capture it for the handoff. If chromium is missing, run npx playwright install chromium first.
Present the PNG to the user inline and provide the absolute HTML and PNG paths.
Self-check against the four QA items in references/output-template.md (screenshot generated, body text ≥ 18px, mobile readability, visual hierarchy) — it is the single source of truth for the handoff.

Template Skeleton

Start from this. The card width is 1024px to match the screenshot width arg (step 4).

<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link href="https://fonts.googleapis.com/css2?family=Noto+Serif+SC:wght@700;900&family=Noto+Sans+SC:wght@400;500;700&family=Oswald:wght@500;700&family=Inter:wght@400;600;700&display=swap" rel="stylesheet">
<style>
  :root { --color-accent: #d4440f; --color-bg: #f5f3ed; --color-text: #1a1a1a; --color-muted: #555; }
  * { margin: 0; padding: 0; box-sizing: border-box; }
  body { background: var(--color-bg); }
  .card { width: 1024px; max-width: 100%; margin: 0 auto; background: var(--color-bg); padding: 50px; }
  /* noise overlay */
  .card::before { content: ''; position: fixed; inset: 0; opacity: 0.04; pointer-events: none;
    background-image: url("data:image/svg+xml,%3Csvg viewBox='0 0 256 256' xmlns='http://www.w3.org/2000/svg'%3E%3Cfilter id='n'%3E%3CfeTurbulence type='fractalNoise' baseFrequency='0.9' numOctaves='4' stitchTiles='stitch'/%3E%3C/filter%3E%3Crect width='100%25' height='100%25' filter='url(%23n)'/%3E%3C/svg%3E");
  }
  .main-title { font-family: 'Noto Serif SC', serif; font-size: 80px; font-weight: 900; line-height: 1.0; color: #0a0a0a; letter-spacing: -0.04em; }
  .accent-bar { height: 6px; width: 100px; background: var(--color-accent); margin: 10px 0; }
  .body { font-family: 'Inter', 'Noto Sans SC', sans-serif; font-size: 19px; line-height: 1.6; color: var(--color-text); }
  .tag { font-size: 13px; font-weight: 700; letter-spacing: 0.15em; text-transform: uppercase; color: var(--color-muted); }
  .caption { font-size: 15px; line-height: 1.5; color: var(--color-muted); }
</style>
</head>
<body>
<div class="card">
  <!-- build content here -->
</div>
</body>
</html>

(assets/ is intentionally empty — it's where local font fallbacks or bundled images would go if added later; the skeleton currently loads fonts from a CDN.)

Design Philosophy

Swiss internationalism structure + modern magazine visual impact. Rigorous grid, bold typography, warm paper texture. Every element earns its space.

Use a different skill when

The user wants a multi-section / scroll-length report (idea, PRD, plan, review turned into a presentation-like web page) → use hai-visual-report, not a single card.
The user wants an interactive page, app, or reusable UI component → use frontend-design.
The user wants a print poster as PNG/PDF (canvas/document output, not a web card) → use canvas-design.

Keep create-visual-card scoped to one decorative, single-frame card image.