Agentic-SEO-Skill: an LLM-first SEO audit skill for Claude Code, Codex and Antigravity
An LLM-first SEO analysis skill for Antigravity, Codex, Claude with 16 specialized sub-skills, 10 specialist agents, and 88 optional utility scripts used as evidence collectors.
At a glance
- What is it?
- Agentic-SEO-Skill packages 16 SEO sub-skills, 10 specialist agents and 88 Python scripts into a skill directory that Claude Code, Codex CLI, Antigravity, Cursor and six other tools can load. The scripts gather evidence; the model writes the findings. That split is the whole design, and it is also where the project's limits sit.
- Who is it for?
- Adopt it if your team already runs Claude Code, Codex CLI or Antigravity and wants SEO findings produced inside the same session as the code, with the evidence scripts on disk rather than a hosted dashboard. Do not adopt it if you need a scheduled crawler that runs without a human in the loop, or if you cannot read Python well enough to tell a script failure from a clean result.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 54 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Agentic-SEO-Skill is aimed at
Most SEO tooling is a hosted product with a dashboard. You paste a URL, wait, and read a score. The analysis happens on someone else's servers, against a rubric you cannot edit, and the output is a number you either trust or ignore. Agentic-SEO-Skill takes the opposite position: the analysis happens in your agent IDE, the rubric is a file in the repository, and the model has to show its evidence for each finding. The README states the workflow plainly. Collect page evidence first, with read_url_content preferred over scripts. Analyze with the LLM, attaching explicit proof to each finding. Label confidence as Confirmed, Likely or Hypothesis. Then prioritize by impact and effort and produce a structured action plan. The intended user is an engineer or technical marketer who lives in Claude Code, Codex CLI, Antigravity, Cursor or one of the other six supported editors, and who would rather read a Markdown action plan in the repo than log into a third-party console. It is not aimed at someone who wants a monthly PDF emailed to a client.
Two layers: scripts collect, the model judges
The repository separates evidence collection from reasoning, and that separation is visible in the layout. Under scripts/ there are 89 files, 88 Python plus one shell validation helper, each doing a narrow job. fetch_page.py retrieves a page with SEO crawler headers and writes local HTML. parse_html.py pulls titles, metadata, headings, links, images, schema and canonical signals out of that HTML. pagespeed.py produces Core Web Vitals and PageSpeed Insights evidence. crawl_audit.py walks multiple pages for status, metadata, depth and duplicate signals. indexability_matrix.py turns robots directives, meta robots, canonicals, HTTP status and sitemaps into a per-URL verdict. finding_verifier.py sits at the end and deduplicates, prioritizes and validates findings before the final report is written. Above the scripts sit 16 sub-skills, each a Markdown file in resources/skills/, covering audit, article, page, technical, content, schema, sitemap, images, geo, aeo, links, programmatic, competitors, hreflang, plan and github. Above those sit 10 specialist agents named for their remit: Technical SEO, Content Quality, Performance, Schema Markup, Sitemap, Visual Analysis, GitHub Analyst, GitHub Benchmark, GitHub Data and a global Verifier. The data flow runs one way. Scripts emit structured evidence, the sub-skill rubric shapes how the model reads it, the specialist agent supplies domain framing, and the Verifier suppresses contradictions before output. The one-command entry point is audit_runner.py, which the README says writes JSON, HTML, FULL-AUDIT-REPORT.md and ACTION-PLAN.md.
Installing it per editor, not once
There is no single install. The README's compatibility table gives a different destination and format for each tool, and the installer is described as shipping native formats rather than a generic copy. For Claude Code the skill directory goes to ~/.claude/skills/seo. For Codex CLI it goes to ~/.codex/skills/seo. Antigravity IDE expects <project>/.agent/skills/seo. Claude Cowork uses <project>/.claude/skills/seo and the README notes it is project-scoped, so you commit it to git. Cursor needs both <project>/.cursor/rules/seo.mdc and .cursor/skills/seo/. Windsurf takes <project>/.windsurf/rules/seo.md plus .windsurf/skills/seo/. Continue.dev uses .continue/prompts/seo.prompt as a slash command plus .continue/skills/seo/. GitHub Copilot reads .github/copilot-instructions.md plus .github/skills/seo/. Cline reads .clinerules plus .cline/skills/seo/. Two CI-facing commands are given for keeping the repository honest: python3 scripts/validate_skill_inventory.py checks for inventory drift, and python3 scripts/reference_freshness.py resources/references --max-age-days 90 fails when reference material is older than 90 days. The rubrics the model is told to apply live at resources/references/llm-audit-rubric.md, which the README says standardizes the finding format (Finding, Evidence, Impact, Fix), severity labels (Critical, Warning, Pass, Info), confidence labeling and the output contract.
What the confidence labels actually buy you
The three-tier label scheme is the most useful idea in the repository, and it is worth being precise about why. A conventional audit tool collapses everything into a severity. A missing canonical tag and a suspected soft-404 both surface as warnings, and the reader has no way to tell which one the tool actually verified. Requiring the model to mark each finding Confirmed, Likely or Hypothesis forces it to admit when it is inferring from partial evidence, which is exactly the failure mode of asking a language model to review a page. The rubric that enforces this is a plain Markdown file, so you can tighten or loosen it, and the Verifier agent exists to catch cases where two specialist passes disagree. The trade-off is that the labels are only as good as the model's discipline. Nothing in the material suggests any automated check verifies that a finding labelled Confirmed was in fact confirmed against script output. If the model skips a script and reasons from the page text alone, the label is self-assigned. Treat the labels as a prompt-engineering convention, not an enforced contract.
Where the skill stops being the right tool
The design assumes an interactive session. You open your editor, invoke the skill, and a model works through the evidence with you present. There is no scheduler, no queue and no alerting described in the material, so a site that needs continuous monitoring will not get it from this repository alone. The second constraint is the script count itself. Eighty-eight Python files is a large surface for a skill, and the README explicitly declines to document them all, deferring the full list and purpose notes to a wiki page. That means the authoritative description of most scripts lives outside the repository you cloned, and a wiki can drift from the code it describes. Third, the analysis quality is bounded by the model you point at it. The workflow puts read_url_content ahead of the scripts, which keeps the loop fast but means a weaker model may produce a confident report built on very little fetched evidence. Fourth, the GitHub-facing sub-skill and its three agents (GitHub Analyst, GitHub Benchmark, GitHub Data) are a distinct product from the website auditing path. If your interest is on-page SEO, that whole branch is dead weight in the clone.
How it differs from Screaming Frog and Sitebulb
The obvious comparison is a desktop crawler such as Screaming Frog, or a hosted auditor such as Sitebulb. Those tools decide what counts as a problem using rules the vendor wrote, and they produce the same output for the same crawl every time. Agentic-SEO-Skill inverts that. The rules live in resources/references/llm-audit-rubric.md and in the 16 sub-skill Markdown files, all of which you can edit, and the interpretation is done by a model that can weigh context a rule engine cannot. A crawler will flag a thin page; the model can read the page, notice it is a paginated archive, and downgrade the finding. The cost is reproducibility. Two runs of the same crawl through this skill can produce different reports, and the 90-day freshness check on resources/references suggests the maintainers know that reference data ages. If you need a defensible, repeatable audit trail for a client contract, a deterministic crawler is the safer instrument. If you need a first pass that reads like a senior consultant's notes and lands in the same repo as the fix, this is the shape you want.
Licence, maintenance and what upgrading costs
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is permissive enough for internal agency work and for embedding in a client deliverable. It is not legal advice, and if you redistribute the skill inside a product you should read the licence text rather than this summary. On maintenance, the release history shows v3.0.1 on 2026-05-14, preceded the same day by v3.0.0 and v2.2.1, with the last push to the default branch on 2026-07-23. Three releases inside roughly an hour is a burst pattern, so version numbers here do not tell you much about stability between them. The upgrade cost is real but bounded. The skill is Markdown and Python with no compiled artefacts, so pulling a new version is a git operation, but the installer writes into editor-specific paths such as ~/.claude/skills/seo and <project>/.cursor/rules/seo.mdc, and any local edits you made to the rubrics will conflict. Keep your rubric changes in a separate file or a branch. The reference freshness command gives you a way to notice when the bundled data has gone stale rather than discovering it in a report.
Who should clone this, and what to check first
The skill fits a team that already pays for Claude Code, Codex or Antigravity and wants SEO review to happen in the same context as the code change. It fits an agency doing technical audits where the deliverable is a Markdown action plan the client's engineers can act on. It does not fit a solo site owner who wants a dashboard, and it does not fit anyone who needs unattended monitoring. The honest caveat is that the material here describes intent more than outcome. The README promises evidence-backed scoring, but the only automated verification it names is inventory drift and reference freshness, neither of which checks whether a given finding was correct. So the first thing to do after cloning is not to run audit_runner.py on a client site. Run python3 scripts/validate_skill_inventory.py to confirm the 16 sub-skills and 89 scripts are all present, then open scripts/finding_verifier.py and read what it actually deduplicates. If that file does what its name claims, the confidence labels mean something. If it does not, you are reading a well-organized prompt library, which is still useful, just not the same product.
Editorial conclusion
Adopt it if your team already runs Claude Code, Codex CLI or Antigravity and wants SEO findings produced inside the same session as the code, with the evidence scripts on disk rather than a hosted dashboard. Do not adopt it if you need a scheduled crawler that runs without a human in the loop, or if you cannot read Python well enough to tell a script failure from a clean result. Before trusting any report, run python3 scripts/validate_skill_inventory.py and python3 scripts/reference_freshness.py resources/references --max-age-days 90, then open one script under scripts/ and confirm you understand what it writes.
Community notes