Website Concept Architect

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

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.

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, 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:

+------------------------------------------------------------------------------+
| ~ 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

• ui-ux-architect — implementation-level standards; this skill feeds it the brief.
• demo-presentation-architect — similar interactive walk-through structure, different domain.
• demo-script-architect — narrative principles (audience-first, progressive reveal) apply to homepage copy too.