Show results as interactive UI inside Codeg's chat (cards, tables, charts, tabs, accordions, badges, progress bars, simple forms) by writing a json-render spec code block in your reply. Use when the user invokes this skill or asks to see something as a card, table, chart, dashboard or other visual layout in Codeg.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Codeg renders a ```spec code block in your reply as interactive UI inside the chat. Write the block directly in your reply message, never into a file. Use it when a visual layout genuinely helps (comparisons, trends, status or progress summaries, structured results, checklists); answer in plain Markdown otherwise. The format reference follows.
OUTPUT FORMAT (text + JSONL, RFC 6902 JSON Patch):
You respond conversationally. When generating UI, first write a brief explanation (1-3 sentences), then output JSONL patch lines wrapped in a spec code fence. The JSONL lines use RFC 6902 JSON Patch operations to build a UI tree. Always wrap them in a spec fence block:
{"op":"add","path":"/root","value":"main"}
{"op":"add","path":"/elements/main","value":{"type":"Card","props":{"title":"Hello"},"children":[]}}
If the user's message does not require a UI (e.g. a greeting or clarifying question), respond with text only — no JSONL. Each line is a JSON patch operation (add, remove, replace). Start with /root, then stream /elements and /state patches interleaved so the UI fills in progressively as it streams.
Example output (each line is a separate JSON object):
{"op":"add","path":"/root","value":"main"} {"op":"add","path":"/elements/main","value":{"type":"Card","props":{"title":"Overview","description":"Your account summary"},"children":["child-1","list"]}} {"op":"add","path":"/elements/child-1","value":{"type":"Stack","props":{"direction":"vertical","gap":"md"},"children":[]}} {"op":"add","path":"/elements/list","value":{"type":"Card","props":{"title":"Overview","description":"Your account summary"},"repeat":{"statePath":"/items","key":"id"},"children":["item"]}} {"op":"add","path":"/elements/item","value":{"type":"Stack","props":{"direction":"vertical","gap":"md"},"children":[]}} {"op":"add","path":"/state/items","value":[]} {"op":"add","path":"/state/items/0","value":{"id":"1","title":"First Item"}} {"op":"add","path":"/state/items/1","value":{"id":"2","title":"Second Item"}}
Note: state patches appear right after the elements that use them, so the UI fills in as it streams. ONLY use component types from the AVAILABLE COMPONENTS list below.
INITIAL STATE: Specs include a /state field to seed the state model. Components with { $bindState } or { $bindItem } read from and write to this state, and $state expressions read from it. CRITICAL: You MUST include state patches whenever your UI displays data via $state, $bindState, $bindItem, $item, or $index expressions, or uses repeat to iterate over arrays. Without state, these references resolve to nothing and repeat lists render zero items. Output state patches right after the elements that reference them, so the UI fills in progressively as it streams. Stream state progressively - output one patch per array item instead of one giant blob: For arrays: {"op":"add","path":"/state/posts/0","value":{"id":"1","title":"First Post",...}} then /state/posts/1, /state/posts/2, etc. For scalars: {"op":"add","path":"/state/newTodoText","value":""} Initialize the array first if needed: {"op":"add","path":"/state/posts","value":[]} When content comes from the state model, use { "$state": "/some/path" } dynamic props to display it instead of hardcoding the same value in both state and props. The state model is the single source of truth. Include realistic sample data in state. For blogs: 3-4 posts with titles, excerpts, authors, dates. For product lists: 3-5 items with names, prices, descriptions. Never leave arrays empty.
DYNAMIC LISTS (repeat field): Any element can have a top-level "repeat" field to render its children once per item in a state array: { "repeat": { "statePath": "/arrayPath", "key": "id" } }. The element itself renders once (as the container), and its children are expanded once per array item. "statePath" is the state array path. "key" is an optional field name on each item for stable React keys. For nested lists, an inner repeat can read an array from the enclosing item with { "statePath": { "$item": "field" } }. This form is valid only inside another repeat. Use an empty field to repeat over the enclosing item itself. Example: {"type":"Card","props":{"title":"Overview","description":"Your account summary"},"repeat":{"statePath":"/todos","key":"id"},"children":["todo-item"]} Inside children of a repeated element, use { "$item": "field" } to read a field from the current item, and { "$index": true } to get the current array index. For two-way binding to an item field use { "$bindItem": "completed" } on the appropriate prop. ALWAYS use the repeat field for lists backed by state arrays. NEVER hardcode individual elements for each array item. IMPORTANT: "repeat" is a top-level field on the element (sibling of type/props/children), NOT inside props.
ARRAY STATE ACTIONS: Use action "pushState" to append items to arrays. Params: { statePath: "/arrayPath", value: { ...item }, clearStatePath: "/inputPath" }. Values inside pushState can contain { "$state": "/statePath" } references to read current state (e.g. the text from an input field). Use "$id" inside a pushState value to auto-generate a unique ID. Example: on: { "press": { "action": "pushState", "params": { "statePath": "/todos", "value": { "id": "$id", "title": { "$state": "/newTodoText" }, "completed": false }, "clearStatePath": "/newTodoText" } } } Use action "removeState" to remove items from arrays by index. Params: { statePath: "/arrayPath", index: N }. Inside a repeated element's children, use { "$index": true } for the current item index. Action params support the same expressions as props: { "$item": "field" } resolves to the absolute state path, { "$index": true } resolves to the index number, and { "$state": "/path" } reads a value from state. For lists where users can add/remove items (todos, carts, etc.), use pushState and removeState instead of hardcoding with setState.
IMPORTANT: State paths use RFC 6901 JSON Pointer syntax (e.g. "/todos/0/title"). Do NOT use JavaScript-style dot notation (e.g. "/todos.length" is WRONG). To generate unique IDs for new items, use "$id" instead of trying to read array length.
AVAILABLE COMPONENTS (43):
AVAILABLE ACTIONS:
EVENTS (the on field):
Elements can have an optional on field to bind events to actions. The on field is a top-level field on the element (sibling of type/props/children), NOT inside props.
Each key in on is an event name (from the component's supported events), and the value is an action binding: { "action": "<actionName>", "params": { ... } }.
Example: {"type":"Card","props":{"title":"Overview","description":"Your account summary"},"on":{"press":{"action":"setState","params":{"statePath":"/saved","value":true}}},"children":[]}
Action params can use dynamic references to read from state: { "$state": "/statePath" }.
IMPORTANT: Do NOT put action/actionParams inside props. Always use the on field for event bindings.
VISIBILITY CONDITIONS:
Elements can have an optional visible field to conditionally show/hide based on state. IMPORTANT: visible is a top-level field on the element object (sibling of type/props/children), NOT inside props.
Correct: {"type":"Card","props":{"title":"Overview","description":"Your account summary"},"visible":{"$state":"/activeTab","eq":"home"},"children":["..."]}
{ "$state": "/path" } - visible when state at path is truthy{ "$state": "/path", "not": true } - visible when state at path is falsy{ "$state": "/path", "eq": "value" } - visible when state equals value{ "$state": "/path", "neq": "value" } - visible when state does not equal value{ "$state": "/path", "gt": N } / gte / lt / lte - numeric comparisons"not": true to invert its result[condition, condition] - all conditions must be true (implicit AND){ "$and": [condition, condition] } - explicit AND (use when nesting inside $or){ "$or": [condition, condition] } - at least one must be true (OR)true / false - always visible/hiddenUse a component with on.press bound to setState to update state and drive visibility. Example: A Card with on: { "press": { "action": "setState", "params": { "statePath": "/activeTab", "value": "home" } } } sets state, then a container with visible: { "$state": "/activeTab", "eq": "home" } shows only when that tab is active.
For tab patterns where the first/default tab should be visible when no tab is selected yet, use $or to handle both cases: visible: { "$or": [{ "$state": "/activeTab", "eq": "home" }, { "$state": "/activeTab", "not": true }] }. This ensures the first tab is visible both when explicitly selected AND when /activeTab is not yet set.
DYNAMIC PROPS: Any prop value can be a dynamic expression that resolves based on state. Three forms are supported:
Read-only state: { "$state": "/statePath" } - resolves to the value at that state path (one-way read).
Example: "color": { "$state": "/theme/primary" } reads the color from state.
Two-way binding: { "$bindState": "/statePath" } - resolves to the value at the state path AND enables write-back. Use on form input props (value, checked, pressed, etc.).
Example: "value": { "$bindState": "/form/email" } binds the input value to /form/email.
Inside repeat scopes: "checked": { "$bindItem": "completed" } binds to the current item's completed field.
Conditional: { "$cond": <condition>, "$then": <value>, "$else": <value> } - evaluates the condition (same syntax as visibility conditions) and picks the matching value.
Example: "color": { "$cond": { "$state": "/activeTab", "eq": "home" }, "$then": "#007AFF", "$else": "#8E8E93" }
Use $bindState for form inputs (text fields, checkboxes, selects, sliders, etc.) and $state for read-only data display. Inside repeat scopes, use $bindItem for form inputs bound to the current item. Use dynamic props instead of duplicating elements with opposing visible conditions when only prop values differ.
{ "$template": "Hello, ${/name}!" } - interpolates references in the string. Absolute paths like ${/path} resolve against the state model. Bare names like ${field} resolve against the current repeat item first, then fall back to the state model at /<field>.
Example: "label": { "$template": "Items: ${/cart/count} | Total: ${/cart/total}" } renders "Items: 3 | Total: 42.00" when /cart/count is 3 and /cart/total is 42.00. Inside a repeat, { "$template": "${name} - ${email}" } reads name and email from each item.VALIDATION:
Form components that accept a checks prop support client-side validation.
Each check is an object: { "type": "<name>", "message": "...", "args": { ... } }
Built-in validation types:
Example: "checks": [{ "type": "required", "message": "Email is required" }, { "type": "email", "message": "Invalid email" }]
IMPORTANT: When using checks, the component must also have a { $bindState } or { $bindItem } on its value/checked prop for two-way binding. Always include validation checks on form inputs for a good user experience (e.g. required, email, minLength).
STATE WATCHERS:
Elements can have an optional watch field to react to state changes and trigger actions. The watch field is a top-level field on the element (sibling of type/props/children), NOT inside props.
Maps state paths (JSON Pointers) to action bindings. When the value at a watched path changes, the bound actions fire automatically.
Example (cascading select — country changes trigger city loading): {"type":"Select","props":{"value":{"$bindState":"/form/country"},"options":["US","Canada","UK"]},"watch":{"/form/country":{"action":"loadCities","params":{"country":{"$state":"/form/country"}}}},"children":[]}
Use watch for cascading dependencies where changing one field should trigger side effects (loading data, resetting dependent fields, computing derived values).
IMPORTANT: watch is a top-level field on the element (sibling of type/props/children), NOT inside props. Watchers only fire when the value changes, not on initial render.
RULES:
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
日本語の概要は準備中です。原文の説明を表示しています。
Comprehensive citation management for academic research. Search Google Scholar and PubMed for papers, extract accurate metadata, validate citations, and generate properly formatted BibTeX entries. This skill should be used when you need to find papers, verify citation information, convert DOIs to BibTeX, or ensure reference accuracy in scientific writing.
日本語の概要は準備中です。原文の説明を表示しています。
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
日本語の概要は準備中です。原文の説明を表示しています。
Use when you have a written implementation plan to execute in a separate session with review checkpoints
日本語の概要は準備中です。原文の説明を表示しています。
Design experiments and studies BEFORE data is collected — choosing a design, randomizing, blocking, and laying out treatment combinations so the results will actually be interpretable. Use whenever someone is planning a study, asks how to assign subjects/samples to groups, mentions randomization, blocking, stratification, controls, factorial or fractional-factorial designs, design of experiments (DOE), screening many factors, response-surface optimization, crossover or repeated-measures or split-plot designs, cluster/group randomization, Latin squares, plate layouts, batch/run-order effects, replication vs. pseudoreplication, or sequential/adaptive/group-sequential designs. Trigger this even for informal phrasings like "how should I set up this experiment", "how do I avoid confounding", "what's the best way to test these 6 factors", or "assign these mice to conditions". For computing the sample size or power once the design is chosen, use statistical-power; for analyzing data already collected, use statistical-analysis.
日本語の概要は準備中です。原文の説明を表示しています。
Perform comprehensive exploratory data analysis on scientific data files across 200+ file formats. This skill should be used when analyzing any scientific data file to understand its structure, content, quality, and characteristics. Automatically detects file type and generates detailed markdown reports with format-specific analysis, quality metrics, and downstream analysis recommendations. Covers chemistry, bioinformatics, microscopy, spectroscopy, proteomics, metabolomics, and general scientific data formats.
日本語の概要は準備中です。原文の説明を表示しています。