website
Build or update a project website — reads docs/Website.md rules (hosting, branding, static/no-CDN, subpage links) before generating any content
Build or Update Project Website
Triggered by requests like "build a website for this project", "update the website", or "add a website for <project>".
Before writing anything
- Read
docs/Website.md(or@docs/Website.mdif already bundled in AGENTS.md) in full. It is the rules doc for this task — hosting assumptions, branding, content honesty, subpage/link constraints, and the static/no-CDN requirement are not optional. - Look at sibling projects'
website/dirs (see~/projects/.uman.tomlfor the managed list) for prior art. If it isn't clear whether this project's site should be fancy or simple, ask the user which sibling project to use as inspiration — don't guess.
While building
- Follow every rule in
docs/Website.md: no GitHub assumptions/octocats unless asked, no unproven feature claims, a "Why" section, relative links only, static output, vendored (not CDN-pulled) JS assets, and no invented JS/TUI demo unless explicitly requested. - Keep output under this project's
website/dir so it is picked up byuman website sync <project>.
Before publishing
- If the change includes new media (screenshots, recordings), get the user's explicit confirmation that it matches expectations before publishing or syncing (see global media-verification rule).
- Don't run
uman website syncor push unless the user asks — building the content is the task; publishing is a separate, confirmed step.
- Content
- file-backed
- License:
- AGPL-3.0-or-later
- Origin
- first-party
- Source:
- docs/commands/website.md
- Source revision
4e3b8d592416fbf93a2af218882c1abef78faed6- Requires
- Targets
- codex, claude
- Invocation
- /website
Related skills
- docup — Review and update bounded repository documentation by category (testing, architecture)
- domain-modeling — Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR.
- evergreen — Create/update evergreen docs and issue files for the current session
- grill-with-docs — A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.