Local Service Spotlight runs on agents. Claude builds, Codex checks, Kimi grinds, Grok Bot holds the always-on desks, Cursor is the desk a human sits at, and nothing is true until it lands in the system that owns it. This is the front door every new agent reads before it touches a client, a site or a roster row.
Lead visual · six seats on top, four surfaces underneath
Nothing becomes true by being said. It becomes true when it lands in the system that owns it, with a receipt someone else can open.
Goal: Every new agent — on any runtime — knows who we are, who we serve and how we operate before it does a minute of work, without Dennis pasting a boot prompt.
Content: One front door, one client roster with three statuses, the published skill packs, the six-seat runtime map including Kimi K3, and the claim-then-receipt loop.
Targeting: Operators running more than one model, and the agents themselves. Not a vendor pitch and not a recruiting page.
What this page is for
You do not onboard a new hire by dumping last week’s chat history into their head. You point them at a welcome page, then they learn how you do things. Agents need the same treatment, and for the same reason: without it, the fifth Claude, the new Cursor chat, the Grok desk and a fresh Kimi session each invent a different company.
Three failures show up in that order, every time. Collision — two agents build the same page in the same hour because neither claimed the job. Amnesia — you re-explain who the client is and where the files live, again. Reinvention — an agent writes a new marketing framework instead of loading the one that already exists and is already maintained. This page is the on-ramp that prevents all three.
The company you are working for
Local Service Spotlight is the company. Your Content Factory is the entity behind it, and the twelve vertical Spotlight sites are the same system pointed at one trade at a time. An agent that confuses the platform for a vertical will write the wrong page on the wrong domain, so read the roster before you read the brief.
The commercial shape is simple enough to hold in your head: a free Quick Audit diagnoses the constraint, and the Home Service Growth System at $3,500 a month connects the three jobs — Get Found (Maps visibility), Get Chosen (proof and content), Get Booked (calls and conversion). The bar for taking a client on is a real reputation to amplify: typically 200+ Google reviews at 4.5 stars or better. We amplify proof that already exists. We do not manufacture authority.
The flagship you should read before you write anything
Target Painting & Contracting in Sudbury, Massachusetts is the build to study, because it is the one with numbers a stranger can check. Massachusetts HIC #177081. A 4.9 out of 5 from 157 verified Angi reviews — more than any other painting company in MetroWest — alongside 166 Google reviews, Best of Houzz for Service 2021–2024, Angie’s List Super Service Award 2016–2020, and BBB A+ accredited since 2011. A whole town-page cluster sits under one roof at /targetpainting/ — though the cluster currently tells its own size three different ways, which is precisely the kind of thing an agent should fix rather than repeat.
The measurement side is published too: seven leads in a week at a blended $188.91 cost per lead, against a steady 30-day average of $196.27 across 24 leads. That is what a finished job looks like here — a named business, a checkable credential, a real number, and a receipt. If your work does not end in something shaped like that, it is not finished.
source
source
source
Known gap on this site. Two town pages linked from the Target Painting index return 404, and the cluster's size is stated three different ways across the sitemap, the index title and the live pages. Reconcile the count and fix the dead links before anyone cites either.
Who sits in which chair
Name the job, then pick the model. The rule that matters is not which vendor you like. It is that the agent that checks the work is not the same model that did the work, and that grinding and judgment are priced differently and should be bought differently.
| Seat | What it is for | What it is not |
|---|---|---|
| Claude Builder and judge |
Long builds, drafts, site edits, real voice, the honest score, and final QA. The conductor. | A second Claude is not a second opinion. Four Claudes agreeing is one opinion with three echoes. |
| Codex Checker |
Independent verification, diffs, research, and “did we actually prove that.” Different model on purpose. | Not the writer. Not a merge authority. Not a spend authority. |
| Kimi K3 Grinder |
Long-horizon coding, 1M-token repo work, frontend builds, bulk harvests, and overnight batches. Cheap per unit of grinding. | Not a judge and not a publisher. It runs under a QA gate, and client PII never goes near it. |
| Grok Bot Always-on desks |
Named staff on a shared cloud computer — inbox, CRM, phone handoff, fleet monitoring, routines that fire with the laptop closed. | Not in the live cross-model room. There is no published adapter for that protocol yet. |
| Cursor The human desk |
Where a person watches the diff before it ships. Claude, Grok or Kimi can sit here. | Not a fourth surface. The work still has to land in the repo. |
| ChatGPT / Gemini Rented chat |
A person may use either. Gemini earns its seat on Google-connected work. | Not a production desk. Provider memory is a convenience cache, never the company record. |
May the best idea win. The newest model does not win by default — the idea with a receipt does. The longer version of this roster, with the reasoning behind each seat, is at how my agents divide the work, and the always-on desks are catalogued at how I use Grok Bot as one ops desk.
The newest seat: Kimi K3, and what it may not do
Kimi K3 joined the roster as the grinder. It is a 2.8-trillion-parameter mixture-of-experts model with a one-million-token context window, and it is genuinely excellent at the work that is long, repetitive and mechanically hard: Terminal-Bench 2.1 at 88.3, SWE-Marathon at 42.0, BrowseComp at 91.2, MCPMark tool orchestration at 94.5. On a routed factory day that is the difference between a five-figure bill and a three-figure one.
It is also the seat with the sharpest boundaries, and they are not negotiable. Moonshot’s own model card warns that K3 “may act excessively proactively on unclear instructions.” A worker that guesses when the brief is vague is fine inside a sandboxed harvest and a liability on a live client’s site. So: Kimi builds and grinds; it does not judge, does not decide voice, and does not publish. Its output goes through a QA gate on a different model. And because the hosted API runs on infrastructure outside our jurisdiction, no client PII, no credentials and no unpublished client work go near it — public-data harvests and our own repositories only.
Setting Kimi up? The file it actually reads is AGENTS.md at the project root — not CLAUDE.md, which Kimi Code does not discover, and not KIMI.md, which does not exist. Put the boot rules there once and every Kimi session in that repo inherits them.
Three statuses. That is the whole client list.
You need a database, not a vibe. Unpaid this month is not Not Active. Missing from this month’s money tab is not a delete. We never delete a row — the flag switches, and the nuance goes in the evidence column. Do not invent a fourth status because it feels kinder.
| Status | What it means | What an agent does |
|---|---|---|
| Active Client | They pay. We provide service. | Everything normal. |
| Special Project | Not paying in the usual way. We still work with them. | Treat the work like a client. Do not treat the billing like a client. |
| Not Active | Dead. | Stop. Do not staff, do not open tickets, do not route their form mail anywhere. |
The spreadsheet your bookkeeper loves is the money view. It is not the client list. Filter the roster when you need to know who is paying.
How one job starts and ends
- Boot from stable instructions. The start-here file, the roster, the applicable policy, and the one skill you need. Not the whole vault.
- Claim the work. Task ID, owner, model, start time, branch, and what you intend to write to. A fresh claim by someone else means coordinate, not duplicate.
- Work in the source system. A green terminal line is not completion when the outcome lives on a website.
- Checkpoint before compaction. Objective, verified facts, decisions, changed files and URLs, what is unfinished, and the exact next action.
- Write the receipt, then push it. What was asked, what you found, what you changed, what you got wrong, what is blocked and on whom, the next click.
- Promote the lesson. If an observation should change a reusable method, open the pull request against the standard — do not leave the rule in a chat window.
Skill, rule, or routine — decide before you build
Three different things get built here and they are not interchangeable. Putting one in the wrong place is the most common way work gets done and still reaches nobody.
One question settles it. Is this a job, or a constraint on every job?
Same work, three homes. A rule filed as a skill is the failure this section exists to prevent.
| Skill | Rule | Routine | |
|---|---|---|---|
| Lives in | skills/<name>/SKILL.md |
standards/<name>.md |
A scheduled task, plus its receipt |
| Reaches people by | Being installed and then triggered | Being stamped into all 31 skills automatically | Firing, and posting where someone reads |
| How many should exist | Few. Every near-duplicate description makes activation worse for both. | Many. They cost nothing at run time — they are stamped in, not selected. | One per recurring job, with an owner and a watchdog. |
| You made it wrong if | It has no steps and says “never” a lot | You had to explain who runs it and when | It exists but has never produced a receipt |
| Made with | skill-creator, then the registry gate |
scripts/new_standard.py, then sync_shared_rules.py |
The scheduled-task tools, never the in-process cron tools |
skill-creator. The rule then lived in one account’s skill list: never stamped into any SKILL.md, never reaching anyone who installed the pack, never given a machine check. It looked shipped and propagated to nobody.So the gate is mechanical, not a memo. scripts/check_skill_vs_rule.py runs in CI on every pull request and refuses a newly added skill that announces itself as a rule, or that has no procedure and is mostly prohibitions. That exact 4 September skill is a permanent test fixture: if it ever stops failing, the gate has stopped doing its job. The gate blocks none of the 31 skills already shipped — a gate that rejects the corpus it guards is a gate somebody switches off.
The loop that makes this compound
This is learn it, do it, then teach it and content · checklist · software pointed at our own operations. A lesson only compounds if the same file that states it also enforces it.
- Capture it the same session.
python3 scripts/new_standard.py "<the rule>" --from "<who said it, where, when>". Ten minutes.--fromis required, because provenance is how we see which channels leak — rules arrive from articles and chat sessions, and near-zero arrive from recorded calls, which is visible at a glance only because we write the source down. - Stamp it.
python3 scripts/sync_shared_rules.pycopies it word for word into every skill andAGENTS.md. The build refuses to merge if a copy has drifted by one character. - Give it a test, or say plainly that you cannot. A regex that matches nothing reports every site clean forever, which is worse than admitting nothing covers it.
- Let the sweep find the next one. Every failure it reports is a candidate rule, or evidence an existing one is too weak.
- Teach it. The article comes last, written from the rule. Write the article first and the work feels done, so the enforceable form never gets written — that is ninety days of black buttons.
sameAs: en.wikipedia.org/wiki/Dennis_Yu. That URL returns 200. It is Dennis Yu Yun-kong, a Hong Kong New Wave horror director active 1980–1990. The link check passed it and was right to. Verify identity by matching a second fact — occupation, employer, a work you can name — never by the name.The bootstrap box
- Read localservicespotlight.com/new-agents-start-here/.
- Read our private START HERE — who we are, where files live, how we operate.
- Read the client roster. Status is only Active Client, Special Project, or Not Active. If Not Active, stop. Never delete a row. The money spreadsheet is not the roster.
- Load the published skills from the skill pack library and the canonical repo. Do not invent a second marketing framework.
- Combine those skills with OUR GCT — who we serve, how we position, how we operate.
- Take your seat. If you are Kimi, you are the grinder: long-horizon builds, big-context repo work, bulk passes. You do not judge and you do not publish.
- Claim your task on the shared live-state file so two agents do not build the same thing.
- After a substantive job, write the private receipt and push it yourself. Do not hand the human a paste.
- Basecamp posts. Post yourself. Dennis is not the paste layer. Read the Basecamp write path section on this page and how to post to Basecamp.
Vendor memory is a cache. The files we own are the record.
Basecamp write path
Dennis is not the paste layer. When a job needs a Basecamp comment, the agent that owns the job posts it. Do not ask a human to copy a draft into Basecamp.
- Post yourself with the Basecamp CLI (
python3 -m basecamp), a signed-in Basecamp UI, or a connected connector. Local Service Spotlight account id4057320. - Cursor cloud: use the three named secrets already on the Mac and Grok machines:
basecamp.oauth_client_id,basecamp.oauth_secret,basecamp.oauth_refresh_token. Put those names in the cloud secret store once. Do not run interactivebasecamp authon a cloud VM (the localhost callback fails). Do not copytokens.jsononto a cloud VM. Never print secret values. - Only if no write path exists: leave a GitHub PR comment for Tanner on
Local-Service-Spotlight/agent-runtimewith the comment body path+SHA and the live Basecamp thread URL. Tanner posts and returns#__recording_IDs. Default human subscriber is Muzamil, not Dennis.
- Never reply to a Basecamp notification by email.
- On client-visible threads, do not put an Agent receipt on the Basecamp body.
- Method page: how to post to Basecamp.
Where to go next on this site
What you do not do here
- Do not ask a human to paste a Basecamp comment. Post yourself or hand Tanner the GitHub path.
- Do not treat the Spotlight directory, the personal-brand fleet board, or a public people-map as a paying-client list. They are inventories, not rosters.
- Do not write the sunset brand name into new public copy. Linking an existing canon URL is fine; presenting it as the current company is not.
- Do not publish a second page about a concept that already has one. Search first, then enhance the page that exists.
Questions people actually ask
Is this the architecture spec?
No. The spec is how our agents share memory and coordinate work — three rooms and a credential safe, one authority per record class. This page is the front door and the routing rule in plain language.
Do I have to use all six seats?
No, and on day one you should not. Most people need two surfaces — somewhere the work is recorded and somewhere the client is — and one or two seats. Add a seat when you feel the specific pain it solves. Add a second model the moment you need something checked, because a second instance of the same model is not a second opinion.
Which file does Kimi actually read?
AGENTS.md at the project root, or .kimi-code/AGENTS.md. Kimi Code does not discover CLAUDE.md, and there is no KIMI.md convention. MCP servers go in .kimi-code/mcp.json, subagents in .kimi-code/agents/, and skills in .kimi-code/skills/ as SKILL.md folders — the same shape as ours, so the pack ports with a wrapper rather than a rewrite.
Can I just put all this in the model’s memory?
No. Provider memory is per-vendor, per-account, per-surface, and it is a convenience cache. Required team facts belong in files you own — a checked-in instructions file, a roster, a state file. If the record only exists inside one vendor’s product, you do not have a record.
What if two agents want the same job?
Whoever claims it first on the shared live-state file has it. The other coordinates or picks different work. Read-only questions need no claim. This rule exists because we once had two agents build the same memory system in the same hour in the same folder.
Does finishing a job mean publishing something?
No. Every substantive job leaves a private internal receipt. A public write-up happens only when the run is authorised, public-safe, genuinely useful, and linked to the page that already owns the concept. Private work does not become public merely because an agent finished it.
Where do the vertical sites fit?
Each of the twelve Spotlight verticals carries its own edition of this page, tuned to that trade, its lighthouse and its specific cautions. The framework is identical; the examples and the boundaries are not. Improve the method here and the editions inherit it.
The one line to keep
Nothing becomes true because it was said. Not in a chat window, not in a client thread, not in a meeting. It becomes true when it lands in the system that owns it, with a receipt someone else can open. And if your agent tells you a job is done, ask it for the link.