site-architecture 适合网站从几页扩展到多个栏目，或现有内容已经很难找到时使用。它规划的是读者怎样进入和连接页面，不只是生成一个 XML 站点地图。先有页面清单与用户任务，结构图才有判断依据。
安装与调用
在项目目录的终端运行下面的命令，只安装这个 Skill 到 Claude Code：
npx skills add coreyhaines31/marketingskills --skill site-architecture -a claude-code
需要 Node.js 和可用的 npx。若使用 Codex，把 -a claude-code 换成 -a codex；在对话里明确要求使用 site-architecture 并附上材料，不把终端安装命令当成任务提示。其他客户端应使用自身的技能选择入口。
先做清单，再画树
整理 URL、页面标题、用途、访问量或业务重要性，以及当前从哪里能进入。新站则先写用户需要完成的三到五个任务，例如找入门教程、比较方案和查看价格。可以这样输入：
使用 site-architecture 整理 pages.csv。
这是一个技能教程站，读者要能按任务找教程、查看使用前提、回到相关内容。
先指出重复用途与孤立页面，再给页面树、URL 表、主导航及内链方案。
现有高访问页面需保留可达性；地址确需变化时逐条列出旧地址和真正对应的新页面。
分组依据应是读者理解的任务或主题，而不只是内部团队分工。首页、栏目页、教程页分别承担不同职责；并非每个标签都需要一个独立且可索引的页面。重要内容路径应清楚，官方给出的层级与点击数可以作为检查线索，不应变成僵硬的搜索规则。
用具体找东西的过程检验设计
要求同时交付文字页面树和 URL 表，表里写出父级、导航位置与优先级。主导航负责核心入口，页脚可以放较稳定的辅助信息，面包屑帮助理解层级，正文内链连接正在阅读的相关问题。不要把所有责任都塞给同一排菜单。
拿三项真实任务走一遍方案：初次访问者从哪里开始，读到一半需要前置知识时去哪里，完成一篇教程后怎样找到下一步。若必须知道站内术语才能找到内容，就需要重命名或增加上下文入口。相关链接也应说明目标内容，不只写“点击这里”。
改版时保留旧 URL 到新内容的逐条对应表；只有确有相同或合理替代内容时才规划重定向，不能把所有旧地址都指向首页。上线前检查导航、内链和重定向是否真的实现，之后再抽查重要入口。结构图只是设计产物，最终要让真实页面和链接共同兑现这条阅读路径。
上线前请几位不熟悉网站的人分别找三类重要页面，不解释导航，记录犹豫的位置；再用站内搜索词和 404 记录补漏。不要为套用“三次点击”口号机械压平结构。
示例：合并两套让读者迷路的分类
假设教程站同时按“工具”和“用途”分类，结果一篇教程分别出现在两个几乎一样的栏目里，另有十篇文章没有入口。把当前导航、页面清单与搜索词交给 Skill：“使用 site-architecture 让想完成‘整理访谈’的读者找到对应教程。提出一级入口、用途页和详情页关系；标出重复栏目与孤立页。现有 URL 不默认更改，确需合并时给旧到新的映射和原因。”
验收时从首页出发实际找三项任务，不要只看 ASCII 树是否整齐。若读者必须先知道某个 Agent 名称才能找到“整理访谈”，说明分类按内部概念而非任务组织。若所有文章都从页脚堆链接，仍然缺少有意义的上下文。只有导航与相关页面内链都能把读者带到目标指南，结构才算可用。
公开流程如何接到实际开发
GOV.UK 做过多轮真实找页面任务，并根据实际路径调整导航。整齐的页面树和读者找得到内容是两项不同结果；前面的找页面任务才是验收依据。
一个公开流水线把 site-architecture 的文本与页面清单作为非交互 system prompt 指引送进策略阶段，再按逐路由建议修改代码；它并没有单独运行 slash 命令，也没有证明访客最终找页更快。
另一个公开的 Astro 建站流程把 site-architecture 排在搭建之前：先定页面层级、URL、导航与内链，再实现页面。该文件展示开发顺序，未提供访客找页面的测试结果。