agent-ready

安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install agent-ready
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 agent-ready。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

agent-ready 是 Openclaw Skills 工作流，用于让个人和品牌网站更易于 AI 智能体、爬虫、研究工具和基于浏览器的助手理解。它会审计网站身份、信任信号、机器可读数据、内容可访问性、爬虫可达性以及面向智能体的文件，并通过评分后的 Ora 报告和针对性验证工具进行检查。
该技能协调一个编排器与一个或多个编码智能体，同时执行严格的操作边界。Ghost 页面和内容等 CMS 级更改会直接处理，代码仓库更改则通过结构化规范交接，并且每项改进都会在工作流继续前进行线上验证。这使 Openclaw Skills 能够实用地改善 AI SEO，同时避免将平台限制误判为真正的技术问题。

应用场景

在制定面向 AI 的 SEO 改进计划前，审计个人网站或创作者品牌的 AI 智能体可发现性。
识别缺失或内容单薄的
/about
、
/contact
/privacy
信任锚点页面。
添加包含身份详细信息和已验证
sameAs
个人资料链接的 Person JSON-LD 结构化数据。
在 Ghost 网站上创建并验证智能体可读取的
llms.txt
文件。
调查核心页面内容是否无需 JavaScript 执行即可在原始 HTML 中获取。
确认不存在的 URL 返回真实的 404 响应，而不是误导性的 200 响应。
区分可操作的网站问题与 Ghost Pro 托管限制，例如托管 WAF 行为和 markdown 内容协商。
跨会话跟踪 Ora 分数、已验证的改进以及仍受平台限制的项目。
通过 Openclaw Skills 工作流，将主题、边缘函数、robots.txt、重定向或其他 git 管理的更改交给编码智能体。

工作原理

在每个会话开始时于 https://ora.sh 运行 Ora 审计，并将评分报告保留在上下文中；网站发生更改后，之前的报告会被视为过时。
根据九项检查清单和评分指南审查 Ora 发现，以区分可修复缺口、误报和平台限制。
通过 Ghost Admin API 创建或改进 /about、/contact 和 /privacy 等信任锚点页面，但只有在所有者批准确切文案后才发布。
通过 Ghost Pro 代码注入添加 Person JSON-LD 区块，并包含所需的 @type、name、url、description 和 sameAs 字段。
追加结构化数据前先获取并读取现有的 Ghost head 注入内容；绝不覆盖已有注入代码。
将 llms.txt 作为 Ghost 页面发布到 /llms.txt/，或者使用版本控制的原始文件，并在需要代码仓库所有权时设置重定向。
更改前使用 curl 手动调查原始 HTML 内容和 404 行为，因为 Ghost 服务器渲染和边缘行为可能产生审计误报。
根据需要使用直接 URL、curl、浏览器快照、Google Rich Results Test、Schema.org Validator、llmstxt.cloud 或 Lighthouse 验证已完成的工作。
将基于代码仓库的更改放入 [AGENT_HANDOFF] 区块交给编码智能体，而不是由编排器编辑 git 管理的文件。
在 markdown 历史表格中记录已验证的 Ora 分数、已完成项目以及仍受平台上限限制的项目。

配置指南

具备浏览器访问能力、兼容 Openclaw Skills 的编排器，用于执行 Ghost Admin 任务。
用于页面、文章、图片、成员和标签的 Ghost Admin API 凭据。
用于经过身份验证的浏览器会话工作的专用 Ghost staff 账户。
可联系网站所有者，以明确批准所有面向公众的文案。
本地已安装 curl、node 和 python3。
在需要代码仓库更改时，使用 Codex 或 Claude Code 等基于 git 的编码智能体。
克隆技能代码仓库并进入技能目录：
git clone https://github.com/highnoonoffice/hno-skills.git
cd hno-skills/agent-ready
确认所需命令行工具可用：
curl --version
node --version
python3 --version
操作流程
打开 https://ora.sh，为目标域名运行一次全新的审计。
解读分数前阅读 references/ora-scoring-guide.md。
使用 Ghost 凭据和浏览器访问配置编排器，并使用专用 staff 账户而非所有者账户。
为每个新建或更新的公共页面准备确切文案，并在发布前获得所有者的明确批准。
更新 Ghost 页面时，先获取当前资源，并在 PUT 请求中包含其 updated_at 值，以避免 409 冲突。
对于 Ghost Pro 代码注入、网站设置和重定向，使用浏览器会话；仅使用集成令牌通常会在这些区域收到 403 响应。
在继续下一个检查清单项目之前，使用线上 curl 请求或浏览器快照验证每一项已完成的改进。
会话结束后重新运行 Ora，并记录新分数和已验证的更改。

数据架构

网站产物
产物 位置或格式 用途
信任锚点页面 /about、/contact、/privacy 通过每页至少 500 个字符的实质性内容，建立可识别且值得信赖的网站所有者。
Person JSON-LD Ghost 网站页眉中的 JSON-LD 脚本 提供机器可读的身份、网站所有权、描述和外部验证链接。
llms.txt 位于 /llms.txt/ 的 Ghost 页面，或重定向的原始代码仓库文件 为 AI 智能体简明说明网站由谁运营、包含什么内容以及在哪里查找关键信息。
可选 AI.txt 通过 Ghost 页面或重定向提供的 /ai.txt 传达新兴的 AI 内容许可和权限偏好；不同于专注于可发现性的 llms.txt。 404 响应 任何不存在的 URL 必须返回真实的 HTTP 404，以免智能体将缺失内容误认为有效页面。 原始 HTML 内容 初始服务器响应 用于确认无需客户端 JavaScript 即可获取核心内容和 H1。
JSON-LD 分类
@type：Person
必需身份字段：name、url、description
验证分类：包含社交资料、出版署名和独立确认页面的 sameAs 数组
个人网站指南：将组织级身份合并到 Person 记录中，而不是添加不受支持的企业字段
当网站不代表拥有真实业务数据的组织时，避免伪造 contactPoint 或 address 值
会话分数日志
每次审计会话维护一行 markdown 记录：
日期 分数 本次会话完成的项目 剩余上限项目
YYYY-MM-DD 51 基线 全部
YYYY-MM-DD 57 信任页面、JSON-LD、llms.txt markdown 协商、WAF
只记录已验证上线的更改，并将剩余发现标记为可操作或由平台控制。此历史记录有助于 Openclaw Skills 用户判断分数停滞是因为所有可修复工作都已完成，还是遗漏了某个问题。

高级特性

强制性的顺序技能门会在缺少全新的 Ora 审计、所有者文案批准、注入前读取、变更后验证或编码智能体交接时停止执行。
多智能体协调将 CMS 和浏览器职责与基于代码仓库的编码工作分开。
结构化的
[AGENT_HANDOFF]
区块支持 Codex 和 Claude Code 工作流，用于主题文件、边缘函数、robots.txt、已部署的重定向以及基于拉取请求的更改。
适配 Ghost Pro 的部署逻辑区分 Admin API 能力与仅限浏览器的代码注入、设置和重定向操作。
仅追加的代码注入通过要求先读后写来保护现有 Ghost 页眉内容。
每项改进后的线上验证可避免将 API 成功响应视为更改已公开部署且正确的证明。
工具专业化将 Ora 评分与 llmstxt.cloud、Google Rich Results Test、Schema.org Validator、Lighthouse、curl 和浏览器快照结合起来。
误报处理可避免在 Ghost 的服务器渲染内容、原生 404 行为、未知爬虫信号和托管 WAF 限制上进行不必要的工作。
可选的
AI.txt
支持可帮助网站所有者将 AI 内容权利与
llms.txt
可发现性指南分开记录。
参考操作手册提供评分解读、Ghost API 模式、JSON-LD 模板、llms.txt 模板、验证命令和拉取请求审查清单。

name: agent-ready version: 1.0.0
description: "Audit any personal or brand site for AI agent discoverability and fix what is fixable — structured data, trust anchor pages, llms.txt, crawlability checks, and Ghost-specific deployment patterns. Ghost Pro native." homepage: https://github.com/highnoonoffice/hno-skills
source: https://github.com/highnoonoffice/hno-skills/tree/main/agent-ready
binaries: [curl, node, python3]
license: MIT

agent-ready

A site is agent-readable when an AI agent — a browser-using assistant, a crawler-fed model, a research tool — can land on it, understand who runs it, and find the specific things it's looking for (contact info, a body of work, machine-readable facts about the owner) without a human translating for it. Most sites are not built with that reader in mind. This skill audits a site against a fixed checklist, tells you what's actually broken versus what only looks broken, and either fixes it directly or hands the fix to a coding agent when the fix requires touching a git-managed codebase.

This skill is written for three cooperating agents:

An orchestrator agent (browser-capable, holds CMS/API credentials) — runs the audit, evaluates findings, executes CMS-level work directly: structured data injection, trust anchor page creation, redirect wiring, and any step that only needs an API call or a browser session.
A coding agent (works inside a git repository, opens pull requests) — handles anything that requires modifying a file that lives in version control: theme templates, edge functions, server config, redirect logic that ships as code.
A second coding agent role, interchangeable with the first — the skill does not distinguish between coding agents. Whichever one is available receives the same handoff format and does the same class of work.

The orchestrator never edits repository files itself. The coding agent never touches CMS credentials or executes browser sessions. That boundary is enforced by Gate 5 below, not by convention.

skill_gates
About to execute any agent-readiness improvement Have I run the Ora audit at https://ora.sh this session and have the scored report in context? Proceed. Stop. Run the audit first. Never execute fixes from memory or a previous session report. About to create or update any public-facing page (about, contact, privacy, llms.txt) Has the owner read and explicitly approved the exact copy that will be published? Proceed. Stop. Show the copy verbatim. Wait for approval. Never publish unreviewed copy. About to write to Ghost code injection head or footer Have I fetched and read the current head injection content this session before appending? Proceed. Stop. Fetch first. Append-only — never overwrite. Just completed any improvement step Have I verified the change is live via curl or browser snapshot before moving to the next item? Proceed. Stop. Verify first. API 200 does not mean live and correct. The fix requires modifying a file in a git repo (theme files, edge config, redirect logic in code) Am I handing this to the coding agent via a structured handoff block rather than executing it myself? Proceed. Stop. The orchestrator does not modify repo files directly. Write the spec block, not the code.

Every gate is hard and sequential within its scope: session_start gates block everything downstream, pre_publish and pre_inject gates block the single step they guard, and post_execute repeats after every improvement, not just the last one. If a gate fails, stop and resolve it before continuing — do not work around it, and do not treat a previous session's pass as still valid.

Audit Tools

Several tools audit agent-readiness from different angles. Run more than one — they catch different things.

Ora — https://ora.sh Primary tool for this skill. Returns a scored 0–100 report with Essential and Recommended findings, each with evidence and a recommended fix. Run this first every session. See references/ora-scoring-guide.md for score interpretation.

llmstxt.cloud — https://llmstxt.cloud Validates your llms.txt specifically — checks that it exists at the expected path, parses correctly, and follows the emerging convention. Run this after completing checklist item 3.

Google Rich Results Test — https://search.google.com/test/rich-results Validates JSON-LD structured data against Google's rich result types. Run this after completing checklist item 2. Paste the live URL, not the raw JSON — it needs to test the actual embedded block.

Schema.org Validator — https://validator.schema.org Broader vocabulary coverage than the Rich Results Test. Use for schema types Google's tool doesn't specifically support (SoftwareApplication in some configs). Also paste the live URL.

web.dev/measure (Lighthouse) — https://web.dev/measure General page quality audit including some crawlability signals. Less agent-specific than Ora but useful for catching content-without-JS issues independently. Run if checklist item 5 needs deeper investigation.

No single tool covers everything. Ora drives the session. The others verify specific steps.

A report from an earlier session is stale the moment any change has been made to the site since; re-run rather than trusting memory of a prior score — see Gate 1.

Read references/ora-scoring-guide.md for how to interpret the Ora score and which findings are platform limitations versus real gaps before acting on the report.

The 9-Item Checklist

Work the list in order. Each item states what it means, whether to act on it directly, investigate before acting, or skip it outright, plus execution and platform notes.

1. Trust anchor pages (/about, /contact, /privacy)

What it means: These are the pages an agent (or a human it's assisting) checks to verify a site is run by a real, identifiable entity. A missing or thin /about page is one of the most common reasons a site reads as low-trust to both agents and search crawlers.

Action: Do — this is directly fixable in one session.

Execution notes:

The orchestrator creates these via the Ghost Admin API pages endpoint with ?source=html.
Each page needs 500+ characters of real content — not placeholder text, not a single sentence. A thin page fails the same way a missing page does.
Gate 2 applies: show the owner the exact copy for each page before it's created, and wait for explicit approval.
Verify with a direct URL check on each page after creation — see Gate 4. 2. Person JSON-LD schema

What it means: A Person schema block in the page's structured data gives agents and search engines a machine-readable identity record: who the site belongs to, and where else that identity is verifiable.

Action: Do.

Execution notes:

On Ghost Pro this is written via code injection (site header), which requires a browser session — integration tokens cannot write to code injection. See the Ghost Pro Constraints section below.
Required fields: @type: Person, name, url, description, and a sameAs array listing public profile URLs (social platforms, publication bylines, any page that independently confirms the identity).
Gate 3 applies: fetch and read the current head injection content before writing. Append the new script block — never replace what's already there.
Verify with: curl -s https://yourdomain.com | grep -o 'application/ld+json' 3. llms.txt

What it means: A plain-text file at a well-known location that gives agents a direct, structured summary of the site — who runs it, what to expect, where to look for specific things — without needing to parse HTML.

Action: Do.

Execution notes:

Option A (recommended): a Ghost page with the slug llms.txt, which Ghost serves at /llms.txt/. Self-contained, no additional infrastructure.
Option B: a raw file committed to a GitHub repo, with a Ghost redirect rule pointing /llms.txt at the raw URL. Use this only when the content needs to live in version control for other reasons (e.g., it's generated from repo content).
Gate 2 applies: the owner approves the exact copy before publish.
Verify with: curl -s https://yourdomain.com/llms.txt/ and confirm real content comes back, not a 404 or a redirect loop.
See references/llms-txt-templates.md for section-by-section templates by site type.
Bonus: AI.txt (emerging standard, optional)

What it means: AI.txt is the IAB Tech Lab's emerging standard for AI content licensing declarations — it tells AI systems what they are and are not permitted to do with your content (train on it, summarize it, reproduce it). Distinct from llms.txt, which is about discoverability and routing. AI.txt is about rights and permissions.

Action: Optional — not yet scored by Ora or enforced by any major AI system. Worth knowing about and worth adding if you have a position on AI training use of your content.

Execution notes:

Served at /ai.txt at the site root — same placement convention as robots.txt.
Same Ghost Pro hosting constraint as llms.txt: use a Ghost page with slug ai.txt or a redirect rule pointing to a hosted file.
Format spec: https://ai-txt.org
For a personal content site with no explicit objection to AI training use, omitting this file is fine — absence is not interpreted as permission denied by current tools. 4. Organization schema completeness

What it means: Ora may separately flag organization-level structured data. For a personal or single-owner brand site, this is not a distinct build — it folds into the Person schema from item 2.

Action: Fold into item 2 — no separate action if that step was done correctly.

Execution notes:

Add or extend the sameAs array on the Person schema rather than building a parallel Organization block.
contactPoint and address are business/organization fields — skip these for personal sites; they don't apply and adding them without real data creates bad structured data, which is worse than none. 5. Content without JavaScript

What it means: Whether the page's core content is present in the raw HTML response, or only appears after client-side JavaScript runs. Agents and crawlers that don't execute JavaScript only see the former.

Action: Investigate before acting.

Execution notes:

Ghost is server-rendered by default, so this finding is often a false positive — usually triggered by a sparse homepage (e.g., a homepage that's mostly a hero image and a feed teaser) rather than an actual client-rendering gap.
Investigate with:

curl -s https://yourdomain.com | python3 -c "import sys; h=sys.stdin.read(); print(len(h), 'chars'); print('H1 found' if '