Working with our agents
Keep your agents current
Install once. After that, your agents pick up every new skill and every new house rule we publish — one lane entirely on its own, the other with a single click. Here is how it works, and what to paste.
One of them is already automatic
Everything we publish lives in one public repository. How it reaches your agent depends on how that agent reads.
Lane B — agents that read files at run time
Codex, Cursor, Grok, and any scheduled job that fetches its instructions before it works are all in this lane. They read the files fresh on every run, so they are current by construction. There is nothing to install and nothing to remember. Point them at the repository once:
https://github.com/dennisyu/local-service-spotlight-skillsIf you write your own agent instructions, the same trick applies: have the agent fetch its rules at the start of every run instead of pasting them in. A pasted rule is a snapshot of the day you pasted it.
Lane A — the Claude plugin
Claude installs the pack as a plugin. That is faster and safer at run time, but it means there is a copy on your account, and a copy can fall behind. Depending on your Claude surface and settings, updates may apply on their own or may wait for you to press Sync.
A chat session cannot install or update a plugin for you. Any agent that claims it did is wrong. What an agent can do is notice the moment your copy falls behind, tell you exactly what changed, and hand you the one click. That is what the job below does.
Paste this once and stop thinking about it
Create a scheduled task in Claude — daily is plenty — with exactly this prompt. Replace [WHERE] with wherever you want the answer: a Basecamp thread, a Slack channel, an email to yourself.
Use the skill-registry skill.
Check whether my Local Service Spotlight skill pack is current, and tell me
exactly what changed. Do not reinstall anything.
1. Read the newest commit on the main branch of the public repository:
https://api.github.com/repos/dennisyu/local-service-spotlight-skills/commits/main
(public, no token needed). Record its SHA and date.
2. Read the commit my installed `lss-everything` plugin reports. If I have no
record of an accepted commit, say so and treat this run as the baseline.
3. If they match, write one line: "No change — still on ." Then stop.
4. If they differ, list in plain language what changed since my commit:
which skills were added, renamed or removed, and which house rules
(files under standards/) are new. Renames matter most — a renamed skill
silently breaks every scheduled job that calls it by name, so name any of
my jobs that reference a changed skill.
5. Tell me the exact click path to sync:
Claude -> Customize -> Plugins -> lss-everything -> Sync.
Say plainly that you cannot do this step for me: a chat session cannot
install or update a plugin.
6. After I sync, verify: start a fresh chat, trigger one changed skill using a
literal phrase from its description, and record whether it fired.
Post the result to [WHERE]. Post the "no change" line too — a quiet run and a
run that never fired must not look the same. Three things in that prompt are doing real work, and they are the three that scheduled jobs usually get wrong.
- It names the skill. A scheduled task starts a fresh session with no memory of the conversation that created it. Implicit triggering is unreliable in an unattended run, so the skill is named outright.
- It compares commits, not dates. File modification times drift for reasons that have nothing to do with content.
- It reports on quiet days too. A job that only speaks up when something changed is indistinguishable from a job that stopped running. Ours has been wrong about that before.
Same job, different last step. Have your agent git pull the repository and read AGENTS.md at the start of every run. In Lane B there is no sync step to click, because there is no copy to fall behind.
You do not have to read them to follow them
A rule that lives only in an article is a rule the next agent will break. We learned that the expensive way: a rule about button contrast was published in May 2026 with an article, an illustrated explanation and a plugin to enforce it. Ninety days later an agent with the entire pack loaded shipped a black button onto a paying client’s site. Nothing was broken and nobody was careless — the rule had simply never entered the one directory agents actually read.
So every house rule now lives as one file, and a script stamps that file word for word into all 31 skills and into AGENTS.md. When you install the pack, the rules come with it. You do not have to know they exist.
The same file carries the test. The live sweep is generated from the rule, never written beside it — because the moment a checker is maintained separately it drifts, and a checker that passes pages which break the rule is worse than no checker at all.
Three tiers, and what each one is for
Not everything can be public, and not everything should be private. The split is by who is allowed to see it, not by how finished it is.
| Tier | What is in it | Who can read it |
|---|---|---|
| Public local-service-spotlight-skills |
The 31 skills, the 38 house rules, the scripts that stamp and sweep them. Everything that is method rather than client data. | Anyone on the internet. No account, no login, no ask. |
| Community | Working examples with real numbers, client-shaped templates, the runbooks that are only useful once you are actually doing the work. | Members, by invitation to the repository. |
| Client and internal agent-runtime, agent-fleet |
Credentials policy, per-client configuration, the scheduled-job fleet, anything naming a client’s numbers. | Us, and the client it belongs to. |
The method is public on purpose. If a rule of ours is any good it should be checkable by people who will never pay us, and the ones that turn out to be wrong get found faster that way.
Six states, and only one of them is proof
Most update problems are really reporting problems: somebody says “shipped” when they mean “downloaded”. Use these words exactly, and the ambiguity disappears.
| State | What it proves | What it does not prove |
|---|---|---|
| Available | The change is in a merged, validated commit | That anyone has it |
| Delivered | A link or file reached you | That you opened it |
| Installed | Your account lists the bundle | That it is switched on |
| Tested | A fresh chat triggered the skill | That an unattended run will |
| Scheduled | A job exists with an owner and a next run | That it has ever fired |
| Observed | A timestamped firing produced real output | — |
Scheduled is not Observed. A schedule object is not a run. If your daily checker has never posted a line — not even a “no change” — you do not have a quiet week, you have a job that is not firing.
Seeing the plugin in a list proves it is installed. Only a fresh chat that actually triggers a skill proves it works.
If you find a rule of ours that is wrong
Open an issue or a pull request on the public repository. Two things make a contribution easy to accept:
- Say where the rule came from. Every rule we keep records who said it, where, and when. Provenance is not bureaucracy — it is how we see which channels leak. Rules captured from articles and chat sessions are plentiful; rules captured from recorded calls are near zero, and that gap is visible at a glance precisely because we write the source down.
- Bring the test, not just the claim. If a rule can be checked against a live page, the check belongs in the same file as the rule, with one example that should trip it and one that should not.
New to the pack? Start at the install guide — it is the front door, and it tells you where to click.