Light
Add observability, logging, documentation, or explanation to dark areas of a system.
Overview
Light is interpreted here as a hybrid spell with a shipping-now execution model.
Canonical source: Light (spell)
Provider target: OpenClaw
When To Use
- A process runs with no logging, metrics, or visibility into its internal state.
- A codebase or system has undocumented areas that block understanding.
- You need to add explanation, annotation, or observability to something opaque.
- You have smart lights connected via Home Assistant and want to control them with natural language.
Workflow
- Give 3 to 6 steps.
- the dark area
- the chosen artifact
- where it should live
- how to read it
- freshness qualification if relevant
- If relevant, include an exact artifact example:
- a structured log line
Deliverables
- List the concrete artifact(s) created.
- Name where operators check them.
- Include what remains dark exactly.
- For logging tasks, say structured log line explicitly.
- For documentation tasks, say runbook note, README paragraph, or stdout line explicitly.
- For status tasks, say status note, heartbeat, or metric explicitly.
Guardrails
- Keep this section visible and explicit.
- It must say that Light illuminates and does not judge.
- It must say observation must stay within authorized surfaces.
- It must include one sentence about false positive.
- It must include one sentence about false negative.
- It must include one sentence about stale, timestamp, last seen, or privacy.
- It must reject over-instrumentation, unsolicited refactors, covert monitoring, and root-cause overclaiming.
- Useful guardrail patterns:
- A false positive here would be...
- A false negative remains possible if...
Default Invocation
Use $light to illuminate this area with the minimum logging, docs, or observability it needs.
1---2name: light3description: Use this cantrip when a system, process, or codebase has blind spots that need illumination - not detection of hidden things, but creation of visibility where none exists.4---56# Light78Add observability, logging, documentation, or explanation to dark areas of a system.910## Overview1112Light is interpreted here as a hybrid spell with a shipping-now execution model.1314Canonical source: Light (spell)1516Provider target: OpenClaw1718## When To Use1920- A process runs with no logging, metrics, or visibility into its internal state.21- A codebase or system has undocumented areas that block understanding.22- You need to add explanation, annotation, or observability to something opaque.23- You have smart lights connected via Home Assistant and want to control them with natural language.2425## Workflow26271. Give 3 to 6 steps.282. the dark area293. the chosen artifact304. where it should live315. how to read it326. freshness qualification if relevant337. If relevant, include an exact artifact example:348. a structured log line3536## Deliverables3738- List the concrete artifact(s) created.39- Name where operators check them.40- Include what remains dark exactly.41- For logging tasks, say structured log line explicitly.42- For documentation tasks, say runbook note, README paragraph, or stdout line explicitly.43- For status tasks, say status note, heartbeat, or metric explicitly.4445## Guardrails4647- Keep this section visible and explicit.48- It must say that Light illuminates and does not judge.49- It must say observation must stay within authorized surfaces.50- It must include one sentence about false positive.51- It must include one sentence about false negative.52- It must include one sentence about stale, timestamp, last seen, or privacy.53- It must reject over-instrumentation, unsolicited refactors, covert monitoring, and root-cause overclaiming.54- Useful guardrail patterns:55- A false positive here would be...56- A false negative remains possible if...5758## Default Invocation5960Use $light to illuminate this area with the minimum logging, docs, or observability it needs.61
Hmbown