LaVioLab Atlas

View saved version →

---
name: content-plan
description: Turn a project description and an optional Search Console export into query clusters, one page per cluster, and a writing queue ordered by money. Use when the user says "what should I write about", "nobody searches my product name", "make me a content plan", "составь контент-план", or hands over a query export and asks what to do with it.
---

# content-plan

Implements the method on <https://atlas.smolevich.com/content/keyword-clusters/>. Read that page if you
need the reasoning. This file is the procedure.

The working unit is a **cluster**: the phrasings one page can satisfy without splitting its answer.
Not a keyword, not a topic. A page per keyword produces thin pages that compete with each other.

## 1. Collect the input

Ask for these and wait:

1. **What the project does**, in the author's own words, and what a person can do inside it.
2. **The language the audience searches in.** Not the interface language. It decides which results
   pages you check in step 4 and which heading set the drafts use in step 7.
3. **A Search Console export, if there is one** — Performance report, Export, the `Queries` table, as
   CSV or as the downloaded ZIP. Optional. Say plainly that without it steps 2 and 3 below run on
   guesses, and the plan is weaker.

If an export is uploaded, read its header and the row count, and name the columns you are using before
going on. A Search Console UI export stops at 1,000 rows; if the file has exactly 1,000, say the tail is
cut off.

**Sort by impressions, not by clicks.** A query with impressions and no clicks is demand you already
touch and lose — the cheapest cluster in the file.

## 2. Harvest phrasings, never invent them

Sources, in order of trust: support messages, reviews, forum and community threads, search
autocomplete, the export.

Write down the exact words people used, clumsy ones included. **The author's own vocabulary is the
least reliable source in the room** — the internal name for a feature is usually not what anyone types.

If the author gives you a phrase they made up, keep it out of the plan and say why.

## 3. Find the capability with no queries at all

Compare the harvested list against what people actually do inside the product.

A heavily used feature with zero queries in the export is a hole in the map, not proof that demand is
absent. It usually means no page names it, so no page can be shown for it. Flag every such capability
as a candidate cluster and mark it clearly as unvalidated.

## 4. Split by intent, then by topic — and test against the results page

**Intent first.** Transactional, comparison, informational. Same topic and different intent means
different pages: "X pricing" and "what is X" cannot share a page without one of them losing.

Then test each candidate grouping. Search two queries from the same candidate cluster and compare the
top URLs:

- Mostly the same URLs → one cluster.
- Different page types — a tool, a listicle, a product page → different clusters.

Record what page type already ranks. An essay does not take a slot held by comparisons. The results
page is search telling you what it thinks the query wants.

If you cannot run the searches, say so and mark the grouping as untested. Do not present a guess as a
validated cluster.

## 5. Order the queue by money, not by volume

Transactional first, then comparison, then informational.

A small query that ends in a signup beats a large one that ends in a bounce. The author will run out of
energy long before they run out of clusters, so the order decides what actually gets written.

Two overrides move a row up, and both need to be written into the reason column:

- **Impressions with no clicks on a page that already exists.** That is a title and snippet rewrite,
  not a new page. Cheapest thing in the queue.
- **A cluster with two pages already chasing it.** That is a merge and a redirect from the loser, not a
  new page. It is unpaid debt and it blocks the pages arou

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: report
description: The weekly slice — six numbers from Search Console exports and your own product data, the delta against the previous period, three conclusions and one action. Use when the user says "weekly report", "what moved this week", "недельный отчёт", "сними цифры за неделю", or hands over a Search Console Performance export and asks what changed.
---

# report

Collects the six numbers defined on <https://atlas.smolevich.com/analytics/what-to-measure/>, compares
them with the previous period, and ends with three conclusions and one action.

**This skill works only from files.** The author downloads the exports and uploads them here. It has
no access to their Google account and never asks for one.

## Prerequisites — check all of these first, and stop on the first one missing

**Never ask for a password, an API key or an access token, and do not use one if the author pastes it.**
Tell them to remove it and to hand over the export instead.

Say exactly which input is missing and how to get it. **Do not continue with a partial report** unless
the author says to go ahead with what is there; then label it partial.

1. **The domain and the Search Console property** it belongs to.
2. **A Performance export with a comparison.** In Search Console: Performance → Search results → Date →
   Compare → the current window against the previous one → Export → Download CSV. That gives a ZIP of
   tables; ask for the unpacked CSV files. You need `Queries.csv` and `Dates.csv`; `Filters.csv`
   confirms the property and the date range.
3. **The submitted-URL count and the indexed count.** Indexing → Pages, switch the filter from
   "All known pages" to "All submitted pages", then either export it or read the two totals, indexed
   and not indexed, off the screen.
4. **The product's own export for signups, activation and repeat use** — a CSV from their database or a
   GA4 exploration. Ask which. Search Console cannot answer metrics 4 to 6.
5. **The name of the single action that counts as activation.** If the author cannot name one action,
   the metric does not exist yet. Say that, and report metrics 1 to 4 only.

Missing inputs are the expected outcome the first time. A report that quietly comes back empty is worse
than one that refuses to run.

## The period

Ask for the domain and the period. Default to a rolling 28-day window ending on the same weekday as the
last snapshot — that removes the weekday effect and makes the series comparable.

Compute the previous period as the 28 days immediately before it. Every number gets a delta.

Search Console data lags behind real time and the most recent days are incomplete. If the window ends
today, say that the tail is provisional.

## Read the numbers from the exports

Before any arithmetic, read `Filters` and say which property and which two date ranges the export
covers. If they do not match the period above, stop and say so.

**Metrics 1 and 2** — from `Dates`: sum clicks and impressions over each window. Average position is
the impressions-weighted mean of the daily position; say that it is computed, not read off the screen.
The distinct query count is the number of rows in `Queries` with impressions in the window. The UI
export stops at 1,000 rows: if the table has 1,000, report the count as "1,000 or more".

**Metric 3** — indexed submitted URLs divided by all submitted URLs, from step 3 of the prerequisites.
If the export has the daily chart, take the value at the end of each window for the delta.

**Metrics 4 to 6** — from the product export. Prefer the product's own database to GA4 where both
exist: it knows which accounts are the author's; GA4 does not.

Show the formula next to each number, so the author can redo it by hand.

## The six numbers

Report each one with its delta against the previous period, and never one without the other.

| # | Number | Source | What it answers |
|---|---|---|---|
| 1 | Impressions, plus the count of distinct queries | Performance export

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: start
description: Route a live pet project through the atlas — take the reports of the existing SEO and GEO audits, merge them into one prioritised list, link the page that explains each item, and name three things to do this week. Use when the user says "nobody finds my project", "where do I start with SEO", "прогони проект по атласу", or pastes an SEO or AI-search audit of their site and asks what to fix first.
---

# start

**This skill runs no checks of its own.** It orders the output of two audits that already exist,
`seo-audit` and `geo-audit`, against the atlas route. Every finding below comes from one of their
reports. If you find yourself fetching `robots.txt` by hand, you have left this skill — stop and ask
for the report instead.

## 1. Ask two questions

Ask both before running anything, and wait for the answers:

1. **The URL of the live site.** Not a staging host, not localhost. The audits read what search reads.
2. **The language the audience searches in.** It decides which results pages matter and what language
   the recommended pages are written in. It is not the language of the interface.

If the project has no public URL — it lives only in Telegram, in a store, or in an app — say so and go
straight to [search inside the platform](https://atlas.smolevich.com/distribution/in-platform-visibility/).
The audits below need a page to fetch.

## 2. Get the two audit reports

`seo-audit` and `geo-audit` are open-source skills maintained by other people. They run in a coding
agent on the user's computer, not here. Ask the user to paste or upload the full output of both, run
on the URL from step 1. If either audit is available as a skill in this environment, run it on that
URL instead of asking.

If a report is missing, **say so and stop**. Do not substitute your own checks — a hand-rolled audit is
a worse audit that looks like a real one. Do not try to install anything. Give the user the install
lines to run in their own coding agent, and say who maintains each package:

```bash
npx skills add -g coreyhaines31/marketingskills
npx skills add -g zubair-trabzada/geo-seo-claude
```

`seo-audit` comes from `coreyhaines31/marketingskills`, `geo-audit` from `zubair-trabzada/geo-seo-claude`.
Neither is part of this plugin. Once the user has both reports, they bring them back here.

That is the whole answer when a report is missing. End it there: no questions about the site, no
"meanwhile" tip, no list, no route. The closing line about tagging links in section 6 belongs to a
finished run, not to this one.

What each tool is and where it comes from: <https://atlas.smolevich.com/tools/skills/>.

## 3. Read them, in this order

1. **`seo-audit`** first. Fetch, block, canonical, indexing, on-page, speed.
2. **`geo-audit`** second. Crawler access, citability, schema, `llms.txt`, platform readiness.

SEO first. Access and indexing decide whether anything else is even read. A citability score for a page
no agent can fetch is a score of a document nobody has.

Check that both reports are for the URL from step 1. If they name another host, say so before merging.

Keep both raw reports. You will cite lines out of them, not summarise them into adjectives.

## 4. Merge into one list

One list, not two. Drop the composite scores — a score moves when anything moves and tells the reader
nothing to do. Keep the individual findings.

Order by this rule, top down. The first rung that is broken outranks everything below it:

1. **Fetchable** — the page returns body text to a plain client. Any crawler, search or AI, that gets
   a 4xx, a 5xx, a challenge page or an empty body is on this rung, whatever produced it: a CDN or
   WAF rule answering 403 to `ChatGPT-User` is a fetch failure, not a directive.
2. **Allowed** — the page is fetched but tells the crawler to stay out: `robots.txt`, `noindex`,
   `X-Robots-Tag`.
3. **Indexed** — submitted, discovered, in the index.
4. **Findable** — the pages answer phrases people actually type.
5

Preview of the first 4,000 characters. Read full instructions →