# viryazheng/recomby-geo counts six skills in one place and seven in another

> This is an alpha bundle of GEO skills, seven workflow slash commands and eight JSON schemas, wrapped for coding agents such as Claude Code and Codex. Most of its content is vendored from three upstream projects under two different licenses, and the human stays in the loop by design: the production stage refuses to run until a person fills the brief.

**ViryaZheng/recomby-geo** — 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.

- Repository: https://github.com/ViryaZheng/recomby-geo
- Stars: 458 · Forks: 39
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/viryazheng-recomby-geo

## Six skills in the table, seven in the layout, eight skills claimed overall

The skill inventory does not reconcile. The core table lists six entries under plugins/recomby-geo/skills/:

- seo-geo-optimizer, taken from 199-biotechnologies and described as the main one, with 13 Python scripts
- content-writer, from toprank
- content-quality-auditor, from aaron-he-zhu, for E-E-A-T and citation auditing
- internal-linking-optimizer, also from aaron-he-zhu
- keyword-research, from toprank
- meta-tags-optimizer, from toprank

The project layout section in the same file annotates that directory as holding seven vendor and self-developed skills. The licensing section goes further and refers to seven vendor skills keeping their original licenses, plus a self-developed skill named geo-review-html released under the repository's MIT terms. That last name appears nowhere in the table, so a reader counting the six rows is looking at a smaller set than the one the repository describes.

The skills are selected by the model rather than invoked directly, which is stated as a feature: the description is what the agent matches against. That design choice makes an inventory error easy to miss, since nothing fails loudly when a skill is absent from the list you expected.

Alongside them sit seven self-developed workflow commands from /01-intake to /07-reaudit and eight JSON schemas, and the document names Princeton GEO methodology among the references, with further references held in a directory.

## The production stage refuses to run, and that refusal is the feature

The collaboration model is enforced in code rather than described as a principle. The workflow runs in seven stages, and the emphasis falls on the middle of it, where the agent prepares a frame and a business expert fills in the insight slots. The production stage, /05-production, hard rejects input when the brief status is not ready-for-production, on the stated grounds that the expert slots are not finished and the agent will not fill them with generated content instead.

That is the one design decision here that is genuinely different from a typical automation script. Most agent workflows treat a missing field as something to improvise around; this one treats it as a stop condition, which means a run can fail for a reason that has nothing to do with the code.

The release history shows the constraint hardening rather than being introduced as a slogan. The newest tag, v0.4.3, is described as gate hardening where advisory rules become enforced gates, and the tag before it, v0.4.2, as schema gate hardening plus a brief heading fix. So the gate you meet today was advisory at some point, and a reader comparing against an older checkout may find a version that warns where the current one refuses.

Underneath both, every stage output is validated against a JSON Schema before it enters the next stage. Eight schemas are listed for seven commands, which leaves room for shared contracts, and the schema gate hardening in v0.4.2 is what that validation is called elsewhere in the history.

## The audit stage deliberately runs without your context

One stage is designed to be ignorant on purpose. The audit stage, /02-audit, runs a sub-agent that has no customer context, and the reason given is that it establishes a visibility baseline by simulating the real questions a stranger would ask an AI engine.

That is a different objective from the rest of the workflow, and it is the most reusable idea in the repository. A baseline measured with the client's own vocabulary, their products and their internal terminology is a baseline that already knows the answer, so it tends to report a visibility that a first time reader would not find. Removing the context is the only way to get a number that reflects what an outside search assistant would actually surface.

The distinction matters for how you read the output. A low baseline is not evidence about your content quality, it is evidence about discoverability under unfamiliar phrasing. The gap between the baseline and the brief stage is the thing the workflow is built to close, and the brief is where the expert's knowledge is supposed to enter.

The remaining stages follow the publishing shape rather than the analysis shape. The flow runs /01-intake, /02-audit, /03-gap, /04-content-brief, then the expert step, then /05-production and /06-distribution, a publish, and a re-audit seven days later at /07-reaudit. The complete run graph is declared the single source of truth in a file under the orchestrator directory.

The seven day gap at the end is the part that makes the loop closed rather than open ended. A re-audit scheduled a week after publication means the workflow assumes its own output needs to be measured against the same kind of baseline it started from, which is the only part of the seven stages that can tell you whether the other six worked.

## Seven MIT and Apache skills are vendored from three upstream projects

Most of what ships here was written elsewhere. The table attributes each skill to an upstream repository and records that project's license alongside it: the main optimizer comes from 199-biotechnologies under MIT, content-writer, keyword-research and meta-tags-optimizer come from a project called toprank under MIT, and content-quality-auditor and internal-linking-optimizer come from aaron-he-zhu under Apache 2.0.

So the repository itself is MIT while part of its contents are Apache 2.0, and the file is direct about the arrangement: the vendor skills keep their original licenses, the self-developed skill goes out under the repository's MIT terms, and the detail is recorded in a dedicated third party licenses file at the root. The stated advantage is that every vendored skill is permissively licensed and therefore auditable and customisable, and the framing elsewhere is that the work here is assembly, refinement and repackaging for the agent scenario, with some structures and methods referencing open work including a KDD 2024 paper and other community collections.

That claim is worth checking against the file rather than taking on trust, because the difference between vendored and original is exactly what determines what you may modify. The names to look for are the two Apache 2.0 entries and the single self-developed skill, since those are the three whose terms differ from the repository default.

## Install is two slash commands in Claude Code, or a manual copy

The quick start is written for one agent:

```bash
# 1. 在 Claude Code 中安装本插件（GEO Skills + 7 阶段工作流命令）
/plugin marketplace add ViryaZheng/recomby-geo
/plugin install recomby-geo

# 2. 准备你的项目目录
mkdir -p clients/<your-project>/inputs
# 把业务资料（PDF / URL / notes）放进 inputs/

# 3. 启动协作工作流
/01-intake clients/<your-project>
# 按提示依次：/02-audit → /03-gap → /04-content-brief → ...
```

For anything else the instruction is to copy plugins/recomby-geo/skills/ manually into an agent that supports skill and plugin loading. So the plugin route gives you the commands and the schemas, while the manual route gives you only the skills, and a user on a different agent loses the seven stage workflow along with the orchestrator.

Two constraints are declared at the top and are worth respecting. The project is labelled alpha, and it states zero external dependencies and zero API keys. The second is a real architectural commitment given what it is doing, since the visibility audit and the re-audit both depend on reaching AI engines somehow.

The inputs directory is where the human side of the system enters. Business material in the form of PDFs, URLs or notes goes into inputs/ under the client project, and that is what the intake stage reads before the audit stage deliberately ignores it.

## Two of the three deliverable groups are explicitly not the product

The repository is unusually direct about what it is not. The agents and office command line layers are described as architecture explanation pages rather than components of the product, with the skills named as the main battleground. Two files carry the curated lists: agents.md collects agent command lines that can load skills, naming Claude Code, Codex CLI, OpenCode, Cline, Goose and Trae among them, and clis.md collects office software command lines that give an agent access to business data, from Feishu, DingTalk, WeCom and Yuque on the domestic side to Slack, Notion, GitHub, Linear, Google Workspace and Jira internationally.

Both are described as showing the full picture of the solution, with the agent as the body and the office command line as the limbs. Neither is a curated installation set with versions or configuration, so a reader who wants a working office integration still has to do the assembly.

The framing explains why. The project positions itself as a virtual role assembled from four parts that cannot be reduced to fewer: the business expert, the agent, the office command line layer, and the skills. Its main competitor comparison is against hosted GEO tools named in the file, which require customer data to be uploaded to their cloud, while this one is described as local first, with agents able to attach a local model through Ollama, vLLM or LM Studio, and office data staying in your own environment.

The stated reason GEO suits this pattern is that it cannot be fully automated. Search engines are said to actively penalise filler written by models, so genuine business insight is required before anything gets cited, and that insight can only come from a person. The file treats this as the reason an AI employee here can only be collaborative, and as the reason the argument lands with decision makers who would resist replacement.

## The layout diagram omits half the files in the tree

The project layout section draws the repository as a directory tree, and that tree is a subset of what is actually there. The diagram lists README.md, README.en.md, agents.md, clis.md, plugins/recomby-geo/ with its plugin.json, orchestrator, commands, skills, schemas and references directories, plus THIRD_PARTY_LICENSES.md, LICENSE and .gitignore.

The repository root also contains INSTALL.md, which is the target of the installation and usage link at the top of the file, along with CHANGELOG.md, CONTRIBUTING.md and two agent configuration directories, .agents/ and .claude-plugin/. None of those appear in the diagram.

The Chinese file is also explicit about its own role as documentation rather than spec. It says the technical details, the schema contracts and the notes for an agent taking the project over are in README.en.md, and that the complete seven stage run graph with its contracts is in the orchestrator file, which is named as the single source of truth. So the file this account is drawn from is the orientation document, and the contract level detail lives in two other places.

Two smaller signals round it out. The project is maintained by Recomby.ai, the single listed contributor is @hanjinchi7-droid, and the releases cluster tightly: v0.4.1 and v0.4.2 are stamped one second apart on 2026-06-09, with v0.4.3 following on 2026-07-04, which is also the date of the last push to the branch.

## Conclusion

recomby-geo is worth reading as a worked example of an agent workflow with a deliberate human gate rather than as a finished product. Its strongest idea is the hard refusal in production, since refusing to substitute generated content for expert input is the thing most agent pipelines will not do. Two things to check before you rely on it: which of the skills you actually get, since the count is inconsistent between sections and the file names differ, and which license applies to each, because the repository is MIT while two vendored skills are Apache 2.0. Expect to read README.en.md for the schema contracts, since the Chinese file this text is drawn from points there for the technical detail.

## FAQ

### How many skills does viryazheng/recomby-geo contain?

The core table lists six vendored skills, while the layout and licensing sections refer to seven vendor skills plus a self-developed skill named geo-review-html that does not appear in the table.

### How do I install the viryazheng/recomby-geo plugin?

In Claude Code, add the marketplace and install the plugin with /plugin marketplace add ViryaZheng/recomby-geo followed by /plugin install recomby-geo. On other agents that support skills and plugins, copy plugins/recomby-geo/skills/ manually.

### What happens if the expert has not filled in the brief?

The /05-production stage hard rejects input when the brief status is not ready-for-production, and the agent will not substitute AI generated content for the unfinished expert slots.

### Why does the audit stage run without customer context?

The /02-audit stage uses a sub-agent with no customer context so the visibility baseline reflects the real questions a stranger would ask an AI engine, rather than questions phrased in the client's own vocabulary.

### Which licenses apply to the skills in viryazheng/recomby-geo?

The repository is MIT, but vendored skills keep their upstream licenses, which are MIT for the 199-biotechnologies and toprank skills and Apache 2.0 for the two from aaron-he-zhu. The mapping is recorded in THIRD_PARTY_LICENSES.md.

### Does viryazheng/recomby-geo need an API key or send data to a cloud service?

It is labelled alpha and states zero external dependencies and zero API keys, and describes itself as local first, with agents able to use a local model through Ollama, vLLM or LM Studio and office data staying in your own environment.

## Sources

- [Issues](https://github.com/ViryaZheng/recomby-geo/issues)
- [License: MIT](https://github.com/ViryaZheng/recomby-geo/blob/main/LICENSE)
- [README](https://github.com/ViryaZheng/recomby-geo/blob/main/README.md)
- [Releases](https://github.com/ViryaZheng/recomby-geo/releases)
- [ViryaZheng/recomby-geo on GitHub](https://github.com/ViryaZheng/recomby-geo)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/viryazheng-recomby-geo