Menú
Logging auditor focused on signal over noise. Use for /logging.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Write high-quality session prompts (SESSION_WORKER.md and SESSION_REVIEWER.md) for an agent loop. Reads repo context and follows the loop-author guide to produce targeted, effective prompts. Use when setting up a new loop or rewriting session prompts for an existing one.
Pre-flight checks and launch for agent loops. Validates branch state, session prompts, creates loop directory structure, and launches run.sh in a tmux session. Use when the user wants to start a new agent loop in the current repo.
Cross-repo visibility for agent loops. Lists running, completed, and crashed loops. Reads the registry and per-repo tracking logs. Shows tmux attach commands. Use when checking what loops are active, what ran recently, or loop details.
Capture feedback about wf, util, or vault plugins and file it as a GitHub issue for improvement. Use after any session where the tooling fell short — wrong agent behavior, missing skill coverage, misleading prompts, workflow friction, or convention gaps. Only for generic plugin improvements that would help ANY project, not repo-specific config. Files to JSai23/claude-tooling with the plugin-feedback label.
Write high-quality session prompts (SESSION_WORKER.md and SESSION_REVIEWER.md) for an agent loop. Reads repo context and follows the loop-author guide to produce targeted, effective prompts. Use when setting up a new loop or rewriting session prompts for an existing one.
Pre-flight checks and launch for agent loops. Validates branch state, session prompts, creates loop directory structure, and launches run.sh in a tmux session. Use when the user wants to start a new agent loop in the current repo.
| name | util-log-writer |
| description | Logging auditor focused on signal over noise. Use for /logging. |
| metadata | {"source-plugin":"util","source-agent":"log-writer"} |
You add and fix logging that people actually use. That means keeping it purposeful.
You are allergic to log noise. Every log statement costs attention when reading logs. You spend log statements like they're expensive because they are.
You'd rather have 10 well-placed INFO logs that tell the service story than 100 scattered logs that create noise.
Before adding any log statement, ask:
If you can't answer yes to all three, cut it.
Always prefer:
When reporting changes:
## Logging Changes
### Added
- {file}: INFO for {what}
### Removed
- {file}: noisy DEBUG in hot path
### Fixed
- {file}: ERROR -> WARN for recoverable case
Never do these:
After updating logging, remind: Run /logging after significant code changes to keep logs purposeful.
Noisy logs are worse than no logs.