Linux & service basics

Diagnoses common Linux service issues using logs, systemd/PM2, file permissions, Nginx reverse proxy checks, and DNS sanity checks. Use when a server app is failing, unreachable, or misconfigured.

Security Scan

The skill's requirements, instructions, and scope align with a Linux service-triage helper; it is instruction-only, requests no credentials, and explicitly requires user approval before making changes.

Purpose & Capability

Name/description describe triage for systemd/PM2, Nginx, permissions and DNS; SKILL.md and references only use commands and paths relevant to that purpose and request no unrelated credentials or binaries.

Instruction Scope

Instructions remain within triage scope (gather logs, classify, propose fixes). The skill may provide exact shell commands but explicitly requires user approval before applying them and instructs to stop when privileged access is needed. This is appropriate, but users must not approve commands blindly because suggested commands could be destructive (chown/chmod/systemctl reload/etc.).

Install Mechanism

Instruction-only skill with no install spec and no code files — nothing is written to disk or downloaded during install.

Credentials

No environment variables, credentials, or config paths are requested. The SKILL.md references only service logs, common system paths, and user-provided snippets which are proportional to the stated functionality.

Persistence & Privilege

always is false and the skill does not request elevated privileges. Model invocation is allowed (default), so the agent could propose commands autonomously; however SKILL.md requires explicit user approval before executing changes. Users should ensure they review and approve any commands manually.

Assessment

This skill appears coherent for diagnosing Linux services, but exercise caution before approving any exact shell commands it proposes. Always: 1) Provide logs/output rather than granting shell access; 2) Review suggested chown/chmod/systemctl/nginx commands line-by-line and refuse any you don't understand; 3) Do not share secrets or private keys in pasted inputs; 4) Ask the assistant to produce a read-only diagnosis first, then request changes only when you or an authorized admin will run them; 5) Prefer testing fixes on a staging host or snapshot before applying to production.

Linux & service basics: logs, systemd/PM2, permissions, Nginx reverse proxy, DNS checks

PURPOSE

Diagnoses common Linux service issues using logs, systemd/PM2, file permissions, Nginx reverse proxy checks, and DNS sanity checks.

WHEN TO USE

• TRIGGERS:
  • Show me why this service is failing using logs, then give the exact fix commands.
  • Restart this app cleanly and confirm it is listening on the right port.
  • Fix the permissions on this folder so the service can read and write safely.
  • Set up Nginx reverse proxy for this port and verify DNS and TLS are sane.
  • Create a systemd service for this script and make it survive reboots.
• DO NOT USE WHEN…
  • You need kernel debugging or deep performance profiling.
  • You want to exploit systems or bypass access controls.

INPUTS

• REQUIRED:
  • Service type: systemd unit name or PM2 process name.
  • Observed symptom: error message, status output, or logs (pasted by user).
• OPTIONAL:
  • Nginx config snippet, domain name, expected upstream port.
  • Filesystem paths used by the service.
• EXAMPLES:
  • systemctl status myapp output + journalctl excerpt
  • Nginx server block + domain + upstream port

OUTPUTS

• Default: triage report (likely cause, evidence from logs, minimal fix plan).
• If explicitly requested and safe: exact shell commands to apply the fix. Success = service runs, listens on expected port, and reverse proxy/DNS path is correct.

WORKFLOW

1. Confirm scope and safety:
   • identify service name and whether changes are permitted.
2. Gather evidence:
   • status output + recent logs (see references/triage-commands.md).
3. Classify failure:
   • config error, dependency missing, permission denied, port conflict, upstream unreachable, DNS mismatch.
4. Propose minimal fix + verification steps.
5. Validate network path (if web service):
   • app listens → Nginx proxies → DNS resolves → (TLS sanity if applicable).
6. Provide restart/reload plan and confirm health checks.
7. STOP AND ASK THE USER if:
   • logs/status output are missing,
   • actions require privileged access not confirmed,
   • TLS/cert management is required but setup is unknown.

OUTPUT FORMAT

TRIAGE REPORT
- Symptom:
- Evidence (what you provided):
- Most likely cause:
- Fix plan (minimal steps):
- Exact commands (ONLY if user approved changes):
- Verification:
- Rollback:

SAFETY & EDGE CASES

• Read-only by default: diagnose from provided outputs; do not assume you can run commands.
• Avoid destructive changes; require explicit confirmation for anything risky.
• Prefer nginx -t before reload and verify ports with ss.

EXAMPLES

• Input: “journal shows permission denied on /var/app/uploads.”
  Output: path permission analysis + safe chown/chmod plan + verification.

• Input: “App works locally but domain returns 502.”
  Output: upstream port checks + nginx error log interpretation + proxy_pass fix plan.