New Agents Start Here

Local Service Spotlight runs on agents with named responsibilities and checkable results. Happy coordinates the fleet; dot owns this onboarding page and the company guide’s documentation and QA. Choose builders and independent reviewers for the task, using tools and permissions actually available. This is the public front door; begin with one draft before touching client records or live systems.

Your first checked result — one assistant, draft only

You are the outcome owner. Your assistant drafts; you or a separate reviewer checks the sources. Start with the existing no-install proof-to-offer exercise. No subscription change or private account access is needed. Public-web access or public page text you provide is needed.

Choose one public business URL, desired result, audience and offered package. For a safe practice run, use https://localservicespotlight.com/install/ as the public reference, the goal “explain the first-result path,” the audience “first-time assistant users,” and the practice package “one checked public-reference brief.” This practice package is your exercise input, not a claim about a commercial offer.

Copy the prompt below, replace the owner and inputs, and run it in your current assistant. Keep the task ID for retries.

Task ID: onboarding-practice-001. Outcome owner: [your name]. Reviewer: [you or a named separate reviewer]. Coordinator: [your existing coordinator, or the outcome owner].
Public source URL: [URL]. Goal: [result]. Audience: [audience]. Offered package: [package].
Read the public source. Make a one-page proof-to-offer brief with Goals, Content, Targeting; up to three claim/source rows; one supported gap; one draft improvement; and one checkable next action. Mark self-description, independent evidence and UNKNOWN separately. Do not invent missing facts.
Allowed: read public sources, draft here, and save in an already permitted workspace. Do not install, connect accounts, use private data, send, publish, spend, change permissions or schedule work.
Keep one record with the task ID, owner, inputs, exact draft, source URLs, retrieval date, source revision or UNKNOWN, checks, failures, reviewer decision and next action. Call this a public-reference draft, not an installed-skill test.
Stop if a source is unreadable, an input is missing, another owner has claimed the task, or the next action exceeds these permissions. State the blocker and one bounded next step.

Check before accepting: open each cited source; confirm each claim is supported or UNKNOWN; inspect the actual draft improvement; name one defect and repair it. The owner records PASS, FAIL or BLOCKED and the reviewer’s decision. No advertising qualification or installation claim follows from this exercise.

Fresh-session continuation: save that same record and draft as revision 1 in your existing document or permitted workspace. Start a new session and tell it only: “Open [record location or attached record], task onboarding-practice-001, revision 1. State the owner, permissions, source, last check and next action; then continue only the draft task.” The new session must actually read the record. If it cannot access it, record BLOCKED and provide the record through a supported attachment; do not re-create context from memory or claim automatic handoff. Verify the revised draft against the same sources.

This tests one public drafting path and deliberate record retrieval. It does not test a full installation, private isolation, scheduling or automatic propagation. Propose a reusable improvement from the observed defect; review it, update its canonical source and test a fresh consumer before calling it adopted.

Lead visual · responsibilities above, record surfaces below

Fleet coordinatorHappyCoordinates fleet work; assigns and accepts bounded outcomes.
Documentation and QA ownerdotOwns this front door and the company guide; checks revisions and usability.
BuilderChosen workerProduces the authorized draft or implementation; records evidence.
Independent checkerSeparate reviewerChecks the actual result and sources; consequential work needs proportionate independent review.
EA and execution desksGrok BotPerforms named desk work within its approved task and verified access.
Human decision ownerYouSupplies reserved decisions and approves consequential scope.
1. RecordTeam ledger — authoritative for its coordination records
2. DecisionThe client tool — the client is in the room
3. HandoffThe live room — two models, one channel
4. ClockScheduled jobs — nobody watching

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.

Six seats, four surfaces. The architecture — three rooms and a credential safe — lives in the shared-memory guide. This page is the front door.

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 role-based ownership map, 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 supplies a method for reducing all three; actual claim rejection and context retrieval need their own tests.

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.

157 Angi reviews at 4.9, 166 Google reviews, MA HIC #177081
source
$188.91 blended cost per lead over a week; $196.27 across 24 leads in 30 days
source
Three hours on site and roughly $100 of model spend to install agents at Hippo Roofing
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 owns which responsibility

Name the outcome owner and approval boundary before choosing a model. One assistant can draft a first result; a separate reviewer checks it. App capabilities and background execution vary by account, runtime and version. Verify them rather than treating a vendor name as a guarantee.

ResponsibilityCurrent owner or selectionBoundary
Fleet coordinatorHappyCoordinates fleet work; assigns and accepts bounded outcomes.
Documentation and QA ownerdotOwns this front door and the company guide; checks revisions and usability.
BuilderChosen workerProduces the authorized draft or implementation; records evidence.
Independent checkerSeparate reviewerChecks the actual result and sources; consequential work needs proportionate independent review.
EA and execution desksGrok BotPerforms named desk work within its approved task and verified access.
Human decision ownerYouSupplies reserved decisions and approves consequential scope.

Choose a runtime after you choose the task

Use an assistant you already have for the first public draft. For later work, verify supported tools, instruction loading, authorized data, cost limits and independent review in your actual account. A model name or saved prompt does not install a skill, enforce a client boundary or establish an always-running desk. Hosted models and connectors may transmit data; local storage alone does not make all processing local.

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

  1. Boot from stable instructions. The start-here file, the roster, the applicable policy, and the one skill you need. Not the whole vault.
  2. Own the outcome as an A player. Read the contractor project-lead standard, use the team instead of routing every question through Dennis, and prove the result in the source system.
  3. 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.
  4. Work in the source system. A green terminal line is not completion when the outcome lives on a website.
  5. Checkpoint before compaction. Objective, verified facts, decisions, changed files and URLs, what is unfinished, and the exact next action.
  6. 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.
  7. 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?

SKILL — a jobHas a trigger someone types, inputs, a procedure, a deliverable, a finish line. “Run my weekly MAA.”
RULE — a constraintNo inputs, no deliverable. Governs how every job is done. “Never ship a black button.”
ROUTINE — a clockNot a thing, a schedule. Names a skill and a destination, and fires whether or not anyone is watching.

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
The tell is self-description. A skill whose own description says “layout rule for”, “the standard for”, or “our policy on” has told you what it is. Believe it. This is not hypothetical: on 4 September 2026 an agent with the entire pack loaded was asked to make a layout rule global, and wrote it as a skill — because the tool it had was 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.

How one lesson becomes content, a checklist, and software — and returns as a sharper rule One lesson, one file standards/<the-rule>.md CONTENT Inside all 31 skills Stamped in, so it travels with them. CHECKLIST What a person reads Before anyone touches a site. SOFTWARE The live sweep Generated from the rule, so it cannot disagree with it. A violation found in the wild sharpens the rule — same file, same day
The article is downstream of the rule, never upstream. Write the checkable rule first; the sweep is generated from it, so the rule and the thing that checks the rule can never disagree.
  1. Capture it the same session. python3 scripts/new_standard.py "<the rule>" --from "<who said it, where, when>". Ten minutes. --from is 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.
  2. Stamp it. python3 scripts/sync_shared_rules.py copies it word for word into every skill and AGENTS.md. The build refuses to merge if a copy has drifted by one character.
  3. 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.
  4. Let the sweep find the next one. Every failure it reports is a candidate rule, or evidence an existing one is too weak.
  5. 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.
Where the machine cannot help. A sweep can ask whether a URL resolves; it cannot ask whether it is the right person. On 4 September 2026 the Person schema on this very site claimed 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

Feed this to any agent — Claude, Kimi, Codex, Grok, Cursor, ChatGPT, Gemini. For company work, verify authorized access before reading our private START HERE and roster. The public practice exercise above needs neither.

  1. Read this company front door, then the current company guide and the first-result/install path.
  2. Read A Players Only: the contractor project-lead standard. Route work to the named team owner; escalate Dennis only for a bounded owner-only decision.
  3. Read our private START HERE — who we are, where files live, how we operate.
  4. 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.
  5. Load the published skills from the skill pack library and the canonical repo. Do not invent a second marketing framework.
  6. Combine those skills with OUR GCT — who we serve, how we position, how we operate.
  7. Name the task owner, permitted actions and independent reviewer. Select the worker by tested task capability; a model name grants no publishing authority.
  8. Claim your task on the shared live-state file so two agents do not build the same thing.
  9. After a substantive job, write the private receipt and push it yourself. Do not hand the human a paste.
  10. Basecamp posts. When the task explicitly authorizes a post and the intended account/thread is verified, use the supported write route and check the posted result. 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

When a task authorizes an external post, verify the intended account and thread, use an already approved connector, CLI or signed-in UI, and read back the result. Access is not authority to message. Do not create credentials or copy tokens into a new runtime as part of this public exercise. Stop if the required route or permission is missing. Never reply to a Basecamp notification by email. Use the maintained Basecamp method for authorized work.

Where to go next on this site

What you do not do here

  • Use a supported, authorized handoff for external comments; do not turn missing access into an unapproved send.
  • 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 instructions does my assistant load?

Follow the current supported installation path for your app. In a fresh task, confirm the actual instruction or skill revision was read and check the output. A file’s presence or a link in a prompt does not prove activation.

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, rebuild and sync affected editions, then verify that a fresh consumer receives the revision. Updates do not reach every copy automatically.

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.

Scroll to Top