Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/darkroomengineering/cc-settings/lighthousenpx skills add darkroomengineering/cc-settings --skill lighthousegit clone --depth 1 https://github.com/darkroomengineering/cc-settingsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00061 | $0.03540 |
| Opus 5 | $0.00030 | $0.01770 |
| Sonnet 5 | $0.00012 | $0.00708 |
| Haiku 4.5 | $0.00006 | $0.00354 |
Grade A, and why
lighthouse scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 375 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Lighthouse Optimization Loop
Set a product-neutral scratch root once:
LIGHTHOUSE_DIR="${TMPDIR:-/tmp}/cc-settings-lighthouse"
mkdir -p "$LIGHTHOUSE_DIR"
Use the Chrome DevTools MCP only when the user configured it. Standalone Codex otherwise uses the Lighthouse CLI plus native/manual screenshots; if no visual capture path exists, stop before changing UI and report that visual regression verification is unavailable. This package does not auto-run unpinned registry MCP packages.
Method: 3 mobile + 3 desktop runs per audit, averaged for reliability. After each code change, re-audit and visually verify the page with the configured MCP or the stated manual fallback.
Setup
-
Parse URL from
$ARGUMENTS. If no URL, ask the user. Default:http://localhost:3000 -
Verify prerequisites:
lighthouse --version # CLI must be installed for the batched 3x3 protocolIf lighthouse is missing:
npm install -g lighthouseIf runs fail with a chrome-launcher error or every metric comes backNO_LCP/null, no system Chrome exists — find a real Chrome/Chromium binary (Chrome for Testing, Playwright'schromium-*— NOTchrome-headless-shell, which produces NO_LCP) and exportCHROME_PATH=<binary>before the loop. Record which binary was used; a before/after comparison is only clean when both sides ran the same binary. Check whether the user configured the chrome-devtools MCP. Do not install or auto-run an unpinned registry MCP on their behalf. -
Create results directory:
mkdir -p "$LIGHTHOUSE_DIR" -
Take baseline screenshots before any changes:
mcp__chrome-devtools__navigate_page(type: "url", url:<url>)mcp__chrome-devtools__take_screenshot
Describe the current layout, key elements, and visual state. This is your visual baseline — you will compare against it after every change to catch regressions.
-
Confirm with user: Show the URL, confirm the dev server is running, ask if there are specific pages or routes to audit beyond the main URL.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 375 lines · 61 tokens per session scan A b3ee54ea7557
lighthouse is a skill published in the GitHub repository darkroomengineering/cc-settings (42 stars, last pushed 4d ago), licensed MIT. It adds 61 tokens to every session and 3,540 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
dotfiles-bootstrap
Bootstrap a workstation with the dotfiles framework. Takes a GitHub user / owner+repo / explicit clone URL and runs dot init (which shells out to chezmoi) with the right safety prompts. Honors the active agent profile (ask / plan / apply / audit) so it defaults to dry-run in safer modes and full apply in apply.
astro-dso-doc
Generates a complete, polished HTML documentation page, a processing checklist, an AstroBin post JSON, a PixInsight process icon set (XPSM), AND a ready-to-paste PixInsight project Description field for a deep-sky object (DSO) astrophotography project. Use this skill whenever the user mentions astrophotography, a DSO…
document-code
Apply Google Style documentation standards to Python, Go, TypeScript, and Terraform code. Use when writing or reviewing code that needs docstrings/comments/JSDoc, when asked to "document this code", "add docstrings", "follow Google Style", or when improving code documentation quality. Supports Python docstrings, Go…
work-on-ticket
Fetches Jira ticket details, creates an appropriately named branch, and initiates the task planning workflow. Use when the user says "work on [TICKETID]" or similar phrases.
datadog
Use this skill when you need to search Datadog logs, query metrics, tail logs in real-time, trace distributed requests, investigate errors, compare time periods, find log patterns, check service health, or export observability data.
document-project
Generate comprehensive, professional project documentation structures including README, ARCHITECTURE, USERGUIDE, DEVELOPERGUIDE, and CONTRIBUTING files. Use when the user requests project documentation creation, asks to "document a project", needs standard documentation files, or wants to set up docs for a new…