docs-detect-source — Identify and route a docs source
Workflow#
- Inspect the input: classify as a plain URL, a GitHub repo URL, or a local path.
- For a plain URL — fetch the page and look for platform signals in HTML meta tags, CDN links, and domain name. If no platform matches, classify as a generic website.
- For a GitHub repo URL — fetch root contents via the GitHub API and look for known config files (
mint.json,SUMMARY.md,docusaurus.config.js,.vitepress/,astro.config.*, etc.). If only a README and source directory are present, classify as a code repo. - For a local path — inspect the directory structure for the same config file signals.
- Map the detected type to a downstream skill and report both.
Guardrails#
- For detection (platform signals in meta tags / CDN links), a plain HTTP fetch of the raw HTML is enough — those signals live in the shell. But note: a non-empty HTML shell does not mean the content is there. Most product sites are JS SPAs whose
<main>is empty until rendered, so the downstream builder (/docs-from-site) must render with a browser to read real content — do not let a 200 with populated<head>fool the content pass into skipping the render. - A single ambiguous signal is not enough — require at least one platform-specific config file or meta tag before assigning a platform type.
- If detection is inconclusive, default to
website//docs-from-siterather than blocking. - Never mutate the source; detection is read-only.
Skill Routing#
| Detected type | Downstream skill | Subagent |
|---|---|---|
website |
/docs-from-site |
docs-site-crawler (Haiku) |
github-code-repo |
/docs-from-code |
docs-code-crawler (Haiku) |
| Any recognized docs platform | /docs-from-docs |
docs-platform-importer (Haiku) |
Acceptance Criteria#
- Input classified into exactly one type without prompting the user
- Platform identified from signals (meta tags, config files, domain) rather than guessing
- Downstream skill name reported alongside the detected type
- Inconclusive inputs default to
websitegracefully