AI Skills (Claude Code & Codex)
Log Lens ships reusable issue-resolution skills inside the engine, in
skills/:
skills/claude- skill namelog-lens-issues-claudeskills/codex- skill namelog-lens-issues-codex
They come with the download: skills/ sits at the root of a standalone install,
and at vendor/cliqthemes/log-lens-core/skills/ when Log Lens is installed with
Composer (including the Laravel adapter, which depends on the engine).
They treat Log Lens as the evidence source and workflow ledger, and the editor's current repository as the application to fix - carrying a request through discovery, diagnosis, code change, validation, and status update.
Install (user scope - recommended)
Symlink the skill into the tool's user-scope skills directory so it's available in every workspace:
# LOG_LENS is wherever the engine lives: your standalone install, or
# vendor/cliqthemes/log-lens-core inside a Composer project.
LOG_LENS=/absolute/path/to/log-lens
# Codex
mkdir -p "$HOME/.agents/skills"
ln -s "$LOG_LENS/skills/codex" "$HOME/.agents/skills/log-lens-issues-codex"
# Claude Code
mkdir -p "$HOME/.claude/skills"
ln -s "$LOG_LENS/skills/claude" "$HOME/.claude/skills/log-lens-issues-claude"
A symlink into vendor/ is replaced on the next composer update, which is
fine - the target path stays the same. Copy the directory instead if you'd
rather pin a version.
How the skill finds Log Lens
It resolves the base URL in order: the core config
(config.php to LOG_LENS_URL), then the LOG_LENS_URL env var,
then user context, then a probe of the configured default, then asks. If an
API key is configured, it reads LOG_LENS_TOKEN (env) or auth.token
(config) and sends X-Log-Lens-Token on every request. All log content stays
local - the skill never sends stacks, context, or credentials to external
services.
Usage examples
Use $log-lens-issues-claude to investigate issue 15, fix it, run tests, and update its status.
Use $log-lens-issues-codex to fix the top 3 unresolved issues by occurrence count.
Use $log-lens-issues-claude to work through every issue from 21 July 2026 one by one.
What it does per issue
Builds and paginates a queue via the lean errors endpoint; investigates one
issue at a time (requesting stack/context/raw evidence only when useful); maps
production release paths to the local checkout; marks the current issue
in_progress; implements the smallest complete fix with regression coverage;
validates; then marks fixed with an auditable note (cause / fix / validation).
It never marks fixed from a diff alone, and uses wont_fix only when policy
explicitly accepts the behavior. A future matching import flips fixed to reoccurred automatically.