원클릭으로 Manus에서 모든 스킬 실행

visualize

스타6

포크0

업데이트2026년 5월 15일 04:25

Create a taste-to-artifact visualization package for a project, task, draft SPEC, UI, backend, agent runtime, dashboard, game, or product idea without implementing it. Use when the user asks to visualize taste.md, taste.vision, what the model thinks is being built, a product experience, UI mockup, architecture schematic, operator journey, or comprehension check before execution.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

waitdeadai

waitdeadai/minmaxing

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

/visualize

Turn taste.md, taste.vision, and the current request into an inspectable comprehension artifact. This skill is for understanding and alignment, not implementation.

Contract

Read taste.md and taste.vision first.
If either file is missing, stop and route to /tastebootstrap.
Read $ARGUMENTS, active SPEC.md when relevant, and obvious public repo anchors. Do not read .env, .env.*, .claude/settings.local.json, private customer artifacts, credentials, audit logs, or secret files.
Create one ignored run folder:

mkdir -p .taste/visualizations
RUN_DIR=".taste/visualizations/$(date +%Y%m%d-%H%M%S)-$(printf '%s' "$ARGUMENTS" | tr '[:upper:]' '[:lower:]' | sed -E 's/[^a-z0-9]+/-/g; s/^-|-$//g' | cut -c1-48)"
mkdir -p "$RUN_DIR"

Always write $RUN_DIR/visualization.md.
Do not implement, edit product code, promote assets, commit, push, deploy, or mutate SPEC.md.
Keep the package no-secret: do not include credentials, private customer artifacts, or raw environment values.
When the chosen mode is HTML, write the HTML as a companion artifact inside RUN_DIR and keep visualization.md as the canonical human contract. The HTML must reference the canonical source files it renders or explains.

Understanding Card

Begin visualization.md with:

## Understanding Card

- Intended user:
- Product promise:
- Core experience:
- Non-goals:
- Visual or operational tone:
- Likely misunderstanding risks:
- Taste anchors:
- Vision anchors:

Surface Classification

Choose exactly one primary surface:

frontend-web
mobile-app
backend-api
data-dashboard
game
agent-runtime
infra/devtool
docs/brand

Record the chosen surface and a one-sentence reason.

Artifact Choice

frontend-web, mobile-app, product UI: produce a production-quality UI/product mockup image when the current runtime exposes image generation. Use the no-image fallback when image generation is unavailable: write a precise image prompt plus an HTML/SVG/Mermaid schematic or UX storyboard.
data-dashboard: produce a dashboard mockup image when available; otherwise a chart layout, metric hierarchy, and workflow schematic.
game: produce gameplay screen/key-art prompt when image generation is available; otherwise a gameplay loop diagram, screen-state storyboard, or interaction map.
backend-api, infra/devtool, agent-runtime: do not force a fake UI image. Produce an operator/user journey map, architecture schematic, state-flow, API experience narrative, Mermaid diagram, or HTML/SVG artifact.
docs/brand: produce a brand/page/content system visualization or narrative structure.

For HTML mode:

prefer static, self-contained HTML with inline CSS
avoid remote scripts, remote stylesheets, remote fonts, analytics, and external asset fetches unless the user explicitly asks for a shareable hosted artifact
include <!doctype html>, <html lang=...>, <title>, and visible links or labels for canonical files such as visualization.md, draft-SPEC.md, or approval.json
do not put requirements, approvals, source ledgers, or verification evidence only in HTML
if the HTML is interactive, include a copy/export affordance that emits Markdown, JSON, or prompt text the operator can paste back into the harness

If an image is generated, save or reference it inside RUN_DIR and record the actual path. If only a prompt, diagram, or markdown artifact is produced, say so plainly. Never claim an image was generated when it was not.

Required Sections

visualization.md must contain:

# Visualization: [short title]

## Understanding Card
## Source Inputs
## Surface Classification
## Chosen Artifact Mode
## Artifact Paths
## Image Prompt Or Diagram Source
## Assumptions
## Mismatch Risks
## Review Rubric
## Outcome

The review rubric must check:

taste alignment
vision alignment
user/operator experience clarity
component or workflow fidelity
text/label correctness when visual text is involved
privacy and no-secret posture
whether the artifact is useful for implementation decisions

Output

Return a concise summary:

## Visualization Complete

- Surface: [classification]
- Mode: [image / prompt-only / markdown / Mermaid / HTML / SVG]
- Run Folder: [.taste/visualizations/...]
- Primary Artifact: [.taste/visualizations/.../visualization.md]
- Generated Image: [path / none]
- Implementation Performed: no
- Open Questions: [none or focused list]

이 저장소의 다른 Skills

같은 저장소

visualizeworkflow

waitdeadai/minmaxing

Run an approval-first variant of the minmaxing workflow: research, audit, plan, estimate, draft SPEC, visualize the intended product or operator experience, then stop with WAITING_FOR_VISUAL_APPROVAL before implementation. Use when the user wants to see and approve the model's understanding before code changes, or wants to continue or revise a saved visualization workflow.

2026-05-156

opusworkflow

waitdeadai/minmaxing

Use this as the definitive workflow command for mutating work: default Opus 4.7 high planning and review with MiniMax-M2.7-highspeed Token Plan execution, plus explicit governed model profiles such as sonnetminimax for Sonnet 4.6 judgment with MiniMax execution. It must drive to a verified result, partial result, or blocked repair path; /opusminimax is the advanced engine underneath, not a competing daily command.

2026-05-126

sonnetminimax

waitdeadai/minmaxing

Run the power-user Sonnet 4.6 judgment plus MiniMax-M2.7-highspeed Token Plan executor route. Use when the operator wants to preserve Opus quota or has exhausted Opus, while keeping the same governed /opusworkflow lifecycle and MiniMax bounded execution.

2026-05-126

opusminimax

waitdeadai/minmaxing

Advanced engine behind /opusworkflow for provider split, packet, repair, and benchmark work, including the explicit sonnetminimax profile for Sonnet 4.6 judgment plus MiniMax-M2.7-highspeed execution. Normal build/fix/refactor work should use /opusworkflow.

2026-05-126

opusolo

waitdeadai/minmaxing

Run the optional all-Opus sibling of /opusworkflow. Use when the operator explicitly wants Opus 4.7 as planner, executor, reviewer, and final judge with default high effort and optional max effort.

2026-05-126

workflow

waitdeadai/minmaxing

Run the full minmaxing workflow end to end for one request. Use when the user wants planning, implementation, verification, and closeout to happen automatically in one command.

2026-05-126

name	visualize
description	Create a taste-to-artifact visualization package for a project, task, draft SPEC, UI, backend, agent runtime, dashboard, game, or product idea without implementing it. Use when the user asks to visualize taste.md, taste.vision, what the model thinks is being built, a product experience, UI mockup, architecture schematic, operator journey, or comprehension check before execution.
argument-hint	["idea","task","SPEC path","or product surface"]
disable-model-invocation	true

/visualize

Turn taste.md, taste.vision, and the current request into an inspectable comprehension artifact. This skill is for understanding and alignment, not implementation.

Contract

Read taste.md and taste.vision first.
If either file is missing, stop and route to /tastebootstrap.
Read $ARGUMENTS, active SPEC.md when relevant, and obvious public repo anchors. Do not read .env, .env.*, .claude/settings.local.json, private customer artifacts, credentials, audit logs, or secret files.
Create one ignored run folder:

mkdir -p .taste/visualizations
RUN_DIR=".taste/visualizations/$(date +%Y%m%d-%H%M%S)-$(printf '%s' "$ARGUMENTS" | tr '[:upper:]' '[:lower:]' | sed -E 's/[^a-z0-9]+/-/g; s/^-|-$//g' | cut -c1-48)"
mkdir -p "$RUN_DIR"

Always write $RUN_DIR/visualization.md.
Do not implement, edit product code, promote assets, commit, push, deploy, or mutate SPEC.md.
Keep the package no-secret: do not include credentials, private customer artifacts, or raw environment values.
When the chosen mode is HTML, write the HTML as a companion artifact inside RUN_DIR and keep visualization.md as the canonical human contract. The HTML must reference the canonical source files it renders or explains.

Understanding Card

Begin visualization.md with:

## Understanding Card

- Intended user:
- Product promise:
- Core experience:
- Non-goals:
- Visual or operational tone:
- Likely misunderstanding risks:
- Taste anchors:
- Vision anchors:

Surface Classification

Choose exactly one primary surface:

frontend-web
mobile-app
backend-api
data-dashboard
game
agent-runtime
infra/devtool
docs/brand

Record the chosen surface and a one-sentence reason.

Artifact Choice

frontend-web, mobile-app, product UI: produce a production-quality UI/product mockup image when the current runtime exposes image generation. Use the no-image fallback when image generation is unavailable: write a precise image prompt plus an HTML/SVG/Mermaid schematic or UX storyboard.
data-dashboard: produce a dashboard mockup image when available; otherwise a chart layout, metric hierarchy, and workflow schematic.
game: produce gameplay screen/key-art prompt when image generation is available; otherwise a gameplay loop diagram, screen-state storyboard, or interaction map.
backend-api, infra/devtool, agent-runtime: do not force a fake UI image. Produce an operator/user journey map, architecture schematic, state-flow, API experience narrative, Mermaid diagram, or HTML/SVG artifact.
docs/brand: produce a brand/page/content system visualization or narrative structure.

For HTML mode:

prefer static, self-contained HTML with inline CSS
avoid remote scripts, remote stylesheets, remote fonts, analytics, and external asset fetches unless the user explicitly asks for a shareable hosted artifact
include <!doctype html>, <html lang=...>, <title>, and visible links or labels for canonical files such as visualization.md, draft-SPEC.md, or approval.json
do not put requirements, approvals, source ledgers, or verification evidence only in HTML
if the HTML is interactive, include a copy/export affordance that emits Markdown, JSON, or prompt text the operator can paste back into the harness

Required Sections

visualization.md must contain:

# Visualization: [short title]

## Understanding Card
## Source Inputs
## Surface Classification
## Chosen Artifact Mode
## Artifact Paths
## Image Prompt Or Diagram Source
## Assumptions
## Mismatch Risks
## Review Rubric
## Outcome

The review rubric must check:

taste alignment
vision alignment
user/operator experience clarity
component or workflow fidelity
text/label correctness when visual text is involved
privacy and no-secret posture
whether the artifact is useful for implementation decisions

Output

Return a concise summary:

## Visualization Complete

- Surface: [classification]
- Mode: [image / prompt-only / markdown / Mermaid / HTML / SVG]
- Run Folder: [.taste/visualizations/...]
- Primary Artifact: [.taste/visualizations/.../visualization.md]
- Generated Image: [path / none]
- Implementation Performed: no
- Open Questions: [none or focused list]