菜单
Tail or follow cortex service logs from Docker Compose. Use when the user asks for cortex service logs, startup logs, crash logs, plugin deployment logs, Docker logs, or follow mode. This is for the service's stdout/stderr, not client syslog entries.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
This skill should be used when the user asks for a homelab health report, syslog summary, fleet status report, log analysis summary, 'what happened in the last 24 hours', 'show me this week's errors', 'summarize recent activity', or any time-bounded log analysis that should produce a written markdown report.
This skill should be used when the user asks to "search logs", "check errors", "tail logs", "show recent logs", "find log entries", "correlate events", "list hosts", "log stats", "syslog", "check homelab logs", or mentions system logs, syslog, log analysis, or log intelligence across homelab hosts.
Re-run the cortex plugin setup hook with the current userConfig and verify the Docker Compose deployment. Use when the user asks to redeploy cortex, apply plugin config changes immediately, rerun the setup hook, refresh the Docker deployment, or recover after an automated SessionStart/ConfigChange hook did not run.
Deploy rsyslog forwarding drop-ins to configured fleet hosts over SSH. Use when configuring fleet forwarding, repairing missing rsyslog forwarding, or updating forwarding after server_url or syslog port changes.
Run a comprehensive cortex health check covering environment, config quality, storage, ports, service status, HTTP health, MCP actions, listener reachability, Docker ingest, and fleet rsyslog forwarding. Use when the user asks for syslog doctor, deployment diagnostics, first-run preflight, health check, sanity check, or broad deployment verification.
This skill should be used after running cortex action=abuse_investigate to analyze the resulting evidence bundle. Use when the user asks to assess frustration incidents, evaluate abuse signals, analyze agent or user friction, produce a frustration report, or follow up on abuse_investigate results.
| name | cortex-logs |
| description | Tail or follow cortex service logs from Docker Compose. Use when the user asks for cortex service logs, startup logs, crash logs, plugin deployment logs, Docker logs, or follow mode. This is for the service's stdout/stderr, not client syslog entries. |
Show recent cortex service logs. These are the binary's stdout/stderr, not syslog entries received from clients. Use the cortex MCP tool with action=tail for received log entries.
Check server mode:
echo "$CLAUDE_PLUGIN_OPTION_IS_SERVER"
If false, explain that the local plugin is in client mode and has no local service logs to tail.
Parse user arguments:
100: that many lines, no follow--follow or -f: last 50 lines, then streamRun Docker Compose logs:
CORTEX_HOME="${CORTEX_HOME:-$HOME/.cortex}"
docker compose --env-file "${CORTEX_HOME}/.env" -f "${CORTEX_HOME}/compose/docker-compose.yml" logs cortex --tail <N> --no-color
For follow mode, add -f and omit --no-color.
If the plugin compose project has no container, report that Docker mode is configured but no plugin-managed container is running. Do not guess a source checkout path.
Show the captured logs directly. If follow mode is active, the streaming output is the deliverable until the user interrupts.
If the logs show obvious unhealthy patterns such as repeated restarts, panics, bind errors, or DB lock errors, summarize the pattern after the log excerpt and suggest cortex-dr for full diagnostics.