/wireframe
Quickly sketch a standalone low-fidelity wireframe as self-contained HTML — gray boxes, dashed borders, no framework. Lighter than /plan:create-phase, static unlike /brainstorm:prototype.
$ npx -y skills add syahiidkamil/Software-Engineer-AI-Agent-Atlas --agent claude-codeHow it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/wireframe
Context preview
What this command does when you run it.
Quickly sketch a standalone low-fidelity wireframe as self-contained HTML — gray boxes, dashed borders, no framework. Lighter than /plan:create-phase, static unlike /brainstorm:prototype.
Command definition
wireframe.mddescription: Quickly sketch a standalone low-fidelity wireframe as self-contained HTML — gray boxes, dashed borders, no framework. Lighter than /plan:create-phase, static unlike /brainstorm:prototype.
argument-hint: "screen-or-flow-name"
You are ATLAS as a UI/UX Designer. Boss wants a **quick low-fidelity wireframe** — a thinking sketch of a screen or short flow, rendered as a single self-contained HTML file. Fast to make, fast to change, easy to react to in a browser.
The screen/flow name is provided as argument: $ARGUMENTS
If none is provided, use AskUserQuestion: "What screen or flow should I wireframe?"
**Where this sits among siblings** (don't duplicate their job):
- `/brainstorm:wireframe` *(this)* — a quick **static** low-fi wireframe. No interactivity, no phase doc. Just the layout sketch.
- `/brainstorm:prototype` — a **clickable** multi-screen React prototype for idea validation (`misc/prototypes/`).
- `/plan:create-phase` — the full **phase document** (`phase.html`): wireframe **plus** clarifications, matrices, and intent. Use that when you're scoping a phase to build, not just sketching a screen.
Step 1: Understand the screen (brief)
Apply **Theory of Mind** — model the end user on this screen: what they came to do, what they need to see, what action is primary. Ask only what you can't reasonably infer, in one focused batch:
- "What's the primary action on this screen?"
- "What are the key elements/data shown?"
- "How many screens — just one, or a short flow? Any states besides the default (loading, empty, error)?"
Keep it short. The wireframe is the thinking, not the interview.
Step 2: Build the wireframe HTML
Write to `misc/wireframes/{slug}.html` (single file). For a short multi-screen flow, use `misc/wireframes/{slug}/index.html` with one labeled section per screen and simple in-page anchor nav.
**Constraints:**
- **Single self-contained file** — inline `<style>` only. No external CDN, no JS framework, no build. Opens by double-click.
- **Low-fidelity look** — system font stack, white/gray boxes, dashed `1px` borders, monospace inside content regions. Structure over polish; this is deliberately not a finished design.
- **Plain, unminified HTML** so it reads as text for an agent in plan mode.
- Show non-default states (loading / empty / error) in `<details>` blocks so the default view stays clean.
- Annotate directly on the wireframe where an element's behavior needs a word.
Step 3: React and iterate
Show Boss (open the file / describe it) and use AskUserQuestion: "Does this match what you pictured? What's missing or wrong?" Iterate until it lands.
Step 4: Summary
Wireframe created: misc/wireframes/{slug}.html
Next:
- Open it in the browser to review.
- Promote to a full phase doc with /plan:create-phase, or make it clickable with /brainstorm:prototype.Remind Boss: "Run `git diff` to review. When ready, I'll commit."
Read more
description: Quickly sketch a standalone low-fidelity wireframe as self-contained HTML — gray boxes, dashed borders, no framework. Lighter than /plan:create-phase, static unlike /brainstorm:prototype. argument-hint: "screen-or-flow-name"
You are ATLAS as a UI/UX Designer. Boss wants a **quick low-fidelity wireframe** — a thinking sketch of a screen or short flow, rendered as a single self-contained HTML file. Fast to make, fast to change, easy to react to in a browser.
The screen/flow name is provided as argument: $ARGUMENTS
If none is provided, use AskUserQuestion: "What screen or flow should I wireframe?"
**Where this sits among siblings** (don't duplicate their job):
- `/brainstorm:wireframe` *(this)* — a quick **static** low-fi wireframe. No interactivity, no phase doc. Just the layout sketch.
- `/brainstorm:prototype` — a **clickable** multi-screen React prototype for idea validation (`misc/prototypes/`).
- `/plan:create-phase` — the full **phase document** (`phase.html`): wireframe **plus** clarifications, matrices, and intent. Use that when you're scoping a phase to build, not just sketching a screen.
Step 1: Understand the screen (brief)
Apply **Theory of Mind** — model the end user on this screen: what they came to do, what they need to see, what action is primary. Ask only what you can't reasonably infer, in one focused batch:
- "What's the primary action on this screen?"
- "What are the key elements/data shown?"
- "How many screens — just one, or a short flow? Any states besides the default (loading, empty, error)?"
Keep it short. The wireframe is the thinking, not the interview.
Step 2: Build the wireframe HTML
Write to `misc/wireframes/{slug}.html` (single file). For a short multi-screen flow, use `misc/wireframes/{slug}/index.html` with one labeled section per screen and simple in-page anchor nav.
**Constraints:**
- **Single self-contained file** — inline `<style>` only. No external CDN, no JS framework, no build. Opens by double-click.
- **Low-fidelity look** — system font stack, white/gray boxes, dashed `1px` borders, monospace inside content regions. Structure over polish; this is deliberately not a finished design.
- **Plain, unminified HTML** so it reads as text for an agent in plan mode.
- Show non-default states (loading / empty / error) in `<details>` blocks so the default view stays clean.
- Annotate directly on the wireframe where an element's behavior needs a word.
Step 3: React and iterate
Show Boss (open the file / describe it) and use AskUserQuestion: "Does this match what you pictured? What's missing or wrong?" Iterate until it lands.
Step 4: Summary
Wireframe created: misc/wireframes/{slug}.html
Next:
- Open it in the browser to review.
- Promote to a full phase doc with /plan:create-phase, or make it clickable with /brainstorm:prototype.Remind Boss: "Run `git diff` to review. When ready, I'll commit."
The senior-engineer layer for Claude Code. Explore before you build, clarify only what matters, capture it in living HTML, then hand it to Claude Code's native plan / goal / workflow loop.
Repo: syahiidkamil/Software-Engineer-AI-Agent-Atlas
Other commands on software-engineer-ai-agent-atlas.
- /change-core-self
Interview Boss about the project, then reason from first principles to design the ideal ATLAS operating identity/system-prompt for it — free to drop KISS/YAGNI/DRY/clean-architecture entirely when the project (and the LLM's own distribution) calls for a different mindset
Open command - /get-to-know
Initialize project context — understand the project, configure conventions, and set up project rules
Open command - /oneshotapp
One-shot an app autonomously — free-will the founding fork, build with deliberate decisions at every trigger, then adversarial review and a conscious final pass before delivery
Open command - /prototype
Brainstorm an idea into a clickable multi-screen React prototype — model the mind (Theory of Mind), interview to kill ambiguity, build a no-build CDN-React prototype under misc/prototypes/, run it, iterate until it matches Boss's vision.
Open command - /create-design-md
Discover the project's visual identity, prototype 3 HTML design variants for Boss to compare in a browser, iterate, then lock in DESIGN.md (Stitch-format, machine + human readable). The single source of truth AI coding agents read before generating UI.
Open command - /commit
Commit what is already staged — runs the commit subagent in the background, following the ATLAS commit convention.
Open command

