Dunker Spotlight runs on agents. Claude builds, Codex checks, Kimi K3 grinds, Grok Bot holds the always-on desks, and Cursor is the desk a human sits at. Before any agent touches this site, a dunker’s name, or a roster row, it reads this page. Same framework as the rest of the network, tuned to dunking.
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: Any new agent working on Dunker Spotlight knows who we serve, what counts as proof in dunking, and where the boundaries are — before it writes a word.
Content: The six-seat runtime map including Kimi K3, the three-status roster, the claim-then-receipt loop, the dunking lighthouse, and the specific cautions that apply on this domain.
Targeting: Agents and operators working the dunking vertical, plus anyone copying the pattern for their own network.
This is the Dunker Spotlight edition. The network master lives at Local Service Spotlight. The framework is the same everywhere; the examples, cautions and links on this page are this site’s. Improve the method at the master, and the reasoning here inherits it.
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.
What is different about Dunker Spotlight
Dunkers produce world-class content and go undiscovered. A hundred million views on someone else’s platform, and nothing a sponsor’s lawyer can point at. This site is where the Spotlight template was born — every vertical in the network still renders from a CSS block literally named #dunker-spotlight-pro — so an agent working here is working on the original.
The money here is sponsors, coaching, camps and bookings rather than a marketing retainer, which changes what proof looks like. A booked camp is the outcome. Views are the input.
A Knowledge Panel at seventeen, and a site built over a lunch break
Dylan Haugen is the proof of concept: a full personal-brand site with a 200+ Google Knowledge Graph confidence score and a verified Knowledge Panel, earned at seventeen. Six contest wins, 100M-plus views, a signing with Shaq’s DunkMan League, and host of the Dunk Talk Podcast.
Cam Hazzard is the operational proof: a pro dunker with a tested 50-inch vertical, hand-picked by Shaq for the DunkMan League, whose site was generated by an AI agent from interview transcripts during a single lunch break. That sentence is the reason this page exists. The bottleneck was never the building. It was that every new agent had to be re-briefed from scratch before it could start. Fix the briefing and the lunch break scales.
source
source
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.
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.
Vendor memory is a cache. The files we own are the record.
Where to go next on this site
- this site’s personal brand audit
- the Spotlight offer
- model judgment — the routing ladder
- how we optimize
- set up Claude
What you do not do here
- Do not invent a dunker success story. If this site has no published outcome yet, say so and go get one — a real number from a real operator beats a page of adjectives.
- Do not repeat a score, award or credential you have not verified. Everything on a Spotlight site is supposed to be checkable by a stranger; that is the entire product.
- Do not write the sunset brand name into new public copy. Local Service Spotlight and this vertical site are the public brands.
- Do not publish a second page about something that already has one. Search the site first, then improve 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.
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.