gtm-engineer-skills: twelve Claude Code skills wired by file handoff
Claude Code skill for improving website AEO (AI Engine Optimization) and GEO (Generative Engine Optimization) scores — 16 foundational checks, 6 intelligence dimensions, framework-specific fixes
At a glance
- What is it?
- gtm-engineer-skills is a set of prompt folders for AI answer engines, with no runtime, no dependencies and no installer. It works only if your agent writes the intermediate files each stage expects.
- Who is it for?
- Adopt gtm-engineer-skills if you already run Claude Code or Codex daily and want a repeatable order of operations for answer-engine visibility, not for any measurement guarantee. Skip it if you need a crawl you can trust as a regression test, since the repository ships no dependency, no scoring library and no CI hook, and the only executable check covers one skill of twelve.
- 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 12 days ago.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Twelve prompt folders with nothing to install
The repository description for onvoyage-ai/gtm-engineer-skills advertises 16 foundational checks, 6 intelligence dimensions and framework-specific fixes. None of that ships as code you call. package.json is marked `private": true`, declares `"type": "module"`, and carries three scripts that only invoke Node's built-in test runner. There is no dependency block, no build step and no binary.
What you clone is a directory of skill folders, each holding a `SKILL.md` file and, when useful, a README, examples, scripts or schemas. The top level also carries `AGENT.md`, `CONTRIBUTING.md`, `TESTING.md`, an `assets/` directory and an `evals/` directory. Twelve skill folders sit alongside them: `research-brand`, `research-keywords`, `reddit-opportunity-research`, `geo-content-research`, `geo-content-planning`, `write-seo-geo-content`, `create-geo-charts`, `audit-content`, `build-resource-pages`, `audit-website-aeo`, `improve-aeo-geo` and `build-backlinks`.
Twelve folders means twelve `SKILL.md` instruction sets, and 16 checks claimed, 6 dimensions named. That makes the whole thing a set of writing instructions aimed at AI answer engines such as ChatGPT, Claude, Perplexity and Google AI Overviews. The output of one skill is a file on disk, and that file is the input to the next. It is closer to a documented workflow that an agent reads than to software you integrate.
The pipeline is wired through files, not shared state
Every stage in the workflow has a named output, and the names are the contract. `research-brand` takes a URL and produces `brand_dna.md`. `research-keywords` produces `keyword_research.md`. `reddit-opportunity-research` produces `reddit_opportunities.md`, `geo-content-research` produces `geo_prompt_targets.md`, and `geo-content-planning` turns those into `content_architecture.md`.
From there the fan-out widens. `build-backlinks` consumes the Reddit and prompt research and emits `backlink_plan.md`. `write-seo-geo-content` drafts markdown articles with frontmatter from the architecture. `create-geo-charts` emits SVG, HTML, CSV and JSON-LD rather than pixels alone. `audit-content` verifies URLs, statistics, claims and source attribution, and its report is what `build-resource-pages` is supposed to draw on before it builds frontend pages inside a client codebase.
The audit pair runs on a different track. `audit-website-aeo` crawls a live site and writes `aeo_audit_report.md`, and `improve-aeo-geo` takes that report and applies code-level changes to the website. Nothing in the flow passes state between skills except files an operator can open, edit or delete. If a stage writes the wrong filename, the next stage has nothing to read and the agent either guesses or stops.
Symlinks, not a plugin manager, decide what loads
Installation is two commands and then a choice per skill. You clone, change directory, and link the folders you want into the skill directory your agent already reads. For Codex that is `~/.codex/skills`; for Claude Code it is `~/.claude/skills`. Both paths are created with `mkdir -p` before the links.
git clone https://github.com/onvoyage-ai/gtm-engineer-skills.git
cd gtm-engineer-skillsmkdir -p ~/.claude/skills
ln -s "$PWD/research-brand" ~/.claude/skills/research-brand
ln -s "$PWD/research-keywords" ~/.claude/skills/research-keywords
ln -s "$PWD/geo-content-planning" ~/.claude/skills/geo-content-planning
ln -s "$PWD/audit-website-aeo" ~/.claude/skills/audit-website-aeoNote what the block leaves out. Only four of the twelve folders are linked, and the README never says to link the other eight. Symlinks are also the whole update path: there is no version pin, so pulling new commits changes the instructions your agent will read on the next run. The repository is MIT licensed and its last push was on 2026-06-07.
Prompts are meant to be run one at a time, which keeps each stage's context small:
Use audit-website-aeo on https://example.com with a 20 page crawl and produce a prioritized AEO/GEO audit.A longer request is also shown, chaining research, architecture, two resource pages and a claim audit in one prompt. That works only when the agent keeps writing the intermediate files between stages.
Sixteen checks advertised, twelve skills shipped
The one number worth arguing with sits in the project description. It claims 16 foundational checks and 6 intelligence dimensions, while the skills table lists twelve rows and the repository root contains twelve skill directories. No file in the tree names sixteen checks or six dimensions, so the counts cannot be traced to anything a reader can open.
The audit side is the only place where a count would matter, since `audit-website-aeo` is described as scoring AI discoverability with deterministic and content checks. Sixteen checks would imply a fixed rubric. What is actually documented is an output file, `aeo_audit_report.md`, and two worked examples: one scored audit of anthropic.com and before/after plans for a Next.js blog and a WordPress business site. Those examples show the shape of the report. They do not enumerate the rubric, and the README does not state the scoring scale or the threshold that separates a passing score from a failing one.
So the check count is a claim about depth that a reader cannot audit. If your decision depends on how many signals are inspected, read the example audit and count them yourself before believing the description.
The eval scripts cover one skill out of twelve
package.json exposes three test entries and all three run the same runner over files in `evals/`. All 3 share one runner. The broad entry is `test:evals`, which globs every test file. The other 2 are narrower: `test:evals:contracts` points at `evals/tests/contracts.test.mjs` and `test:evals:audit` points at `evals/tests/audit-website-aeo.test.mjs`.
Only one skill has a dedicated suite by name. The other eleven are covered, if at all, by whatever the glob picks up. Since there are no dependencies declared, those tests cannot be exercising an HTML parser, a crawler library or a JSON-LD validator pulled from a registry; anything they check is either regex work or a fixture comparison.
node --test evals/tests/*.test.mjsThe practical consequence for an adopting team: you can run the evals in about a second, which tells you the contracts still hold, but there is no regression signal on the behaviour that actually changes your traffic. The skills are prompts, and a prompt can pass every contract test while producing worse prose. Nothing in the repository runs on a pull request, and `TESTING.md` sits at the root as a document to read rather than a hook that fires.
Claims verification is the strongest idea and the weakest guarantee
`audit-content` is the odd one out among the writing skills. Its job is not to produce marketing copy but to verify URLs, statistics, claims, source attribution and internal consistency, and its output is a report rather than a draft. Between the two, `audit-website-aeo` and `improve-aeo-geo` are the pair with a visible before and after, and `audit-website-aeo/examples/anthropic-com-audit.md` is the only sample of a full scored report in the tree. For an answer-engine workflow that is the right place to spend scrutiny, because being cited with a wrong number costs more than not being cited.
What it does not promise is a source of truth. The README gives no list of reference databases, no confidence model and no statement about how a URL is fetched. An agent running the skill has whatever web access its host environment provides, and the distinction between a checked link and a link the agent recalls matters when the whole premise is that AI systems hallucinate.
This is also where the project overlaps with doing the work by hand. Writing JSON-LD yourself, keeping a `content_architecture.md` in your repository and running your own crawler against a staging URL costs more setup and gives you something that fails loudly. The skill route is faster to start and leaves more of the verification judgement inside the model.
What an AEO score can and cannot tell you
The premise of the toolkit is that ChatGPT, Claude, Perplexity and Google AI Overviews choose their answers by different signals than ranked blue links do. Pages need direct answers, clear structure, sources and quotable passages; charts need text layers, tables and structured data instead of pixels alone. Those are reasonable targets, and the repository's topic tags include aeo, geo, seo, structured-data and llms-txt.
The measurement side is where the toolkit has no teeth. AEO scores are computed by one agent reading one crawl of a live site on one day. Nothing here validates against a named third-party scorer, and no retrieval test is performed, meaning nothing confirms that a rewrite changed what an answer engine actually returns for a prompt. `geo-content-research` produces prompt targets; whether those prompts now resolve to your page is outside what any of the twelve skills checks.
The alternative approach is to treat the generated files as drafts and close the loop yourself: keep a fixed prompt set, run it against your domain on a schedule, and record which answers name you. That is more work and it produces a number you can defend. AEO and GEO scores produced inside an agent session are a prioritisation aid for a rewrite queue, not a metric you can put in front of a board.
Editorial conclusion
Adopt gtm-engineer-skills if you already run Claude Code or Codex daily and want a repeatable order of operations for answer-engine visibility, not for any measurement guarantee. Skip it if you need a crawl you can trust as a regression test, since the repository ships no dependency, no scoring library and no CI hook, and the only executable check covers one skill of twelve. Before committing a week to it, run audit-website-aeo against a page you already know the numbers for and read aeo_audit_report.md line by line. That is the single file that decides whether the rest is useful or just plausible prose.
Frequently asked questions
How do I install gtm-engineer-skills into Claude Code?
Clone the repository, then create `~/.claude/skills` with `mkdir -p` and symlink the individual skill folders into it. Only the folders you link become available to the agent; the README shows links for `research-brand`, `research-keywords`, `geo-content-planning` and `audit-website-aeo`.
Does gtm-engineer-skills need npm install or any dependencies?
No. package.json has no dependency block and is marked `private": true`. Its three scripts only invoke `node --test` over files in `evals/`, so the repository has nothing to install.
What file does audit-website-aeo produce?
It writes `aeo_audit_report.md`, a scored AEO and GEO audit built from a crawl of a live site. The repository also ships a worked example at `audit-website-aeo/examples/anthropic-com-audit.md`.
How do the skills pass work between stages?
Through files on disk. `research-brand` writes `brand_dna.md`, `research-keywords` writes `keyword_research.md`, and `geo-content-planning` turns those into `content_architecture.md`, which later stages read. Nothing is shared except those artifacts, so a missing or misnamed file breaks the chain.
Can I check my own skill changes before pushing them?
You can run the evals, but coverage is uneven. Only `audit-website-aeo` has a dedicated test file; the contract suite lives at `evals/tests/contracts.test.mjs` and the rest ride on the glob in `test:evals`. Nothing runs automatically on a pull request.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/onvoyage-ai-gtm-engineer-skills)Was this useful?