recomby-geo: a GEO skills pack plus curated agent and office-CLI lists
GEO 领域 AI 员工开源方案 · Open-source GEO AI-employee solution (MIT). GEO Skills package + curated lists of agents and office CLIs that make up the AI-employee stack.
At a glance
- What is it?
- recomby-geo packages six third-party GEO skills and seven self-authored workflow commands as a Claude Code plugin, with curated lists of agents and office CLIs as architecture notes. The interesting part is the enforced human brief gate; the weak part is that most of the skill code is vendored.
- Who is it for?
- Adopt recomby-geo if you already run Claude Code or another skill-loading agent and you have a GEO engagement where a named business expert will actually fill the brief slots; the /05-production gate is the reason to pick it over a folder of loose prompt files. Do not adopt it if you need a turnkey GEO platform, if you cannot accept that the six GEO skills are vendored from other repositories and carry their own licences, or if your agent cannot load a plugin directory.
- 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 74 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 problem: GEO work does not fit a fully automated tool
Generative engine optimization asks a different question from classic SEO. Instead of ranking a page against a query, you are trying to get cited when a model answers a question. The README argues that large-model search engines penalise machine-written filler, so a citation requires real business insight, and business insight has to come from a person who knows the business. That argument is the project's whole reason for existing. If it holds, then a GEO tool that generates content end to end is producing the exact material the engines are trained to discount.
recomby-geo is aimed at the person running GEO for a client or an internal team: a consultant, a forward-deployed engineer, or a marketing lead who has access to subject-matter experts. The repository describes the target as a virtual job assembled from four parts, with the business expert and the agent as separate contributors and the skills package as the part this project actually maintains. It is not aimed at someone who wants a dashboard that produces a content calendar.
What the repository actually contains, and what it does not
The layout is explicit. Under plugins/recomby-geo/ there is plugin.json, an orchestrator/run.md described as the single source of truth for the workflow, a commands/ directory with seven workflow commands, a skills/ directory, a schemas/ directory with eight JSON Schema files, and a references/ directory. At the repository root sit agents.md and clis.md, plus THIRD_PARTY_LICENSES.md.
The README is direct about the split: agents.md and clis.md are described as architecture explanation pages, not products. They list agents that can load skills (Claude Code, Codex CLI, OpenCode, Cline, Goose, ByteDance's Trae) and office CLIs that let an agent reach business data (Feishu, DingTalk, WeCom, Yuque domestically; Slack, Notion, GitHub, Linear, Google Workspace, Jira internationally). Reading those two files tells you the intended shape of the deployment, but installing them is not the point. The maintained asset is the skills package and the command set.
Of the skills themselves, six are listed with their upstream sources: seo-geo-optimizer from 199-biotechnologies (MIT, described as the main one, with 13 Python scripts), content-writer and keyword-research and meta-tags-optimizer from toprank (MIT), and content-quality-auditor and internal-linking-optimizer from aaron-he-zhu (Apache 2.0). One self-authored skill, geo-review-html, is named in the licence section. That is a packaging project more than an algorithms project, and the README does not pretend otherwise.
The seven-stage workflow and the brief gate that blocks production
The pipeline runs /01-intake, /02-audit, /03-gap, /04-content-brief, then a human step, then /05-production, /06-distribution, publication, and /07-reaudit seven days later. Each stage writes output that must pass JSON Schema validation before the next stage accepts it, which is why schemas/ holds eight files rather than one.
Two mechanisms are worth separating from the marketing around them. The first is the /05-production gate. The README states that /05-production hard-refuses to run when the brief status is not ready-for-production, and that the agent will not fill the expert slots with AI-written content on its own. That is a real design decision: the automation stops at a named state value rather than at a prompt instruction the model could talk itself past. The v0.4.3 release note, titled gate hardening, says advisory rules became enforced gates, which suggests earlier versions treated some of this as guidance rather than a block.
The second is /02-audit. It runs a sub-agent without client context to establish a visibility baseline, described as simulating how a stranger would question an AI engine. The point is to avoid contaminating the baseline with the client's own framing. Whether that produces a useful baseline depends on the audit skill's implementation, and the README does not show sample output.
Installing it and running the first project
The README gives a three-step path inside Claude Code. First, /plugin marketplace add ViryaZheng/recomby-geo, then /plugin install recomby-geo. Then create a project folder with mkdir -p clients/<your-project>/inputs and drop business material (PDFs, URLs, notes) into inputs/. Then start with /01-intake clients/<your-project> and follow the prompts through /02-audit, /03-gap, /04-content-brief and onward. The complete flow diagram lives at plugins/recomby-geo/orchestrator/run.md.
For other agents, the README says to copy plugins/recomby-geo/skills/ manually into any agent that supports skill or plugin loading, and points at agents.md for the list. There is no second packaging format documented, so a non-Claude Code user is copying directories rather than installing a release artefact.
The repository claims zero external dependencies and zero API keys. Treat that as a statement about the package itself: the skills are described as model-matched by their description fields rather than called directly, so the model decides when to invoke them. If your agent or your local model does not do skill matching well, the skills sit unused and the workflow commands produce schema-valid files with nothing behind them.
Local-first as the differentiator, and where that claim is thin
The README positions local-first deployment against SurferSEO, Frase and Clearscope, which it says require uploading client data to a cloud service. Three claims support the contrast: agents like Claude Code and Codex CLI can point at local models through Ollama, vLLM or LM Studio; the office CLIs run in your own environment so business data does not leave it; and the whole stack is open source under MIT or Apache 2.0, so it can be audited and modified.
The distinction is real in shape but incomplete in the material. The repository does not document a specific local-model configuration, a tested Ollama or vLLM setup, or a command that switches an agent to a local endpoint. It states the capability exists in the agent ecosystem. The office-CLI half is likewise a list in clis.md rather than an integration: the README describes those tools as the data source and operating scaffold, and the agent as the body. So local-first is an architectural property of the assembled stack, not a feature you can verify from this repository alone. For a compliance-sensitive engagement that is the difference between a claim and an audit trail, and the material here only supports the former.
Vendored skills and the licence surface you inherit
Six of the seven skills come from other repositories. The README and the licence section both say the vendored skills keep their original licences (MIT for the 199-biotechnologies and toprank skills, Apache 2.0 for the two from aaron-he-zhu), that the self-authored geo-review-html skill is MIT with the repository, and that THIRD_PARTY_LICENSES.md holds the details. The README also credits Princeton KDD 2024, Auriti Labs and awesome-geo as sources the structure and methodology draw on.
Practical consequence: MIT and Apache 2.0 both permit commercial use and modification, but Apache 2.0 carries notice and patent terms that MIT does not, and a redistribution of the package has to carry the notices forward. The repository's own MIT licence does not relicense the vendored files. If you fork the skills package, or ship it inside a client deliverable, read THIRD_PARTY_LICENSES.md per skill rather than relying on the root LICENSE. That is a description of the file structure, not legal advice.
The other cost of vendoring is upgrade drift. When seo-geo-optimizer or content-quality-auditor changes upstream, this repository has to pull the change in, and the README does not describe a sync process. The release history shows three releases in about a month (v0.4.1 adding an interactive client-review HTML and Codex CLI support, v0.4.2 and v0.4.3 both hardening schema and gate behaviour), which suggests active work on the wrapper rather than on the vendored logic.
Where it is the wrong tool, and what to use instead
If you want GEO output without a human in the loop, this is the wrong choice by design. The /05-production refusal is not a bug to work around; it is the product. Teams that need volume content generation should look at the upstream skills directly, or at a hosted GEO platform, and accept the trade-off those tools make.
A more useful comparison is the one the README implies: a folder of loose prompt files and the same six skills copied into a project. That approach has no schema validation between stages, no state value that blocks production, and no orchestrator file defining the order. The difference is not the GEO knowledge, which is largely vendored either way. It is the contract layer: eight JSON Schemas and a command sequence that fails loudly. If you already have a working prompt library and your team reliably fills the expert sections by hand, recomby-geo adds structure you may not need. If hand-filling is exactly what gets skipped under deadline, the enforced gate is the reason to take on the extra layer.
A second case: an agent that cannot load plugins. The README's fallback is manual copying of the skills directory, which loses the command set and therefore the workflow. At that point you have the vendored skills and none of the project's own contribution.
Who should adopt it, and the first thing to verify
Adopt it if you run Claude Code or another skill-loading agent, you have a real GEO engagement with a named expert who will fill brief slots, and you want the stage boundaries enforced rather than suggested. The three commands to run first are the marketplace add, the plugin install, and /01-intake on a single real client folder, because the intake schema is where your actual input format either fits or does not.
Do not adopt it if you need a hosted platform with reporting, if you cannot carry Apache 2.0 notices into your distribution, or if your agent cannot load a plugin directory and you are unwilling to lose the commands. The project labels itself alpha, and the release cadence shows gate and schema behaviour still changing between v0.4.1 and v0.4.3, so pin a version rather than tracking main. Verify two things before you commit: that THIRD_PARTY_LICENSES.md covers every skill you plan to ship, and that /05-production actually refuses on a brief you deliberately leave incomplete. That second check takes one run and tells you whether the gate is enforced in the version you installed.
Editorial conclusion
Adopt recomby-geo if you already run Claude Code or another skill-loading agent and you have a GEO engagement where a named business expert will actually fill the brief slots; the /05-production gate is the reason to pick it over a folder of loose prompt files. Do not adopt it if you need a turnkey GEO platform, if you cannot accept that the six GEO skills are vendored from other repositories and carry their own licences, or if your agent cannot load a plugin directory. Before committing, read THIRD_PARTY_LICENSES.md against the skills you intend to ship, and run /01-intake on one real client folder to see whether the schema validation fits your inputs.
Community notes