Skip to main content

AI Skills (Claude Code & Codex)

Log Lens ships reusable issue-resolution skills inside the engine, in skills/:

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.

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.