Skill packs › Skill

Grokipedia AuthorityIN EVERY PACK

Win a Grokipedia page for a person, company, podcast, or book — and keep it accurate. Scores whether Grok can already write and SOURCE a page (readiness), hardens the citable proof, submits through the Suggest-Article flow in a disciplined drip, then monitors and corrects. Runs as a STANDALONE MONTHLY agent because notability accrues on a monthly rhythm, not a weekly one. Step 6b of the Local Service Spotlight method — the AI-encyclopedia sibling of ai-search-visibility.

Skill file grokipedia-authority.md · last updated Aug 12, 2026

Use this when you want your people, clients, companies, podcasts, and books to have a Grokipedia page — xAI’s AI-generated encyclopedia — and you want it done at scale, honestly, without getting flagged for spam.

Grokipedia is not Wikipedia. You don’t write the page; Grok does, by scraping the open web. It builds a page when it can (a) pin down one clearly-identified entity and (b) back every claim with independent, citable sources that clear a lenient-but-real notability bar. That means a Grokipedia page is the external validation of your entity-home work: you graduate to a page when your online legibility finally catches up to your earned credibility. This skill decides who’s ready, makes the ones who aren’t ready ready, and submits the ones who are.

Why this is a STANDALONE MONTHLY agent (not part of the weekly fleet audit)

Read this before you wire the schedule — the cadence is a deliberate design choice, and the same reasoning is printed on every skill-pack landing page so clients understand it too.

• Notability moves monthly, not weekly. The inputs that flip a “not yet” into a “ready” — a new press hit, a published book with an ISBN, an award, a podcast season, a Wikidata item — land on a monthly-or-slower rhythm. Re-scoring weekly burns tokens and Grok’s patience to watch a needle that hasn’t moved.
• Submission must be rationed. Grok penalizes duplicate and thin submissions. A monthly capped drip (top ~3 newly-ready entities per run) keeps the account clean; a weekly firehose gets it flagged. Discipline is the product.
• It’s a different job from the weekly audit. The weekly fleet audit is maintenance (health, SEO, RankMath, interlinking). Grokipedia is promotion of an entity to an encyclopedia — a distinct pipeline with its own registry, its own drip cap, and its own human-gated write (a submission on your X/Grok identity). Bolting it onto the weekly job would blur two jobs and make both harder to reason about.
• It mirrors what already works. Our weekly-fleet-wikidata-audit already proved the pattern for the harder bar (Wikidata): read a registry, drip-create 1–2/run with independent references, never mass-create. Grokipedia is the lower-bar cousin, so it gets the same discipline on a monthly clock.

One agent, one clock, one registry, one drip cap. That is why it stands alone.

What agent kicks this off, and what skills it’s tied to

The Grokipedia Authority agent kicks off monthly (1st of the month). It doesn’t work in isolation — it stands on the skills before it in the method and feeds the one beside it:

• personal-brand-website-agent → the entity home. Grok’s #1 citable source is a live site at your name with Person schema. No entity home, no page. This skill requires that one.
• knowledge-panel-entity-seo → the schema + entity disambiguation. The same Person/Organization JSON-LD that earns a Google Knowledge Panel is what lets Grok pin the right entity and dodge namesakes.
• positive-mentions-harvester → the proof. Third-party mentions, press, podcast spots and awards are the independent sources Grok verifies against.
• definitive-article-writer → citable facts. When Grok gets a date or a claim wrong, the fix is to publish the correct fact somewhere Grok can read it (usually the entity home), then submit an edit.
• ai-search-visibility → the sibling. That skill makes ChatGPT/Perplexity/Google-AI describe you correctly; this one does the same job for the AI encyclopedia. Run them together.

Inputs

• A roster with, per entity: name (proper diacritics), niche, country, entity-home URL, socials, and any independent proof (press, books w/ ISBN, awards, academic records, notable roles).
• The readiness inputs you already have from the audit: entity-home liveness + domain type, Ahrefs DR, proof band, and a notability/namesake triage (who shares your name in the knowledge graph).
• A logged-in grokipedia.com (X/Grok) session for submissions, and dashboard/publish credentials for reporting.

The rules — non-negotiable

• Never mass-submit; respect the rate limit. Grokipedia’s Suggest-Article is rate-limited to ~1 request per 600 seconds (10 min) after a small burst — bursting returns “Rate limit exceeded: max 1 requests per 600 seconds.” Submit ONE at a time, spaced ≥11 min (the grokipedia-drip scheduled task paces this automatically), a few of the strongest per cycle. A thin or duplicate submission costs you more than a slow rollout.
• Disambiguate or don’t submit. If a different, established person owns the name in the knowledge graph and you have no strong anchor (name-domain + niche + location), build the anchor first. A merged/confused page is worse than no page.
• One citable fact per claim. Grok verifies against the open web. If it isn’t published somewhere Grok can read, it isn’t a fact yet — publish it on the entity home first (this is the definitive-article-writer handoff).
• Person ≠ company ≠ podcast ≠ book. Submit them as separate, interlinked entities. Grok rejects a company page that looks like a duplicate of its founder.
• Honesty over coverage. A “ready” call must be defensible. Better to hold a member at “nearly” for a month than to submit and get rejected.

Steps (the monthly pipeline)

1. Score readiness. For every entity compute a 0–100 Grokipedia Readiness Score: identity/20 (can Grok pin one entity?) + entity_home/30 (live, schema’d, citable) + corroboration/30 (independent sources) + authority/20 (DR + active social). Route each to a status: live (page exists → monitor), ready (submit now), nearly (one fixable gap), build (entity home/proof first), hold (namesake/identity unresolved).
2. Detect existing pages. Check grokipedia.com/page/<Name> (diacritic-sensitive — check the proper spelling AND an ASCII-folded fallback). A real page returns HTTP 200 with og:title “Name — Grokipedia”; a missing one returns 404 “Article Not Found.” Anyone already LIVE skips submission and goes to monitor.
3. Harden sources for the “nearly” band: publish the missing facts on the entity home, point pending nameservers so the home goes live, and surface 1–2 independent proofs. This is where most of the value is — it improves the Knowledge Panel and AI-search at the same time.
4. Submit the drip (top ~3 ready, by score): on grokipedia.com, use Suggest Article. Paste the one-line notability rationale, the entity type, and the source list from the entity’s submission package. Submit the person first; once it lands, create each ecosystem entity (company/podcast/book) and interlink.
5. Monitor & correct the LIVE pages: read the page, list factual errors, and submit edit-suggestions — each backed by a citable URL (usually the entity home). Small errors compound; fix them.
6. Report. Write each entity’s status (score, action, page URL) to its dashboard and to the registry, append a dated changelog line, and draft the summary email. Never publish silently.

Output

• A per-entity registry (status · score · action · page URL · ecosystem) + a ranked human-readable report.
• A ready-to-paste Suggest-Article package for every “ready”/”nearly” entity.
• Submitted drip (≤3), monitored corrections, and updated dashboards — with a human-steps list for anything gated (a login, a nameserver, a source that has to be created).

For DealCon — agency owners & acquirers

Grokipedia pages are a productized authority add-on with near-zero delivery cost: the readiness engine and submission packages are automated, and the same source-hardening that wins the page also lifts the client’s Knowledge Panel and AI-search answers. Sell it as “own your name in the AI encyclopedia,” priced as a quarterly authority retainer. The monthly cadence is the deliverable cadence — one clean report a month showing who graduated.

Learned in the field

Appended automatically by the self-improvement loop (Skill-Learnings/): dated lessons from real runs. Newest at the bottom.

<!– learning:2026-08-01-a-resolved-flag-must-be-retired-at-the-source –> August 1, 2026 (from: grokipedia-readiness)

August 1, 2026 (from: grokipedia-readiness)

When research clears a warning, retire the warning where it lives. A resolution written somewhere else is a second opinion, and the code keeps reading the first one.

On June 30 the Wikidata triage filed Claudia Witticke as a namesake trap: Q133434182 looked like a near-empty “seamstress” stub that could not be confirmed as hers. On July 27 a rotation check disproved it — following the item’s GND 1268215171 to the DNB record gives Witticke, Claudia / Land Italien / Beruf Näherin / Gründerin von “Leidenschaft Nähen”, and “Leidenschaft Nähen” is the exact brand on her own domain. The rotation wrote that up correctly and promoted her to tier A. It did not delete the trap entry.

So for five weeks the same file asserted both things at once, and the engine believed the older one. The cost was not cosmetic:

• identity scored 14/20 instead of 20/20, dropping her from 92.4 to 86.4
• she carried a namesake-collision flag, which under the standing disambiguate or don’t rule

meant the monthly drip would skip her — indefinitely, and for a reason that had already been disproved

A stale warning is worse than a missing one, because it is load-bearing. Nobody re-examines a member the file says is unsafe to touch.

Two fixes, and the second is the one that generalises:

1. Retire the entry at the source. Move it to a namesake_resolved key with the evidence and the

date, so the history survives without the live list lying.

1. Make the contradiction self-detecting. A trap says “the only match for this name is someone

else”; a tier-A entry says “this member has an item”. If both name the same qid, they cannot both be true. The engine now resolves that in favour of the newer evidence, prints [STALE-TRAP], and a unit test fails until the underlying file is cleaned.

The general rule: when two records in one system disagree about the same identifier, that is a detectable condition, not a judgement call. Write the check. Silent contradictions get obeyed by whichever code path happens to read first, and the loudest possible failure is cheaper than a member who quietly never ships.

A corollary found in the same file: the rotation note also recorded that the roster’s niche and country for her were wrong (“Style / image coaching, AT” for a sewing author in South Tyrol, Italy). That was flagged and not actioned either — and it would have shipped a false claim about a real person into an encyclopedia. A note that says “X is wrong and should be corrected” is not a correction. Either fix it in the same run or file it where something will fail until it is fixed.

<!– learning:2026-08-01-confirmation-screen-is-not-confirmation –> August 1, 2026 (from: grokipedia-readiness)

August 1, 2026 (from: grokipedia-readiness)

A confirmation screen is a rendering decision. It is not evidence that the write happened. When a submission matters, read the response the server actually sent.

Grokipedia’s Suggest-Article modal has two failure modes that look identical on screen:

The July 4 run recorded that exceeding the rate limit returns a visible Rate limit exceeded: max 1 requests per 600 seconds. On August 1 it returned nothing at all — the form just reset. So the note that was written to prevent a misdiagnosis became the cause of one: the first Witticke attempt looked exactly like the successful Nichterl attempt that preceded it, except Nichterl had shown the Thank-you screen and Witticke had not.

Guessing in either direction is expensive. Assume failure and you re-submit, and duplicates are the one thing this job must not produce — the July run already left two identical Annelie Salminen (writer) rows in the activity log. Assume success and the member silently never gets submitted at all, and nobody notices until the next monthly run.

The resolution is to stop reading the UI. Wrap window.fetch before clicking Submit and capture the POST body:

`js if (!window.__hooked) { window.__cap = []; const of = window.fetch; window.fetch = async function (…a) { const r = await of.apply(this, a); if ((a[1] && a[1].method) === ‘POST’) { const c = r.clone(); window.__cap.push({ s: r.status, b: (await c.text()).slice(0, 300) }); } return r; }; window.__hooked = 1; } `

{"success":true,"id":"<uuid>"} is the fact. Everything else is decoration. Attempts 1 and 2 produced no POST at all; attempt 3 returned success and the Article Requests counter moved 106 → 107 with exactly one new row.

Two general rules fall out of this:

1. Verify a write at the layer that performed it, not the layer that reports it. This is the

same shape as the Elementor lesson (a 200 on the REST write is not a live render) and the scheduled-task lesson (a draft is not staged until a re-fetch confirms it).

1. A documented gotcha has a shelf life. It describes a third-party system on the day it was

written. When a run’s behaviour contradicts the note, the note is the thing to re-check first — and then to correct in place, so the next run inherits the truth rather than the fossil.

<!– learning:2026-08-09-an-empty-capture-proves-nothing –> August 9, 2026 (from: grokipedia-fleet — an armed fetch hook captured nothing on an edit that had already landed)

A silent instrument is not a negative reading. Absence of your evidence is not evidence of absence.

Grokipedia’s edit modal looks identical whether a submission succeeded or was refused. We solved that months ago by arming a fetch hook before clicking Submit and reading the POST body, and wrote the rule down in the skill:

{"success":true,"id":"<uuid>"} is the only proof. Empty __cap = blocked client-side, nothing
created, safe to retry later.

On 2026-08-09 the Escape Fitness edit came back with an empty __cap from a correctly-armed hook, and the modal cleared exactly the way a refused attempt does. By our own written rule that was a non-event and the next step was to retry. The account said otherwise: Total Edits had moved 8 to 9. The edit had landed. A retry would have filed the same correction twice on a client’s page.

Four minutes later the Matthew Januszek edit did capture a fetch POST, id and all. Same site, same modal, same session, same hook — one submission visible to the instrument and one not. So the application does not use a single transport for this action, and a hook on fetch alone (or on XMLHttpRequest alone, or on both — sendBeacon exists too) is a coin flip dressed up as proof.

The deeper error is in the shape of the rule, not the choice of transport. It assigned meaning to silence. A positive capture is real evidence: something happened and here is its id. A negative capture is the instrument saying “I saw nothing”, which is consistent with both “nothing happened” and “it happened somewhere I wasn’t looking.” Those two are not distinguishable from inside the hook, and no amount of hooking more transports fixes that — it only narrows the gap while leaving the logic backwards.

The check. For any write whose success you cannot see directly, find the counter the system keeps — a total, a list, a row count, a version number — and read it before and after. Your own capture is corroboration. Theirs is the verdict. If the system exposes no such tally, say so in the report rather than promoting your instrument to an authority it has not earned.

The tell. Any rule of the form “if I didn’t observe X, then X didn’t happen.” Also: retry logic gated on a negative observation from a probe you built. That is the moment a monitoring gap turns into a duplicate write, which is worse than the original uncertainty because it is now visible to a client.

Related. Same family as [[checks-must-be-able-to-fail]] and [[failed-probe-must-not-look-clean]], and the second instance in this single run of the broader rule [[the-account-is-the-ledger-your-notes-are-a-guess]] — earlier the same day, a run’s own notes recorded one submission where the account showed three. Twice in one run, trusting the artifact we generated over the tally the system keeps would have caused a duplicate write.

What shipped: the task prompt’s edit step now reads the Total Edits counter before and after every submission and treats a captured id as corroboration only; the hook was extended to XMLHttpRequest while explicitly demoting it below the counter; and pages.json records the Escape Fitness edit as confirmed by the counter, with a note naming the wrong rule so the next run cannot inherit it.

<!– learning:2026-08-09-the-account-is-the-ledger-your-notes-are-a-guess –> August 9, 2026 (from: grokipedia-fleet monthly run — the run’s own notes said 1 submission, the account said 3)

When a system holds your history, read the system. Your notes stop at the moment you stopped.

The Grokipedia fleet run submits a capped drip of three requests a month, and it writes what it submitted into pages.json. On 2026-08-09 the run was interrupted after the submissions landed but before it finished. pages.json recorded one submission, Dennis Yu, complete with a captured POST id — exactly the evidence discipline the skill demands, and entirely correct as far as it went.

The account showed three. Article Requests had moved 107 to 110, and the activity feed listed Dennis Yu, Michael Krigsman and CXOTalk at 27, 26 and 25 minutes old. The next agent to pick the job up read the notes, saw one submission against a budget of three, and was two steps from spending a budget that was already gone.

The notes were not wrong. They were truncated — they described the run up to the last moment the run was alive to write anything down. Every record a process keeps about itself has this property, and it is worst precisely when the process died, which is exactly when someone else comes looking.

The same run had already been bitten by the deeper version of this. The August 2 entry announced that Grokipedia “generates pages about our people WITHOUT us” and led with a client, Matthew Januszek. We had requested Matthew Januszek ourselves on January 23. The ledger recording that had been sitting in our own account since January, unopened, for the entire month the claim stood in a changelog and an email to ops. A whole narrative about an external system’s behaviour, built without asking the external system what it had on file.

The check. Before you act on a count of something you did — submissions, posts, invites, uploads, API calls — ask the system that holds it. Not the log you wrote, not the memory file, not the summary from last run. If the external system exposes a total, read the total and diff it against your record; a mismatch is information, and the direction tells you which way you were wrong. If it exposes no total, that absence is worth naming in the report rather than papering over with your own tally.

The tell. Any sentence of the form “we have submitted N so far” where N came from a file you wrote. Also: a plan whose next step depends on remaining budget, quota, or rate limit computed from local state. Those numbers live somewhere authoritative, and it is nearly always one cheap read away.

Related, and the reason this keeps recurring: the same failure shape as the eleven days the agent-runtime plan spent naming a human blocker that had already cleared — a git ls-remote would have said so on day one — and as the weekly Dorine check that compared a source against its own snapshot and never against the clock. In all three, the local record was internally consistent and externally stale. Consistency is not currency.

What shipped: the skill’s submission rule now says to count the budget from the live Article Requests total at the start of the run and before each submission, not from the run’s notes; the two undocumented submissions were recovered from the account and written back into pages.json with a reconciliation block naming how they were found; and the ordering rule the ledger disproved (person-before-company) was corrected in the scheduled prompt so the next run cannot inherit it.

<!– learning:2026-08-10-page-one-is-not-the-ledger –> August 10, 2026 (from: grokipedia-fleet — six-page submission history read as if it had one page, for seven months)

A paginated list read to the end of page one is a partial read that feels complete.

Our Grokipedia account holds 110 article requests, shown 20 at a time across six pages. Every run of this job read page one, built a list called already_rejected_do_not_resubmit_without_new_evidence, and then reasoned from it with confidence. The list had twelve entries. The real number is forty.

The cost was not abstract. On 2026-08-09 we posted to a client’s Basecamp project telling him that his company was the way into the encyclopedia, because the company gets accepted where the individual gets rejected. Showcase Remodels had been submitted on 25 January and rejected. It was on page two. He read a confident recommendation to try the one thing we had already tried and been refused.

What makes this failure mode nasty is that page one is not obviously partial. It fills the screen, it is sorted newest-first so it looks current, and the twelve rejections it did contain made the list feel researched rather than truncated. Nothing about the artifact announces “there are five more pages of me.” Compare a truncated file read, which usually leaves a visible seam.

The check. Before treating any list as complete, find its declared total and reconcile. Grokipedia printed “21–40 of 110” at the bottom of the page the whole time — the count was sitting there in the footer while we generated a twelve-item list from it. Ask: what does the system say the total is, how many did I actually read, and do those match? If there is no declared total, page until a page comes back short, and say in the report how far you got.

The tell. Any assertion of the form “we have never tried X” or “the complete set is Y” derived from a UI that paginates, an API with a default limit, a search that caps at 20 results, or a scroll container. Also: a list whose length is suspiciously close to a round number — twelve rejections out of an unknown total should have prompted the question, and forty out of a stated 110 would not have.

Related. This is the third instance in two days of the same underlying error, which is why it is worth its own note rather than a line in a changelog: [[the-account-is-the-ledger-your-notes-are-a-guess]] (our notes said one submission, the account said three) and [[an-empty-capture-proves-nothing]] (our instrument saw nothing, so we concluded nothing happened). All three are the same shape — an artifact we produced, treated as authoritative over the system’s own record. Notes, hooks, and first pages are all partial views that feel total.

What shipped: the task prompt now has a dedicated step, ahead of any submission, that reads all six pages via ?page=N and refreshes the stored decided-set; pages.json carries _full_ledger_2026_08_10 with all 40 rejections, all 29 creations, and the pagination recipe; and the client who got the wrong recommendation was told directly, leading with our error rather than the platform’s.

Other skills: ai-search-visibility · boil-the-ocean · client-access-checklist · client-relationship-cadence · content-agent · content-factory

The full run order is on the skill-pack directory. Every skill here is one task from the Task Library — the library is the catalogue of what can be done; a pack is the subset you install; an agent is who runs it.