菜单
Generate a decorative tile SVG for a Lineup comparison type and write it to data/<type>/tile.svg. The SVG is picked up automatically by the tile loader (getTileUrl) and rendered as a low-opacity background by TileBackground. Arguments: comparison type id (required).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | generate-tile |
| description | Generate a decorative tile SVG for a Lineup comparison type and write it to data/<type>/tile.svg. The SVG is picked up automatically by the tile loader (getTileUrl) and rendered as a low-opacity background by TileBackground. Arguments: comparison type id (required). |
| model | opus |
| allowed-tools | Read, Glob, Write |
| argument-hint | <comparison-type-id> |
You are generating a decorative background SVG for a Lineup comparison type. The SVG is saved to data/<type>/tile.svg and automatically picked up by the tile loader (getTileUrl) in app/src/lib/tiles.ts. It is rendered by the TileBackground component at opacity-10 behind the comparison tile's title and description on the landing page.
$ARGUMENTS:
databases, rust-gui). Must match an existing directory under data/.If the id is missing, ask the user to provide one. If data/<type>/ does not exist, abort and list the valid ids from data/index.json.
data/index.json to confirm the comparison type exists and to learn its name and description (use these for thematic inspiration).data/*/tile.svg to find any existing tiles and read 1–2 as stylistic references.app/src/components/TileBackground.tsx to understand the rendering contract (opacity, positioning, currentColor inheritance).Every generated SVG must follow these rules. They encode the decorative/legibility/accessibility requirements agreed in Milestone 18.
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 200 200" fill="none">
<!-- motif elements here -->
</svg>
viewBox="0 0 200 200" — square canvas; TileBackground stretches it with object-cover.fill="none" on the <svg> root; individual elements control their own fills.fill="currentColor" exclusively. Never hardcode hex, rgb, or named colours.currentColor inherits from the surrounding text colour, which switches between light and dark automatically. The tile therefore works on any card background and in both Tailwind themes.opacity attributes on individual elements (e.g. opacity="0.6"), not by mixing different fill colours.opacity-10 only silhouettes and large forms read; fine linework and small labels vanish. Think icon-scale glyphs, not diagrams.<text> or <tspan> elements — text at low opacity becomes illegible noise.object-cover crops.style blocks and <defs> with gradients are permitted but discouraged — they rarely survive low opacity.data/<type>/tile.svg using the Write tool.viewBox="0 0 200 200" is present.<text> or <tspan> elements.currentColor fills (grep for hex # or rgb( — there must be none).If the check fails, rewrite the file and verify again.
The only file written is data/<type>/tile.svg. Do NOT touch data/index.json, candidate files, or any app source files.
Do NOT commit. Committing is the user's responsibility, via /commit.
After writing the file, tell the user:
data/<type>/tile.svg./run) and navigate to the landing page to see the tile rendered live. If the result needs adjustment, describe the change you want and I'll regenerate.Do NOT re-summarise the style rules or print the SVG source inline.
Draft data/<type>/RESEARCH.md for a new Lineup comparison type through Socratic scoping. Writes only the research guide so the user can iterate on scope, attributes, and sources before schema files are generated. Use when adding a new side-by-side comparison (databases, hosting providers, etc.) to a Lineup project. Arguments: comparison type id (kebab-case, required), optional free-text seed.
Add a single new candidate to an existing Lineup comparison type, with a scope-fit check against the comparison's RESEARCH.md before anything is written. Creates the `data/<type>/<candidate>.json` stub, appends the entry to `data/<type>/index.json`, and appends a new `- [ ] <Name> — <reason> (added <date>)` line to RESEARCH.md's Candidates list. Use when the user has a specific candidate in mind (often with URL / description / reasoning provided inline) and wants it vetted against scope before it lands. For bulk scaffolding of candidates already listed in RESEARCH.md, use `/scaffold-type` instead. Arguments: comparison type id (required), candidate name (required), optional free-text context (URL, description, reasoning).
Search the web for additional candidates that fit an existing Lineup comparison type, present them for the user to pick from, then scaffold the chosen ones (RESEARCH.md Candidates append, data/<type>/index.json append, per-candidate stub files). Use when the comparison type is already scaffolded and you want to expand its candidate roster with items you haven't identified yourself. Complements `/add-candidate` (user brings one name), `/scaffold-type` (bulk-scaffolds names already in RESEARCH.md), and `/new-type` (drafts the research guide). Arguments: comparison type id (required), optional free-text hint narrowing the search (e.g. a niche, region, or characteristic).
Add one or more new attributes to an existing Lineup comparison type. Updates `data/<type>/RESEARCH.md` (a new row in an Attribute Groups table, plus Assessment Guidelines if applicable) and `data/<type>/attributes.json` (appends to an existing `groups[]` entry or creates a new group) in a single pass. Use when the comparison type has already been scaffolded (both files exist) and you want to extend the attribute set. Does not touch candidate files — existing candidates render `—` for the new attribute until `/gather-data` fills values. Arguments: comparison type id (required), free-text description of the new attribute(s) (required).
Drive a batch of /gather-data research passes for a Lineup comparison type, fanning out across candidates in PARALLEL. Enumerates unchecked candidates from RESEARCH.md (initial research), then candidates missing attributes added later via /extend-comparison (scoped backfill). Spawns isolated gather-data-worker subagents (fresh context, no commit) one-per-candidate in parallel batches, then SERIALLY flips each candidate's RESEARCH.md checkbox (initial only) and commits its file with the data(<type>): CANDIDATE convention. Use for long-running, hands-off research sessions across many candidates. Arguments: comparison type id (required), optional count cap and worker count.
Research and populate attribute values for a Lineup candidate using the comparison type's RESEARCH.md as the guide. Actively searches the web for authoritative sources and records {value, source, comment} per attribute, then commits the updated candidate file. Use for initial research or to refresh stale values. Arguments: comparison type (required), optional candidate id (auto-picked as the next under-researched candidate when omitted), optional attribute id or group id to scope the work.