plan-website

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: plan-website
description: Interactively plan a website with a non-technical user - project snapshot, existing site/brand assets, inspiration sites, sitemap, per-page copy, and visual direction - before any code gets written. Actively asks for an existing website URL, brand/visual assets, and 2-3 sites whose look the user likes, then writes a maintained website/site-plan.md that build-website consumes next. Use whenever the user wants to plan, scope, or write copy for a website; needs help figuring out what pages a site should have; wants a sitemap or content outline; or says things like "I need a website," "help me plan my site," "what pages should my site have," or "I don't know where to start with a website." Trigger even if the user never says the word "website" but clearly wants an online presence for a business, portfolio, project, event, or personal page.
allowed-tools:
  - Read
  - Write
  - Edit
  - WebFetch
  - WebSearch
---

# Plan Website

Help a non-technical user turn a vague "I need a website" into a concrete, written plan another skill can build from.

This is the first of three chained skills: **plan-website → build-website → deploy-website.** Your job stops at a plan - don't write site code here, that's `build-website`'s job. But do it well: the better this plan is, the less back-and-forth the build phase needs.

## Why this skill front-loads research

Two things separate a good site plan from a generic template, and both come from *looking things up* instead of asking the user to describe everything from scratch:

- **What already exists.** Most people asking for a website aren't starting from nothing - they have an old site, a logo, a social bio, some reviews, a flyer. If you don't actively ask for and pull in what already exists, you'll make the user re-type things they've already written, and you'll lose real facts (their actual tagline, their actual services) in favor of generic filler.
- **What "good" looks like to them.** "Make it look nice" is not actionable. "Make it feel like this site, especially the big bold header and the muted colors" is. Asking for 2-3 sites the user likes turns a vibe into something concrete you can point to later.

Both are cheap to ask for and expensive to skip.

## Where the plan lives

```
website/
  site-plan.md   # the plan you're writing
  assets/        # logos, photos, brand notes, anything gathered along the way
```

On start, check whether `website/site-plan.md` already exists. If it does, read it, tell the user what you found, and continue/update it rather than starting over - this is a living document, not a one-shot form.

## Interaction mode

This is a **conversation, not an intake form.**

- **One step at a time.** Don't fire off ten questions in one message. Ask a couple, listen, reflect back what you heard, move on.
- **Plain language.** No jargon (sitemap, CTA, hero section, etc.) without a one-line plain-English gloss the first time you use it.
- **Do the legwork.** If the user gives you a URL or names a site they like, go look at it (`WebFetch`) instead of asking them to describe it to you.
- **Never invent facts.** Pricing, credentials, years in business, testimonials - if you don't have it from the user or their existing materials, leave it flagged as open rather than making something up.
- **Adapt pace to the person.** Some users will have all of this ready to go; others need you to suggest examples and options at every step. Read the room.

## The phases

Run these roughly in order, but stay flexible - if the user jumps ahead or answers three steps at once, don't force them back through a script.

### 1. Project snapshot

Get oriented in 3-4 quick questions:

- What's the site for? (a business, a portfolio, a nonprofit, a personal project, an event - anything)
- Who's it for - who's the visitor?
- What's the one thing you want a visitor to do? (book a call, buy something, sign up, get in touch, just learn more)
- Does a website already exist f