- Introduced `inspect-shz-logs` skill for inspecting local and production logs with bounded read-only commands. - Added `view.sh` script for log viewing with options for following logs and filtering by keywords. - Created `query-shz-highgo` skill for querying the SHZ HighGo database through an SSH gateway. - Implemented read-only SQL execution with strict controls on allowed statements and query structure. - Added new domain and mapper classes for managing outdoor fair job associations. - Enhanced `OutdoorFairController` to support job listing and management for outdoor fairs. - Created SQL scripts for initializing outdoor fair job data and managing menu visibility.
2.1 KiB
name, description
| name | description |
|---|---|
| inspect-shz-logs | Inspect and follow the SHZ backend's local and production logs through bounded, read-only commands. Use when Claude Code is working in the shz-backend project and needs to diagnose startup failures, exceptions, request behavior, scheduled jobs, or runtime incidents from local backend.log or the production backend, error, info, and user logs on the shz server. |
Inspect SHZ Logs
Use the bundled script instead of assembling SSH commands manually. Keep every initial read bounded; follow logs only when the user explicitly asks to monitor live activity.
Inspect local logs
Read the last 200 lines:
.claude/skills/inspect-shz-logs/scripts/view.sh local 200
Follow the local log interactively:
.claude/skills/inspect-shz-logs/scripts/view.sh local 200 --follow
Inspect production logs
Read the main application log:
.claude/skills/inspect-shz-logs/scripts/view.sh online backend 200
Read the current error log:
.claude/skills/inspect-shz-logs/scripts/view.sh online error 200
Choose only one production log type: backend, error, info, or user. Add --follow as the final argument only for an explicit live-monitoring request.
For keyword analysis, fetch a bounded window and filter locally, for example:
.claude/skills/inspect-shz-logs/scripts/view.sh online error 1000 | rg -i 'exception|error|failed'
Diagnose from logs
- Establish whether the request concerns local or production behavior.
- Read 100–300 recent lines from the relevant log.
- Expand up to the script's 5,000-line cap only when timestamps or stack traces require more context.
- Correlate timestamps, thread names, exception causes, and nearby requests.
- Report the evidence and likely cause without exposing tokens, passwords, personal data, or unrelated log content.
Treat production access as read-only. Never restart services, edit files, deploy code, truncate logs, or run arbitrary remote commands through this skill.
Read references/log-locations.md only when checking server identity, paths, or supported log types.