Sketch genuinely different layout hypotheses as ASCII wireframes before opening Figma or writing a line of HTML - three by default, two to five when you name a number - built for design teams who want to compare directions, not commit to one too early.
Explore several layout directions for a screen in plain text, compare them side by side, and pick one before any hi-fi work starts. The skill takes a screen name and its primary job as input, and returns one monospace ASCII wireframe per hypothesis - three by default, or the number you name, anywhere from 2 to 5 - each answering a different version of "what does this screen lead with", not a palette variation of the same layout. A fixed legend keeps buttons, inputs, and active states readable the same way across every variant.
- What it does
- Quick start
- Usage
- Example output
- How it works
- How is this different from just asking the model?
- FAQ
- Related skills
- Who maintains this
- Generates distinct layout hypotheses for one screen, each a different answer to what value proposition the screen leads with. Three is the default; a stated number is used as given anywhere from 2 to 5, and a word that names a count - a couple, a pair - states it as plainly as the digit does.
- Renders each hypothesis as a monospace ASCII wireframe, 8-20 lines tall and as wide as the platform calls for - 55-65 characters for the mobile default, 66-80 when desktop or tablet is stated - in a fenced code block that displays correctly in any chat or terminal.
- Uses one fixed legend per response - buttons, inputs, checkboxes, radios, dropdowns, toggles, icons, list rows, overlays, and active tabs always use the same symbols, so the variants are easy to compare.
- Asks exactly one clarifying question when the screen or its primary job is unclear, instead of guessing - and asks only about the part that is actually missing.
- Caps output at five variants and states why: more options slow a decision down instead of speeding it up. It floors at two for the same kind of reason - one sketch is a direction committed to, not a comparison - and says so rather than silently drawing a different number than you asked for.
- Skips citations and rationale in this phase on purpose - a wireframe is only useful while it stays cheap to throw away.
- Declines to name a best variant even when asked directly, and hands back the one question that would decide it instead - three product bets cannot be ranked from a sketch.
Install for yourself, across every project:
git clone https://github.com/humbleteam/ascii-wireframes ~/.claude/skills/ascii-wireframesInstall for one project only, checked into that repo:
git clone https://github.com/humbleteam/ascii-wireframes .claude/skills/ascii-wireframesUse with another agent: this skill is plain markdown, in the Agent Skills format. Paste the contents of SKILL.md into the system prompt of Cursor, Codex, or any other LLM agent that accepts custom instructions.
Restart Claude Code after installing, then ask it what skills it has available, or check ~/.claude/skills/ (personal) or .claude/skills/ (project) directly - ascii-wireframes should be listed either way.
- "Give me 3 layout directions for a pricing page for a B2B analytics tool." Returns three ASCII wireframes, each leading with a different pricing strategy: a single recommended plan, a feature-comparison table, and an ROI calculator.
- "Sketch some options for a mobile onboarding flow before we open Figma." Defaults to mobile proportions and returns three onboarding structures: a guided tour, a self-seeding empty state, and a single setup question.
- "I need 3 different hero section approaches for our marketing homepage." Asks one clarifying question first if the homepage's primary conversion goal is not stated, then renders three hero directions once it has an answer.
- "Here's our current settings screen - sketch some options." (screenshot attached) Reads the screen off the image, asks the one question the image cannot answer - what the screen is for - then returns three hypotheses against that job.
Prompt: "Give me 3 layout directions for a task dashboard home screen."
V1 - Today's tasks first
+------------------------------------------------------------+
| (menu) TaskFlow (search) (bell) (AB) |
+------------------------------------------------------------+
| Today - Tue Jul 14 [[ + Task ]] |
| ---------------------------------------------------------- |
| [ ] Ship pricing page copy 9:00am Design High |
| [ ] Review PR #482 11:30am Eng Med |
| [x] Sync with client onboarding 1:00pm PM Low |
| [ ] Draft Q3 roadmap 3:00pm PM Med |
| |
| Up next: 4 tasks tomorrow, 2 overdue |
+------------------------------------------------------------+
Leads with what's due today, so the first thing a user sees is what to act on right now.
V2 - Project board overview
+------------------------------------------------------------+
| (menu) TaskFlow (AB) |
+------------------------------------------------------------+
| BACKLOG (6) | IN PROGRESS (3) | REVIEW (2) | DONE (8) |
| ------------ | ---------------- | ------------ | --------- |
| [ Card ] | [ Card ] | [ Card ] | [ Card ] |
| [ Card ] | [ Card ] | [ Card ] | [ Card ] |
| [ Card ] | [ Card ] | | ... |
| [ Card ] | | | |
| [ Card ] | | | |
| [ Card ] | | | |
+------------------------------------------------------------+
Leads with the shape of all work in flight, so a user orients on the whole project before picking a task.
V3 - Single task, focused
+------------------------------------------------------------+
| (back) Ship pricing page copy (AB) |
+------------------------------------------------------------+
| Status: In progress Assignee: You Due: Today |
| ---------------------------------------------------------- |
| Description |
| Rewrite hero and pricing copy for the new plan tiers. |
| |
| Subtasks (2/4) |
| [x] Draft hero copy |
| [x] Draft pricing table copy |
| [ ] Get design review |
| [ ] Ship to staging |
| |
| Activity: 3 comments [[ Mark done ]] |
+------------------------------------------------------------+
Leads with one task and its context, so a user lands already inside the thing they came to finish.
Which variant(s) should move forward?
Picking one ends the sketching phase. The reply hands the wireframe on and separates what it states from what it only stands in for, because the next skill treats a count as a contract:
V2 it is - the project board overview.
Next step is a pixel-faithful HTML mockup, which is the html-mockup skill's
job rather than this one. Send it the V2 wireframe as the structure to build
against, and these three with it, because the sketch stands in for them:
- The DONE column draws two cards and a `...` under a header that reads 8.
The `...` says the column repeats, not that it holds two cards. The header
count is the real one in every column; the drawn rows are not.
- Every card in the sketch reads [ Card ]. That says a card sits there and
nothing about what is on it.
- Palette, type, spacing and real copy were never in the sketch at all.
If TaskFlow already exists anywhere - a live board, a brand page - point
html-mockup at it and the last of those comes off the reference instead of a
guess. With no reference it still builds, and marks every value it had to
assume in its census so you correct them in one pass rather than after.
- Every hypothesis has to be a different product decision, not a different visual treatment. Changing only color, spacing, or font between two variants makes them the same hypothesis twice.
- A fixed ASCII legend - borders, buttons, inputs, checkboxes, radios, dropdowns, toggles, icons, repeated list rows, overlays, active-tab markers - stays identical across every variant in one response, so the eye compares structure instead of relearning symbols each time.
- A control the legend does not name borrows the nearest symbol it does and lets the label carry the meaning, rather than inventing a new symbol halfway down the sketch. Inconsistent symbols are what make a set of wireframes unreadable side by side.
- Width and height are a guardrail, not a suggestion. Everything the skill sizes for itself stays inside 55-80 characters and 8-20 lines: that fits a chat pane or terminal without wrapping, and it forces the sketch to leave out detail that belongs in a hi-fi mockup. A width you name yourself is the one thing that overrides it.
- The platform picks the width, and picks exactly one range for it. No platform stated means mobile proportions - 55-65 characters, narrower and taller, mirroring a 390x844 screen - because mobile is the harder constraint. Desktop or tablet moves it to 66-80, wider and shorter. The two ranges do not overlap, so every variant in one response is drawn at the same width and compares down a column.
- The skill asks one clarifying question, never more, when a request under-specifies the screen or its primary job, instead of guessing - and it scopes that question to whatever is missing rather than re-asking what it already has.
- A screenshot settles the screen, not the job. An image shows the elements and the current layout; it cannot show what the screen is for, and without the job three hypotheses collapse into three restyles. So a screenshot with no stated job gets the one question about the job, then the variants.
- Rationale, citations, and "why" explanations are absent from this phase on purpose. A low-fidelity sketch earns its value by being cheap to throw away; a citation makes a reviewer defend a choice instead of reacting to it. Asking for a winner does not unlock one either: the skill holds the screen and its job and nothing else, so ranking three product bets would mean inventing the facts that decide them. It names what each variant bets on and asks the one question that settles it, leaving the call with the person who has the context.
- Once a variant is picked, the skill hands off to a pixel-faithful HTML build rather than doing both jobs in one pass - see html-mockup for that step. The handoff says which marks in the sketch are literal and which are shorthand. A list drawn as two rows and a
...means the list repeats, not that it has two rows, and the skill that builds the mockup writes a census of exact counts and holds its own render to it - so an abbreviation that crosses unmarked stops being an abbreviation and becomes the spec.
A bare prompt for "3 wireframe options" tends to return three versions of the same layout with different colors or spacing, not three different product decisions. It also sneaks in hi-fi opinions - font choices, exact colors - before a direction is picked, and it produces wireframes of inconsistent width and symbol use that are hard to scan side by side. This skill forces every variant to carry its own value proposition, pins one legend and one size range for the whole response, and refuses citations or rationale at this stage on purpose, because a low-fidelity sketch only earns its keep if it costs nothing to reject.
Why wireframe in ASCII? Plain text renders identically in any chat window, terminal, or markdown viewer, with no image tooling required. It is also fast to produce and easy to diff against a follow-up revision.
How many design variants should I explore? Three is the default - enough to force genuinely different value propositions without spreading a reviewer's attention too thin. Ask for a number and you get it, anywhere from 2 to 5, and a word that names a count asks as clearly as a digit: a couple or a pair is two, while some, a few and several leave the count open and take the default. Both ends of that band have a reason and the skill states it when you hit one: past five, comparison turns into skimming, and below two there is nothing to compare, because the closing question asks which variants move forward and a lone sketch turns that into a yes or no about the only option on the page. If the screen genuinely does not carry as many different bets as you asked for, you get the ones that are real plus a line saying why the count is short - the missing variant would have been a restyle, and a restyle is not a hypothesis here.
Can Claude generate wireframes? Yes. This skill has Claude produce monospace ASCII wireframes directly in a chat reply, using a fixed legend for buttons, inputs, and active states so output stays consistent across variants.
What symbols should an ASCII wireframe use?
This skill pins one legend: + - | for borders, [ Label ] for a secondary button and [[ Label ]] for a primary one, [.....] for a text input, [ ] / [x] for checkboxes, ( ) / (o) for radios, [ Label v ] for a dropdown, [o--] / [--o] for a toggle, (icon-name) for icons, [IMG: description] for a photo region, *asterisks* around an active nav item, ... for a row that repeats, v v v for content below the fold, and = borders for a modal above the page. When a screen needs something the legend does not name, the rule is to borrow the closest symbol and let the label say what it is - a date picker as [ 12 Mar 2026 v ] - rather than invent a symbol partway through, which is what makes a set of variants stop being comparable.
Can I just attach a screenshot of the current screen? Yes, and it saves you describing the layout - the image settles what is on the screen. It cannot settle what the screen is for, which is the input the three hypotheses are built against, so expect one question about the primary job before the variants arrive. Answer it and you get three directions rather than three restyles of what you already have. What you will not get is a description of your own screenshot back.
What is low-fidelity wireframing for AI agents? A deliberately cheap, text-only sketching step that happens before any hi-fi mockup or code, so a team aligns on structure and value proposition first.
How wide should an ASCII wireframe be? Wide enough to hold the layout, narrow enough not to wrap in a chat pane: 55-80 characters, 8-20 lines tall. Inside that envelope the platform decides, and it decides once for the whole response - 55-65 characters when no platform is stated (mobile is the default, being the harder constraint), 66-80 for desktop or tablet. Name a width yourself and the skill uses it as given.
Which variant should I pick - can it just tell me? No, and asking directly does not change the answer. The skill knows two things about your project: the screen and its primary job. The three variants are three different product bets, and which one is right depends on your users, your business model, and what your team can build - none of which fits inside a wireframe or gets asked for at this stage. A "best" pick made anyway would be a preference with a recommendation's label on it, which is the thing the no-rationale rule exists to keep out. What you get instead is one line per variant naming what it bets on, and the single question whose answer decides it. You are the one holding that answer. A comparative verdict with reasons behind it is a design-review job, once a direction is picked and there is a mockup to review.
What happens after I pick a variant?
The skill confirms your selection in one line, then points to the html-mockup skill for turning the chosen wireframe into a pixel-faithful HTML mockup. It does not generate HTML itself. It also tells you what to send along with the sketch, which matters more than it sounds: a wireframe abbreviates on purpose - two rows and a ... for a list of any length, v v v for everything below the fold, [IMG: photo] for a region with no size - while html-mockup starts by writing a census of exact counts and states and then holds the render to it. An abbreviation handed over unmarked becomes the spec, and a feed of two items is what you get back. Palette, type, spacing and copy were never in the sketch either; with a reference screenshot html-mockup reads them off it, and without one it marks every guessed value in the census so you correct them in one pass.
Does this skill write any HTML or code? No. It is scoped to the ASCII sketching phase only. If asked for HTML mid-sketch, it names html-mockup as the next step instead of producing code.
Part of a 10-skill open-source kit for design teams by Humbleteam.
- design-review - structured UX critique with a 0-4 score, before/after/why fixes, and a citation for every claim.
- html-mockup - census-first HTML mockups that match a reference screenshot: exact palette, item counts, component states.
- extract-design-tokens - pull palette, type, spacing, radii, and shadows from a URL or screenshot into CSS variables and JSON.
- audit-design-tokens - find token drift in a codebase: raw hex values, off-scale spacing, near-duplicate colors.
- design-qa - a pre-ship design QA gate: states, contrast, touch targets, breakpoints, keyboard paths.
- design-handoff - turn a finished mockup into a dev-ready spec: tokens, states, accessibility annotations, open questions.
- accessibility-audit - WCAG 2.2-grounded accessibility review with success-criterion citations and severity levels.
- ux-writing - interface copy that reads human: plain-verb microcopy rules and an AI-tell strip pass.
- design-brief - extract a 5-bullet design brief from messy project inputs, with a gap report for what is missing.
Humbleteam is a digital product design and AI-engineering studio: founded in 2017, working from Prague and Dubai, with 80+ digital awards to the name, including 14 Awwwards wins, a Webby, and a Red Dot. We design digital products for startups and enterprises in fintech, healthtech, sports, and AI, and we build AI infrastructure for design teams - agents, workflows, and skills like this one.
This skill is distilled from the internal playbooks we run on client work: the same checklists behind the case studies at humbleteam.com/work, for clients like Tinder and Acronis.
- The full 10-skill kit: Related skills above, or all repos at github.com/humbleteam
- What we do with AI for design teams: humbleteam.com/ai
- Design and AI writing: humbleteam.com/blog
- LinkedIn: linkedin.com/company/humbleteam
- Talk to us: hi@humbleteam.com
Issues and PRs welcome.
MIT - see LICENSE.