fire-your-seo-agency: a docs-only repository that validates itself

Five lanes, and the fifth one is the reason to read it

The organising idea is that search optimisation is not one activity, and a checklist that does not separate them will quietly optimise the wrong thing. The skill treats them as five lanes with a question attached to each. SEO asks whether crawlers can read and index the content at all, targeting the Google and Bing crawlers. AEO, answer engine optimisation, asks whether the AI answer box above the results cites you, targeting Google AI Overviews and Bing Copilot. GEO, generative engine optimisation, asks whether you are the primary source when a model browses, naming ChatGPT, Perplexity and Claude. LLMO asks whether the model's own knowledge contains your brand and whether that knowledge is correct. And NEO, Naver engine optimisation, asks whether Naver cites you. The claim for NEO being the differentiator is that global answer-engine guides ignore Naver entirely, which is a fair observation if your traffic is Korean.

The audit reads your site without JavaScript and returns a scorecard

The first thing the agent does is read the site the way a crawler does, with JavaScript off, and score all five lanes before it changes anything. The readme shows the shape of the result, and the example rows are worth reading as a template rather than as findings about any particular site. The technical lane comes back as a warning because the body is server-rendered but 214 detail pages are missing from the sitemap. The answer lane comes back as a failure because there are no direct-answer first paragraphs and the count of FAQ structured-data blocks is zero. The generative lane fails for a missing machine-readable instructions file and because the crawler policy for two named bots is left undecided in the robots file. The model-knowledge lane warns that the brand name is spelled three different ways across surfaces. The Naver lane fails because the site is not registered in Search Advisor. After the scorecard it proposes priorities, implements them and schedules a re-measurement, so the loop closes on measurement rather than on edits.

Output is measured as posts that get seen, not posts published

The content engine exists because most of what a retainer buys is a monthly post count, which is the one number that cannot be defended. The pipeline replaces it with four parts: a question backlog pulled from your own search data, a frontmatter content model that generates the structured data, a publish gate every post must pass, and a refresh and merge policy so posts do not rot. The measurement claim is that output counts posts that get seen and cited rather than posts published, which is the correct instinct and the harder measurement. The supporting numbers in the readme come from one site, a solo-built Korean stock research service, and are the author's own: 1.54 million search impressions in thirty days, a month-on-month increase of 85,578 percent, 7.4 thousand clicks, pages cited paragraph by paragraph by Naver's AI Briefing, and no advertising spend. Read honestly, those two figures together imply a click-through rate under one percent, which is normal for impressions at that volume and is why impressions are a weak headline.

The Korean references are canonical and the English ones are mirrors

This is the detail that decides how you should use the repository, and it is stated plainly rather than buried. The documents under the references directory in Korean are the canonical ones, because those are what the agent reads, and an English subdirectory mirrors them for human readers. So an English reader is reading a translation of the material that actually executes. The risk is drift, and the project handles it with a parity check in continuous integration that compares heading counts, table rows, checkboxes and section numbering between the two languages. Comparing structure rather than prose is the right granularity for an automated check, since it catches a deleted section without pretending to compare prose. What it will not catch is a Korean section that was rewritten to mean something slightly different while keeping the same headings, so treat the English files as a reading aid rather than as the source you can safely edit.

Ten checks run on every push, and the frontmatter contract has numbers

A documentation repository that rots is the failure mode this project is defending against, and the defence is a workflow file that runs on every push and pull request:

python3 tools/validate.py --strict          # 10 checks, standard library only
python3 -m unittest discover -s tests -t .  # unit tests for every check
python3 -m pip install pillow
python3 tools/optimize_assets.py --check    # flags recompressible assets

The checks are the interesting part, because each one targets something that fails silently in a repository with no compiled code. The skill frontmatter contract is enforced with hard numbers, requiring a kebab-case name, a name of at most 64 characters, and a single-line description of at most 1,024 characters, which are host constraints rather than style preferences. The plugin and marketplace manifests must agree on both version and name. The changelog must match the manifest version, so a release cannot be cut without updating it. Relative links and anchors are checked. Reference parity between the two languages is checked by structure. The asset budget and preview dimensions are checked, the MIT licence metadata is checked, and every text file goes through a secret scan. The validator uses only the standard library, and the asset optimiser needs one extra package for images.

Install as a plugin, or clone it into one of two skill directories

Two installation routes, with a scope decision attached to each. The recommended one is the plugin route, two commands that add a marketplace and install from it, which is described as the path with easy updates. The alternative is a clone into a skills directory, and there are two of them:

# As a project skill (this project only)
git clone https://github.com/leopard627/fire-your-seo-agency.git .claude/skills/fire-your-seo-agency

# Or as a personal skill (every project)
git clone https://github.com/leopard627/fire-your-seo-agency.git ~/.claude/skills/fire-your-seo-agency

That distinction matters more than it first appears. A project skill is available only in that repository, while a personal skill is available in every project you open, which is what you want if you are auditing more than one site. Once installed, the skill is invoked by name in the conversation with a target, and the audit command is the entry point. Because this is a skill rather than a program, there is nothing to compile and no runtime to manage; what you are installing is a procedure document plus reference material, which is also why the validator focuses on document structure rather than on code.

The refusal list is the more durable half of the readme

Three things the skill will not do, and they are the part worth arguing with your vendor about. It will not buy backlinks, run engagement pods or produce content spam, on the grounds that it does not fight the search engine. It will not promise rankings, because there are no claims without measurement. And it will not do keyword stuffing, hidden text or cloaking, on the grounds that those get a domain killed. The stated philosophy compresses to a claim that AI does not cite good writing but accurate data, with the practical instruction to become the primary source for a number and let the citations follow. That is a stronger position than most of the material in this category, and it is testable: if you become the source for a figure, a citation is something someone else can verify. The framing of the repository as a replacement for an agency is marketing, but the refusal list is a constraint that a careful reader can hold the project to.

The tags carry the repository name twice

Small packaging details that matter if you script anything against this repository. The release tags are prefixed with the repository name and a separator, so the tags read as the project name followed by a doubled dash and the version, and three releases landed inside a month: one adding repository checks and a cross-posting Markdown check, one adding the content engine with the sub-blog, question backlog, publish gate and refresh policy, and an earlier one adding Bing, AI crawler policy, experience signals, English documentation and the plugin install route. The repository declares MIT, and the tree contains the licence file alongside a Korean readme, the English one, the skill file, the plugin directory, references, tests and tools. The project homepage in the metadata points at the author's own commercial site rather than at a documentation site, which is worth knowing when you weigh the evidence, since the case study and the maintainer are the same party. The closing licence line in the collected copy is cut off mid-sentence, so the wording of the licence plea is not available here.

Editorial conclusion

fire-your-seo-agency is worth reading if you ship content for a Korean audience or you want a checklist you can hand to an agent, because the five-lane split and the refusal list are the reusable parts and the validator makes the documentation trustworthy enough to automate against. Two cautions. The evidence offered is one site, the author's own, and its headline figure is impressions rather than citations, so treat the playbook as plausible rather than proven. And the documents your agent actually executes are the Korean ones, with the English files kept in parity by a CI check rather than being the source, which matters if you plan to read and adapt the material in English.

Frequently asked questions

Official sources

1. leopard627/fire-your-seo-agency on GitHub
2. License: MIT
3. Project website
4. README
5. Releases