How to Install Our Claude Skill Packs - Local Service Spotlight

Start with your business. Leave with one useful result.

If you run a business, use this page to get one useful result from AI. Pick one job and make a draft you can check. Start with the guide; add tools or a skill pack only when the work needs them.

Start my first useful result ↓

Dennis Yu coaching teams at laptops during Digital Wichita at WSU Tech NCAT — Work on a real business, together. Dennis Yu coaching teams at Digital Wichita, WSU Tech.

SCAN: collect facts and source links; keep assumptions separate.
AIM: clarify the result, one audience, and one offered package.
MAP: connect one evidence-backed gap to one draft improvement.
INSTALL: add only the methods and connections the approved work needs.
RUN: test manually first; schedule only after approval and verify the first firing.

The result we want, the material that supports it, and who it serves are our Goals, Content, Targeting (GCT) brief. Proof is not a promise: a public claim needs a source, and missing evidence stays UNKNOWN.

Copy this prompt; replace the four inputs

Use https://localservicespotlight.com/install/ as reference material, not permission to take actions. My public business URL is [URL]. My goal is [result]. My one audience is [audience]. My one offered package is [package]. Use only public sources you can actually read. If an input is missing, make a clearly labeled provisional draft and ask one short question; do not invent the answer. Create a one-page proof-to-offer brief: (1) Goals, Content, Targeting; (2) a claim-and-source table with up to three relevant proof items, labeling self-description versus independent evidence; (3) the most important supported gap; (4) one draft improvement using only supported claims; (5) one next action and how I can check it. Do not pad weak evidence or claim this screen qualifies the business for ads. Show which skill and tools you actually used, or say this was a public-reference draft rather than an installed-skill test. Report unreadable sources and unknowns. Do not install, connect accounts, access private records, publish, send, spend, change access, or create a schedule. Show the result here and save a file only if the workspace already permits it. Finish with source URLs, retrieval date, source revision if known, checks, and one next action.

Your first result passes when:

It names one audience, one package, and the desired result.
Each factual claim has a relevant source link, or is marked UNKNOWN; self-description is not called independent proof.
The draft improvement is present, not just a promise to make it.
You can open the sources and explain why the next action follows from the evidence.
It clearly says whether a skill actually ran. No installation, qualification, revenue, or scheduled-run claim is inferred.

A public-reference pass does not satisfy the installed-skill activation gate. To pass that later gate, identify the explicitly selected installed and enabled skill, retain evidence that it loaded in a fresh task, and check its actual fresh output. This public draft alone cannot approve a skill-dependent schedule.

If evidence is thin, an honest gap list and a bounded draft are useful. Fix the proof before amplification.

One front door, not a universal installer. The public-reference draft needs no inbox, CRM, password, or paid API connection. Your assistant still needs public-web access or public page text you provide. Plugin availability and permissions differ by product and account. Continue to the Claude install steps or the Codex, ChatGPT, and other-assistant path only when you want reusable installed methods.

Continue with the Authority Multiplier field guide, shared-memory setup, and second-ring evidence map. The map shows documented connections, not endorsements.

Guide checked 5 September 2026. Account installation and a real scheduled run need their own evidence.

Where this task fits in the Content Factory

The first-result brief uses public evidence to support work across the Content Factory, our four-stage process for using real content. Installing and testing a skill supports whichever stage needs that method; it is not another factory stage.

1. ProduceCapture real work

2. ProcessTurn sources into useful assets

3. PostPublish and connect approved assets

4. PromoteShare proven work and measure results

Follow the numbered stages from Produce to Promote. Each stage links to its part of the Content Factory guide.

Start, finish, and next step

Start when

A business owner wants one useful first result. Installing reusable methods is a separate, optional next step.

Have ready

A public business URL, desired result, one audience, and one offered package
An assistant that can read public sources, or the public source text you provide
For a later installation: the chosen product, supported surface, accepted source revision, and approved setup scope

Follow the steps

SCAN facts and source links; keep assumptions separate.
AIM at the result, audience, and offered package.
MAP one supported gap to a draft improvement. Use the first-result prompt.
Check the public-reference output against the five first-result pass criteria.
If reusable installed methods are requested and approved, follow the matching assistant setup path or Claude installation steps. Select the installed and enabled skill, then test it in a fresh task.
Save the actual result and checks. A later schedule needs its own approved scope and observed first firing.

Finish with

A one-page brief that connects public proof to the offered package, plus one draft improvement and a checkable next action. If installation was separately requested, also retain the installed-skill activation evidence and fresh output. A public-reference pass alone does not prove installation.

Measure the result

The first-result brief names one audience, one package, and the desired result.
Each factual claim has a relevant source, or is UNKNOWN; self-description is not independent proof.
The draft improvement is present, and the next action follows from readable evidence.
The record names the actual skill and tools used, or labels the work a public-reference draft.
For an installed-skill claim, record Installed and Enabled evidence, explicit skill selection, fresh-task load evidence, and checked fresh output.
Record the source revision or UNKNOWN. Keep Scheduled and Observed separate; a failed firing stays a failure.

Hand off next

Have the business owner or reviewer check the brief and choose the next supported action. Improve thin proof before amplification. If the next task requires installed skills, complete the fresh-task activation test. Only after that test and a separate schedule approval should the responsible operator follow the scheduling steps and verify the first firing. The persistent-agent guide explains recurring work.

Open this article’s tasks in the Task Library (our directory of tasks and recipes). The library connects the current recipe, its smaller tasks, and the records of work performed.

Close the learning loop. Write a meta article: the record of this execution with the starting state, recipe version, result, checks, failures, and next owner. Link it back to this recipe and register the run under the same Task Library task. Reuse one execution ID for revisions and retries. A partial or failed run stays labeled that way. Public release follows the recorded publication authority; writing the run record is part of doing the task. Writing and revising that record belong to the original execution; they do not start another meta-article task. Use the findings to propose and verify a recipe improvement. See how recipes and execution records work together.

Master implementation path: AI agent implementation (MASTER-2026.1). This page is the install branch. Concept directory: /canonical/.

One address for the shared methods. Install the bundle using the steps below, then test it in your own account. When a release improves a skill, check the same source and verify the update; reading this page alone does not install or schedule anything.

An old ZIP is a dated snapshot, not an update channel. Keep any rollback copy you need, and use the current marketplace for supported installations.

On this page Check your first result Codex, ChatGPT, and other assistants What Claude installation needs Install it — five clicks How to tell it worked What these words mean Where it works Verify updates Schedule only after the manual test passes Troubleshooting

Using Codex, ChatGPT, or another assistant?

Use the public first-result prompt above now if your assistant can read the web. That tests the method, not a plugin installation. The Claude menus below are not universal.

Codex local setup

For a small local test, ask $skill-installer to install skills/evidence-verification from https://github.com/dennisyu/local-service-spotlight-skills. Review the source and destination before approving installation. Do not overwrite an existing skill or install duplicate names to fix a missing trigger. This single skill is not the full audit bundle.

Start a fresh task. In Codex CLI or the IDE extension, use /skills or $evidence-verification to select it. If it is absent, check the supported skill locations and whether it is disabled; restart if discovery is stale. See OpenAI’s local skill installation and enablement guide.

ChatGPT and group plugins

Use the supported Plugins directory and your workspace’s approved distribution path. Start a new chat after installation; ChatGPT uses @ to select a skill. Codex CLI uses /plugins to manage marketplace plugins and Space to switch an installed plugin on or off. Plugins are not supported in the Codex IDE extension.

This page does not claim that the Claude-format LSS bundle is already in every OpenAI account’s catalog. If no compatible approved package is offered, keep using the public-reference draft and have the workspace’s plugin function resolve distribution. See OpenAI’s plugin installation and permission guide.

Other assistants: use their supported source-reading and skill controls. If the assistant cannot open a URL, paste the relevant public text. Do not rename a missing capability as “installed,” import private memory to compensate, or grant broad access just to run this first test.

What Claude installation needs

A paid Claude plan. Plugins require a supported paid plan. Workspace settings, feature rollout, tool permissions, and whether work uses local files also affect what you can run. Check the linked product documentation if your interface differs.

Pro	A supported starting plan. Check feature availability and usage limits for your account.
Max	Higher usage capacity can help with longer jobs. It does not remove all limits or guarantee completion; test your workload before upgrading.
Team or Enterprise	Workspace policy applies. If required, an owner can enable Code execution and file creation and Skills in Organization settings. Missing options can reflect workspace policy or feature availability; send your admin the exact screen and this page.

Install it — five clicks

Open Claude on a computer and click Customize
In Cowork, open the Cowork tab first. Install from a supported computer surface. Phone use depends on the task and available tools.
Go to the Plugins tab
Open Browse → Personal → Add marketplace
In Claude, the full path is Customize → Plugins → Browse → Personal → Add marketplace. Menus can differ by account. If the marketplace is already listed, open it instead of adding a duplicate.
Paste this address and confirm
https://github.com/dennisyu/local-service-spotlight-skills
Click Install on lss-everything
The live marketplace manifest lists the current version and skills. Compare that list with the skill names your runtime can actually invoke; installed is not the same as invocable. Done — but not yet proven. Run the checks below.

Already installed the old name? First inventory your marketplaces, bundles, connected tools, and custom settings; save screenshots or an export and the prior accepted revision. Preserve the old known-good configuration. Confirm which exact LSS bundle is obsolete; an old label alone is not a migration plan. Review and test the current approved lss-everything bundle through supported controls without duplicate active versions. Only after that fresh installed-skill test passes and you confirm removal should you disable or remove the exact obsolete LSS bundle. Do not remove an entire uninspected marketplace. If the product requires removal first, pause and agree a recovery plan before changing anything.

Only want one area? Same address — pick a smaller bundle instead of lss-everything: authority and reputation, content engine, client operations, or quality and standards. Most people should take everything; the skills are written to hand work to each other.

Why did five plugin cards appear? One repository can list several bundle choices. Install lss-everything or selected topical bundles, not both. A plus means available; a gear means installed and manageable. See the screenshot guide to the five cards and GitHub permission screen.

On Team or Enterprise? Your owner may offer an optional, auto-installed, or required plugin. Shared plugins may remain off until you enable them. Check your own account; organization availability alone is not installation.

How to tell it worked

There are several checkpoints. Passing one does not prove the next one.

Installed
Customize → Plugins. The bundle should say Installed.
Enabled
Open the bundle and make sure the toggle is on.
Tested in a fresh Cowork task
Start a fresh Cowork task and type a real request — “harvest my positive mentions” or “run my weekly authority report.” Use the first-result prompt above with one audience and one package, then add: “This is an installed-skill test. Explicitly select the installed and enabled evidence-verification skill. Show evidence that it loaded in this fresh task and produce a fresh proof-to-offer brief. If it is unavailable, report BLOCKED; a public-reference draft does not pass this activation test.” Type / or use the + skill picker to select evidence-verification. Save the selection/load evidence and check the actual fresh output, not just the assistant saying it loaded a skill.
Update checked
Follow Check for updates below, then repeat the fresh Cowork task test. Record the version or synced commit if Claude shows it.
Receipt saved
For team rollouts, save the time, Claude surface, account or workspace, version if shown, and a screenshot or link to the result. That receipt is proof; an agent saying “everything looks great” is not.

Think of a kitchen: a plugin is the cookbook, a skill is one recipe, an agent is the cook, a scheduled job is the alarm telling the cook when to start, and the receipt is the photo of the finished dish. Owning the cookbook does not prove dinner was cooked.

Save a small acceptance receipt

Record: date and run ID; product, surface, and a private account alias; source commit or UNKNOWN; Installed and Enabled evidence; skill actually selected; output link; pass/fail checks; limits; and the next owner/action. Keep private account details out of public examples.

Available → Delivered → Installed → Enabled → Tested → Scheduled → Observed. Each state needs its own evidence. Observed means a real firing left an output or an unedited failure; it does not automatically mean success.

What these words mean

You do not need to memorise these. They show up in the Claude interface, so here they are in plain English.

SkillA written instruction sheet Claude follows — an SOP for one job. “Harvest my positive mentions.” “Run the weekly report.”

PluginThe box the skills ship in. Install one plugin, get every skill inside it.

AgentA worker carrying out a scoped task with skills and tools. You manage the goal, approvals, and result.

ReceiptA dated record of what actually ran, the result, its checks, and what failed or remains unknown.

Scheduled jobA saved instruction and clock for a worker. It still needs the right tools, approval, and a checked output.

In short: a skill is the instruction, a plugin is the box it ships in, an agent is the worker who uses it, and a scheduled job is the alarm that starts the worker.

Where it works

	Web	Desktop app	Phone
Installing the plugin	Yes	Yes	Use a computer
Running a skill	Yes	Yes	Yes
Configured cloud-compatible jobs	Where enabled	Where enabled	Where enabled
Local files, apps and connectors	Require an available desktop environment and approved access. Check the current surface and local-connection support for the exact task.

Cloud-compatible work can be available across supported surfaces. Local files, desktop apps, and local connectors require the authorized desktop environment.

Keep the work current

The canonical marketplace manifest owns the skill list. A file date or a number copied onto this page is not a release identity.

Compare the source with your environment
Record the accepted source commit and the version your account actually shows. If the UI does not reveal a commit, record that limit and keep the revision you tested; do not guess.
Already installed? Check for updates.
Open Customize → Plugins → Browse → Personal, choose local-service-spotlight-skills, then open its menu and select Check for updates. If Claude offers Sync automatically, turn it on if you want future releases. Follow your workspace’s policy if an administrator manages the pack.
Open Lss everything again. Make sure it is enabled. If an Update button is offered, apply the update and recheck. A downloaded ZIP will not update itself.
A new release is not proof that every member received it. Compare the current release with what your account shows. If Claude shows a synced commit, record it. If it does not, record “not shown.” Keep a known-good copy until your fresh test passes.
Local standalone skills need their own reviewed refresh; editing an installed cache is not the shared update route.
Run the same fresh-task test again
Select evidence-verification explicitly if needed. Check the proof-to-offer brief against the five pass criteria above, save the receipt, and keep the prior accepted revision for recovery.
For a team, prove one environment first
The existing update owner tests one canary before a wider rollout. A changed file, successful download, or passing source test does not prove the rest of the group received it.

Manual update verified and automatic update observed are different claims. Do not promise unattended updates without evidence from that exact surface. Our reviewed update and rollback contract defines the handoff; the acceptance checklist defines the proof.

One owner, not another clock. Before adding any update checker or job, check the team’s existing registry for the same source, destination, and cadence. Extend its owner and receipt checks instead of creating a competing schedule. Review this guide after a provider UI change or a failed first-use test; a dated review is not proof of a working account.

Schedule only after the manual test passes

An installed skill waits for a task. After a manual pass, you can approve a scheduled job with a clear output and owner. Use public sources and a saved draft report for the first rehearsal. Confirm the exact runtime and input locations before relying on local files or apps.

Install the skills first
For a skill-dependent job, first pass the installed-skill manual test: record the explicitly selected installed and enabled skill, fresh-task load evidence, and checked fresh output. A public-reference pass alone is not eligible. Check for an existing job with the same source and destination before creating one. The scheduled environment must have the required skills and tools.
Open the Cowork tab
Use the supported Cowork surface for your account and task. Cloud-compatible work and work needing local files or apps have different requirements.
Click Scheduled in the left sidebar, then New task
Top right. You can describe the job and let Claude set it up, or fill in the fields yourself: name, what it does, how often. No code either way.
Check the first real firing
After its scheduled time, open the saved report and confirm its run ID, timestamp, sources, checks, and next action. A failed firing is observed failure, not a successful result. Email, publication, and spending remain separate approval gates. A schedule sitting in the list only proves it was scheduled.
Add a missed-run alert
Decide who gets told when there is no receipt after the expected time plus a grace period. Silent non-runs are the failure people miss.

Check the actual runtime. Current Cowork guidance describes remote scheduled tasks and says they cannot be tied to a computer folder; the same guide retains local-task setup notes. Do not assume that leaving a laptop awake fixes every schedule. Confirm the supported mode in your account and use a public-source cloud-compatible rehearsal first.

Draft the schedule before you activate it:

“Draft, but do not activate, a weekly public-proof check for my business. Propose the timezone, owner, required skills, source URLs, output location, success checks, failure alert, and pause control. Keep it draft-only with no email, publishing, or spend.”

The rule that makes a scheduled job work. Do not rely on the setup conversation being present. Name the current source files and instructions explicitly, even when the product provides project knowledge or memory. Spell out who it is for, the exact skill, when it runs, where the result goes, what success looks like, and who gets alerted if the output is missing. A vague weekly-report request cannot be audited. A draft contract can: use the named skill and public sources, write to the approved report location, record the run ID, timezone and next expected firing, define a grace period, and name the function that checks a missing receipt. Activate only after its scope and approval mode are accepted.

Scheduled is not the same as working. Call it Scheduled when the definition exists. Call it Observed only after a firing leaves a timestamped result or an unedited error.

Agents are the same idea without the clock — a named worker you hand a whole job to, rather than chatting step by step. Installing this skill bundle supplies methods. Configure any named agent or recurring job separately using your runtime’s supported controls, then verify its output.

Troubleshooting

What you are seeing	What to do
Plugins says I need to upgrade	Check your plan, workspace permissions, and feature availability. Paid plans have different usage limits; an upgrade is not a guarantee that a long job will finish.
I cannot find “Add from a repository”	Open Customize → Plugins → Browse → Personal → Add marketplace. Menus can differ by account. Use the repository option shown, or ask your workspace administrator if it is unavailable.
No Customize in my sidebar	Try a supported computer surface and check your account availability. Local-file tasks still need the desktop environment.
The Skills or Plugins option is missing or greyed out	Ask your workspace owner to check plan availability, plugin policy, the relevant capability, and whether the item is offered or enabled for your group. Include the exact screen; missing controls have more than one cause.
It is installed but Claude ignores it	Check the toggle is on. Then start a fresh Cowork task — an existing conversation will not pick up a plugin added mid-way.
Codex says the model requires a newer version	This is a runtime compatibility failure, not evidence that the skill is broken. Check `codex --version` and which application or executable actually started the task. An already-installed current desktop app may include a newer supported runtime. Use the supported current runtime, or have its owner update it through the official installation path, then repeat the same fresh installed-skill test. Preserve the failed receipt. Do not delete the skill, change the model to hide the error, reset credentials, or bypass approval rules. A successful download is still not a successful run.
I installed it, now what?	Start a fresh Cowork task and describe the job in plain language. Use the first-result prompt and its pass criteria. If the relevant skill does not activate, select it explicitly with `/` or the + skill picker. If it is not listed, report the missing capability instead of pretending it ran.
My teammate has a newer version	Use the Check for updates steps, then test in a fresh Cowork task. Do not assume a release reached you until that test passes.
The scheduled job exists but no report arrived	Treat that as a failed run, not a healthy schedule. Check the scheduler’s last-attempt time and error, and the expected output destination. Escalate with the run ID and timestamps.
I have an old ZIP from you	A ZIP is a dated snapshot. Keep a rollback copy if needed; install from the current marketplace and verify updates in a fresh Cowork task.

Still stuck?

Reply in the workshop or Basecamp thread where you received this guide. Include your product and surface, the step, the exact error, the expected result, and a redacted screenshot or output link. The member-support function can route the issue without asking you for passwords. A fix may need more than one reply.

Capability distinctions rechecked against official documentation, 5 September 2026; your account still needs its own activation test — Use plugins in Claude, Schedule recurring tasks in Cowork, Cowork on web, desktop and mobile. Claude’s menus change occasionally — if something here does not match what you see, tell us and include your Claude surface and plan.

Installation loads the methods; it does not move everything else. Read the plugin explainer for packaging, the Claude–ChatGPT/Codex–Grok map for runtime differences, and the shared-memory guide for model-independent context. Connectors, permissions, agents, and schedules still belong to each runtime.