| name | website-concept-architect |
| version | 1.0.0 |
| description | Walk the user through designing a website concept before any code — purpose, audience, content inventory, tone, visual archetype, structure — and output 2-3 distinct concept directions plus an ASCII homepage wireframe. Use when planning a new personal site, portfolio, or marketing page upstream of implementation. Hands off to ui-ux-architect / frontend-design. |
Website Concept Architect
Pre-code concept design for personal sites, portfolios, and landing pages. This skill produces direction, not markup. The deliverable is a small set of distinct concept docs the user picks from; the chosen one feeds ui-ux-architect for implementation.
When to use
User is starting a new website and wants to decide what it is before writing code. Not for redesigns of working sites unless the brief is "rethink from scratch". Not for component-level UI decisions — those belong to ui-ux-architect.
1. Operating principle — walk, don't dump
Run the six stages interactively, one at a time. After each stage, present the menu, pause, wait for the user's pick, then advance. Never collapse multiple stages into a single question. Never skip stages even if the user volunteers info — surface what they said as a pre-selected default and confirm.
The point of the walk is to force decisions the user would otherwise defer. Skipping a stage means a vague concept doc later.
2. The six stages
| # | Stage | Purpose | Output |
|---|
| 1 | Purpose | What is the site for? | 1-2 picks from archetype list |
| 2 | Audience | Who reads it? | 1-2 picks, drives tone & density |
| 3 | Content inventory | What lives on it? | Checked menu of sections |
| 4 | Tone & personality | How does it feel? | 2-3 adjectives from curated list |
| 5 | Visual direction | What does it look like? | 1 archetype (ranked suggestions, full list shown) |
| 6 | Synthesis | Concept docs | 2-3 distinct concept directions + ASCII wireframe |
3. Stage 1 — Purpose
Present these archetypes. User picks 1-2 (combinable, e.g. portfolio + writing hub):
- Portfolio / showcase — work artifacts are the point; projects are the spine of the IA.
- Writing hub — essays / blog / notes are the spine; everything else is navigation.
- Professional calling card — single-page or near-single-page; recruiters / clients land, learn, contact.
- Digital garden — evergreen interlinked notes; structure is the network, not chronology.
- Project launcher — a specific product or project is the hero; "about me" is a footnote.
- Experimental playground — site is itself a creative artifact; convention is the enemy.
If user picks 2 incompatible archetypes (e.g. experimental playground + professional calling card), flag it and ask which wins on the homepage — the loser becomes a subsection.
4. Stage 2 — Audience
Picks shape how much explanation things need and what voice fits.
- Recruiters / clients — fast skim, credentials-first, low jargon, contact obvious.
- Fellow devs / peers — assumes shared vocab, tolerates density, code samples land.
- Friends / community — informal, personality-forward, in-jokes OK.
- Future-you / archive — built for searching your own past, density over polish.
- The open web — generic visitor, must self-explain, SEO matters.
Multi-audience is normal. If they pick 3+, ask which one the homepage is optimized for — the rest get accommodated on subpages.
5. Stage 3 — Content inventory
Present this menu. User checks what they want; offer to add custom items.
Standard sections:
- About / bio
- Now page (what you're focused on right now)
- Projects index
- Individual project case studies
- Essays / blog / writing
- Notes / digital garden / wiki
- Reading list / bookshelf
- Uses page (tools, hardware, setup)
- Resume / CV (or link to PDF)
- Contact (email, social, form)
- Newsletter signup
- RSS / Atom feed
- Changelog (site or life updates)
- Photo gallery
- Talks / podcasts / appearances
- Guestbook / webring (retro-web aesthetic)
For each picked section, ask one follow-up: does this exist yet? Sections without content get marked [deferred] in the concept doc so the user doesn't ship empty pages.
6. Stage 4 — Tone & personality
Pick 2-3 adjectives. These anchor stage 5's visual suggestions and stage 6's copy voice.
Present as opposing pairs so picks force tradeoffs:
- minimal ↔ dense
- playful ↔ serious
- warm ↔ clinical
- raw ↔ polished
- intimate ↔ public
- experimental ↔ conventional
- fast / scannable ↔ contemplative / long-form
- confident ↔ self-deprecating
A user who picks minimal + playful + warm gets very different suggestions than dense + serious + clinical. Record the picks verbatim — they go into the concept doc as the brief.
7. Stage 5 — Visual direction
Eight archetypes. Rank the top 3 by fit based on stages 1-4, but show the full list so the user can override.
| Archetype | Feel | Fits when stages 1-4 say... | Reference sites |
|---|
| Terminal / CLI | monospace, sparse, command-line | dev audience, minimal, raw, archive | sive.rs, wiki.nikiv.dev, ratfactor.com |
| Editorial / Swiss | strong type, grid, generous whitespace | polished, serious, professional calling card | rauno.me, paco.me, linear.app |
| Brutalist | raw HTML, default styles, no chrome | experimental, raw, intimate, dev audience | brutalist-web.design, motherfuckingwebsite.com |
| Zine / maximalist | collage, mixed fonts, layered textures | playful, experimental, community audience | cassie.codes, lynnandtonic.com |
| Minimalist portfolio | single column, big images, lots of whitespace | portfolio, polished, recruiters/clients | many designer portfolios |
| Notebook / garden | wiki-like, dense interlinks, evergreen | digital garden, archive audience, dense | gwern.net, andymatuschak.org |
| Magazine / story | long-scroll narrative, art-directed, hero imagery | project launcher, contemplative, open web | pitchfork.com long-reads, the verge features |
| Database / index | filterable table, almost a UI | dense, archive, lots of artifacts | are.na profiles, derek sivers' /now directory |
Show the ranking with one-sentence rationale per pick, e.g. "Terminal/CLI fits because you picked dev audience + minimal + raw." User picks one; if they override the ranking, ask why and record it (the override often reveals a constraint not surfaced earlier).
8. Stage 6 — Synthesis
Produce 2-3 distinct concept directions, not one. Even if the user is decided, alternatives expose what they're trading off.
Concept doc shape
For each direction, write a markdown doc with these sections:
# Concept: <name>
## One-line pitch
<the site in 15 words or fewer>
## Brief
- Purpose: <stage 1 picks>
- Audience: <stage 2 picks, primary first>
- Tone: <stage 3 adjectives>
- Visual archetype: <stage 5 pick>
## Information architecture
<tree of pages/sections, max 2 levels deep>
## Homepage strategy
<what the homepage does in 2-3 sentences — first impression, primary action, >
<2-3 sentences in the chosen voice — about section opener, or homepage tagline + subhead>
The three directions should differ on a real axis, not be cosmetic variants:
- Concept A = the obvious read of the user's picks
- Concept B = optimizes harder for the primary audience (often more minimal)
- Concept C = a deliberate stretch — what if the experimental dial went one click further?
If two of the three end up nearly identical, drop one and explain why.
9. ASCII homepage wireframe
One per concept. Keep it 80 cols wide, label regions in [BRACKETS]. Show hierarchy with box-drawing or simple dashes.
Example for a terminal/CLI portfolio:
+------------------------------------------------------------------------------+
| ~ ramon.dev [now] [writing] [/] |
+------------------------------------------------------------------------------+
| |
| ramon alvarez |
| go developer · tooling · personal CLIs |
| |
| > currently building rsk, a skill management CLI for claude code |
| |
| --- recent ---------------------------------------------------------- |
| 2026-05-18 shipped: ralvaskills v0.3 |
| 2026-05-02 essay: why I bundle skills as one repo |
| 2026-04-21 project: rsk cli infrastructure |
| |
| --- projects -------------------------------------------------------- |
| ralvaskills personal AI skills toolkit [→] |
| rsk cli for managing skills [→] |
| |
+------------------------------------------------------------------------------+
| email · github · rss |
+------------------------------------------------------------------------------+
Wireframes are about proportion and hierarchy, not pixel layout. No colors, no fonts, no icons beyond ASCII. If a section needs explanation, add a one-line note below the wireframe, not inside it.
10. Anti-patterns
- Skipping stages because "the user already said". Surface their input as a default and confirm; don't assume. Half the value is forcing the user to look at what they didn't say.
- One concept doc instead of 2-3. Alternatives are how the user understands what they're choosing. Single-concept output is a failed run.
- Visual archetype before tone is locked. Stage order matters — visual is downstream of purpose/audience/tone, not parallel.
- Filling in content for
[deferred] sections. If the user hasn't written the essays, don't invent topic lists — the concept doc commits to structure, not content.
- Wireframes with implementation details. No "use shadcn Card here" — that's ui-ux-architect's job. Wireframes show what goes where.
- Generic suggestions. "A clean modern portfolio" is not a concept. Every concept doc must commit to specific picks on every axis.
11. Hand-off
Once the user picks one of the 2-3 concepts, the concept doc is the brief for:
- ui-ux-architect — for tokens, components, accessibility, the four required states.
- Built-in
frontend-design skill — for the actual code if going production-grade.
The concept doc should be saved to the project repo (e.g. docs/concept.md) so it survives as the design rationale.
12. Cross-skill ties
