# An agent needs a capability page, not just a crawl map > Why llms.txt is only the map, why skill.md is the operating note, and why manifests, bot access, and proxy hygiene decide whether the surface gets used. - Canonical HTML: https://growth.iangoh.com/blog/an-agent-needs-a-capability-page-not-just-a-crawl-map/ - Published: 2026-05-27 - Updated: 2026-05-27T23:59:00Z - Categories: AI Search, brand trust, technical SEO - Niches: AI products, developer tools, SaaS, creator tools, B2B software ## On this page - A map and an operating note do different jobs - Discovery should survive the real production path - Trust gets better when the file is verifiable - Access policy still decides whether any of this gets seen ## Start with these related tactics - [Root skill.md for product capability discovery](/growth-ideas/root-skill-md-for-product-capability-discovery/): Publish a root `/skill.md` that tells agents what your product can do, which inputs it needs, and which constraints matter instead of forcing them to infer capabilities from scattered docs. - [Agent-skills index for multi-workflow products](/growth-ideas/agent-skills-index-for-multi-workflow-products/): If the product has several workflows, publish separate skill files plus a `/.well-known/agent-skills/index.json` manifest instead of forcing one giant capability blob. - [Reverse-proxy forwarding for agent skill paths](/growth-ideas/reverse-proxy-forwarding-for-agent-skill-paths/): If docs sit behind a proxy or custom domain, forward `/skill.md`, `/.well-known/skills/*`, and `/.well-known/agent-skills/*` instead of letting the discovery layer die at the edge. A lot of teams now know they should publish llms.txt. That is useful. It tells the agent where the pages are. It does not tell the agent what job the product can finish, what inputs it needs, or which limits matter before it starts acting. That second layer is where a capability page starts to matter. ## A map and an operating note do different jobs That is the clean distinction behind [root skill.md for product capability discovery](/growth-ideas/root-skill-md-for-product-capability-discovery/). A machine index is good for finding pages. A capability file is good for telling the agent what the product actually does and how to approach it. It pairs naturally with [publish llms.txt for agent retrieval](/growth-ideas/publish-llms-txt-for-agent-retrieval/). One file is the site map. The other is the field note. If you only ship the map, the agent still has to guess its way into the workflow. ## Discovery should survive the real production path The boring but important move is [reverse-proxy forwarding for agent skill paths](/growth-ideas/reverse-proxy-forwarding-for-agent-skill-paths/). A lot of teams generate the right files upstream and then lose them on the custom domain where the agent actually lands. This is the same family of problem as [agent-skills index for multi-workflow products](/growth-ideas/agent-skills-index-for-multi-workflow-products/). The value is not just writing the skill. The value is making the routes easy to discover from the hostname the buyer already trusts. ## Trust gets better when the file is verifiable I like [agent-skills manifest with sha256 integrity](/growth-ideas/agent-skills-manifest-with-sha256-integrity/) for that reason. It is a small infrastructure detail, but it turns the capability layer into something closer to a real interface. The client can tell whether it fetched the expected instructions instead of a stale or mangled copy. That matters more once the agent is about to use a live workflow. The same logic is behind [skill frontmatter with compatibility and tool constraints](/growth-ideas/skill-frontmatter-with-compatibility-and-tool-constraints/). Clear constraints make bad automation less likely. ## Access policy still decides whether any of this gets seen The other quiet failure is access policy. [Explicit AI-bot allowlist in robots.txt](/growth-ideas/explicit-ai-bot-allowlist-in-robots-txt/) looks almost too small to mention, but it decides whether the discovery files get fetched and cited in the first place. This is strongest for AI products, developer tools, SaaS docs, and creator software with a self-serve surface. If the product expects an assistant to help a buyer, a user, or an internal team, then the assistant needs more than a list of URLs. It needs the plain operating note too. The activation move after that is simple: pair the capability page with [one-command skill install from docs URL](/growth-ideas/one-command-skill-install-from-docs-url/) so discovery can turn into use without another layer of explanation. ## Related GrowthDex tactics - [Root skill.md for product capability discovery](/growth-ideas/root-skill-md-for-product-capability-discovery/) - AI Search, Documentation, Website - [Agent-skills index for multi-workflow products](/growth-ideas/agent-skills-index-for-multi-workflow-products/) - AI Search, Documentation, Integrations - [Reverse-proxy forwarding for agent skill paths](/growth-ideas/reverse-proxy-forwarding-for-agent-skill-paths/) - AI Search, Website, Documentation - [Agent-skills manifest with sha256 integrity](/growth-ideas/agent-skills-manifest-with-sha256-integrity/) - AI Search, Documentation, Integrations - [Explicit AI-bot allowlist in robots.txt](/growth-ideas/explicit-ai-bot-allowlist-in-robots-txt/) - AI Search, SEO, Website ## Essay chronology - [Newer essay: The help center should feel local before it feels complete](/blog/the-help-center-should-feel-local-before-it-feels-complete/) - support-led growth, technical SEO, brand trust - [Older essay: The changelog should meet the user where the work happens](/blog/the-changelog-should-meet-the-user-where-the-work-happens/) - changelog strategy, brand trust, retention ## Keep reading - [The agent-ready page should announce itself](/blog/the-agent-ready-page-should-announce-itself/) - seo, AI discovery, documentation - [The support portal should know what to reveal](/blog/the-support-portal-should-know-what-to-reveal/) - support-led growth, brand trust, technical SEO - [The support surface should stay attached to the work](/blog/the-support-surface-should-stay-attached-to-the-work/) - support-led growth, brand trust, technical SEO ## Continue through the blog - [SaaS](/blog/#path-saas) - 3 essays in this path - [AI products](/blog/#path-ai-products) - 3 essays in this path - [developer tools](/blog/#path-developer-tools) - 3 essays in this path ## Sources - [Mintlify Docs: skill.md](https://www.mintlify.com/docs/ai/skillmd) · [GrowthDex source hub](/sources/mintlify-docs-skill-md-mintlify-com/) - [Mintlify Blog: Your docs are now discoverable by agents](https://www.mintlify.com/blog/skills-discovery-from-any-url) · [GrowthDex source hub](/sources/mintlify-blog-your-docs-are-now-discoverable-by-agents-mintlify-com/) - [Vercel Knowledge Base: Agent Readability](https://vercel.com/kb/guide/agent-readability-spec) · [GrowthDex source hub](/sources/vercel-knowledge-base-agent-readability-vercel-com/) ## Editing notes - Kept the essay on one narrow distinction between discovery maps and capability notes instead of drifting into generic claims about the future of agents. - Used concrete objects like routes, proxies, manifests, digests, and robots rules so the argument stays close to implementation reality. - Avoided launch-style hype and let the specific file behaviors carry the point. - Ended with an activation step that is operationally useful, not a padded summary. ## Advisory If you want help turning this into a growth system, Ian Goh offers advisory at https://iangoh.com/advisory.