v1.0.0 to v1.0.1

---

name: website-concept-architect

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](../ui-ux-architect/SKILL.md) 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:

```markdown

# 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, what the visitor leaves knowing>

## Sample copy voice

<2-3 sentences in the chosen voice — about section opener, or homepage tagline + subhead>

## What this concept sacrifices

<honest list of what's deprioritized vs. the other concepts — every concept trades something>

## Ascii homepage wireframe

<see §9>

```

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:

```

+------------------------------------------------------------------------------+

+------------------------------------------------------------------------------+

| |

| |

| |

| --- recent ---------------------------------------------------------- |

| |

| --- projects -------------------------------------------------------- |

| |

+------------------------------------------------------------------------------+

| 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](../ui-ux-architect/SKILL.md) — 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

- [ui-ux-architect](../ui-ux-architect/SKILL.md) — implementation-level standards; this skill feeds it the brief.

- [demo-presentation-architect](../../personal/demo-presentation-architect/SKILL.md) — similar interactive walk-through structure, different domain.

- [demo-script-architect](../../personal/demo-script-architect/SKILL.md) — narrative principles (audience-first, progressive reveal) apply to homepage copy too.