agentsclimarketplace
Sign in

Aiops service operations

Skill LinLin00000000/aiops-vault-template/skills/aiops-service-operations

Use this skill with aiops-vault when the user asks an agent to deploy, inspect, restart, monitor, troubleshoot, migrate, back up, or expose a small self-hosted service. It provides a portable operations workflow for Docker Compose, systemd, reverse proxies, service cards, backup checks, and consumer-side validation without duplicating the user's private inventory.From its SKILL.md

Install
npx -y skills add LinLin00000000/aiops-vault-template --skill aiops-service-operations

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.0 KB, 574 tokens by cl100k_base, as published. Nobody here has run it

AIOps Service Operations

This optional skill complements aiops-vault. It describes the operations workflow after the vault has supplied current facts.

Scope

Use for small services and agent-operated infrastructure:

  • Docker Compose projects.
  • systemd services.
  • reverse proxy routes.
  • service data directories.
  • backup/restore checks.
  • health checks and log triage.
  • service-card updates.

Do not store service facts in this skill. Use the AIOps vault and live inspection.

Operation workflow

  1. Load aiops-vault first when available.
  2. Identify the target service and host through aiops.py service <name> or resources --section.
  3. Read the service card or project README if present.
  4. Inspect runtime state safely:
    • Docker: docker ps, docker compose ps, docker compose logs --tail.
    • systemd: systemctl status, journalctl --since, systemctl cat.
    • HTTP: curl -I or a real health endpoint.
    • proxy: read route config without printing secrets.
  5. Separate desired change from risky side effects.
  6. Execute the smallest reversible step.
  7. Verify from the consumer side, not just the process side.
  8. Update current docs and append a maintenance-log entry.

Deployment defaults

For small cloud-hosted services, prefer:

  • deployment files under /opt/<service>/;
  • persistent data under /data/<service>/;
  • app ports bound to 127.0.0.1 behind Caddy/Nginx when public HTTPS is needed;
  • SSH/admin access on a private network when possible;
  • explicit backup and restore notes before trusting a service with important data.

Adjust these defaults to the user's platform and existing conventions.

Troubleshooting lens

Classify failures by layer:

  1. DNS / client route.
  2. reverse proxy.
  3. app listener / container / systemd unit.
  4. upstream API/provider.
  5. storage / permissions / disk.
  6. authentication / secret location.

Use logs and real probes to distinguish layers. Do not guess from the service name.

Documentation write-back

  • If host, URL, port, runtime, config path, data path, backup boundary, security boundary, or status changed: update resources.md or the service card.
  • If local runbook details changed: update the service card or service README.
  • If the event matters for future recovery: append maintenance-log.jsonl.
  • If a secret moved: update secrets-location.md with location metadata only.

Final report shape

End with:

  • target and resource pool;
  • files changed;
  • commands run and important output summaries;
  • verification result;
  • maintenance-log entry status;
  • follow-ups or blockers.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most operations skills give in 574 tokens

Counted across 483 of the 484 authors here whose files we hold, read 2026-08-07

  • Collect monitoring data throughout the simulationin 14 of 483, across 6 files
  • Set the random seed for reproducibilityin 14 of 483, across 6 files
  • Validate simulations against analytical solutionsin 12 of 483, across 4 files
  • Clarify goals, constraints, and inputsin 11 of 483, across 2 files
  • Implement contract tests for integration pointsin 11 of 483, across 2 files
  • Implement strangler fig infrastructure with API gatewayin 11 of 483, across 2 files
  • Audit modernized components for security vulnerabilitiesin 11 of 483, across 2 files
  • Avoid Python blocking calls in processesin 10 of 483, across 3 files
  • Use resource context managers for automatic cleanupin 9 of 483, across 2 files
  • Maintain consistent time unitsin 9 of 483, across 2 files
  • Validate outcomes against success criteriain 8 of 483, across 1 file
  • Analyze the legacy codebase for technical debtin 8 of 483, across 1 file

Said here and by no other author read

  • load the vault first
  • identify the target service and host
  • inspect runtime state safely
  • read route config without printing secrets
  • execute the smallest reversible step
  • verify from the consumer side

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.