feat(hermes): register using-synology-ops in mapping.yaml (auto/mcp)
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
# Task Board
|
||||
_Updated: 2026-05-12 (using-synology-ops-install 🟢 done — SHA256 match, skill visible in registry)_
|
||||
_Updated: 2026-05-12 (using-synology-ops-hermes-mapping 🟢 done — mapping.yaml + dist-hermes/mcp/using-synology-ops/)_
|
||||
|
||||
<!--
|
||||
Canonical layout. One block per task. Per-task deep context lives in
|
||||
@@ -783,18 +783,16 @@ The SKILL.md was committed locally to `~/projects/claude-skills/skills/using-syn
|
||||
|
||||
---
|
||||
|
||||
## ⚪ [using-synology-ops-hermes-mapping] — Register `using-synology-ops` in `~/projects/claude-skills/hermes/mapping.yaml` so the hermes-agent (chat-agent for non-CC environments) knows how to map intent to this skill.
|
||||
## 🟢 [using-synology-ops-hermes-mapping] — Register `using-synology-ops` in `~/projects/claude-skills/hermes/mapping.yaml` so the hermes-agent (chat-agent for non-CC environments) knows how to map intent to this skill.
|
||||
|
||||
Mode: `auto` — skill is purely behavioral (trigger-and-guidance for an MCP server), does not modify local environment or require permission grants.
|
||||
|
||||
**Status:** ready
|
||||
**Where I stopped:** (not started)
|
||||
**Next action:** 1. Edit `~/projects/claude-skills/hermes/mapping.yaml`, add entry for `using-synology-ops` with `mode: auto`, triggers copied/distilled from SKILL.md `description`.
|
||||
2. Run `python ~/projects/claude-skills/scripts/build-hermes.py` to regenerate dist.
|
||||
3. Verify `dist-hermes/` contains `using-synology-ops`.
|
||||
4. Commit locally in `claude-skills/`: `feat(hermes): register using-synology-ops in mapping.yaml`.
|
||||
**Status:** done
|
||||
**Where I stopped:** (done 2026-05-12) — mapping.yaml entry добавлен (mode:auto, category:mcp, без replace-rules — skill behavior одинаков на CC и Hermes). `build-hermes.py` → 25 skills processed (auto 14, manual 2, skip 9, pending 0). `dist-hermes/mcp/using-synology-ops/SKILL.md` присутствует, SHA256 совпадает с источником (passthrough без правил). NB: rebuild также вытащил unrelated LF→CRLF diff'ы у `using-projects-meta` + `project-bootstrap` dist'ов — это побочный эффект build-hermes.py под Windows (Python пишет system-newline). Эти diff'ы НЕ закоммичены этой таской — отдельная задача на `.gitattributes` (`*.md text eol=lf`).
|
||||
**Next action:** (none — kept until merged)
|
||||
**Branch:** n/a
|
||||
<!-- created-by: OpeItcLoc03@DESKTOP-NSEF0UK / from: OpeItcLoc03/workshop / 2026-05-12T16:21:51.686Z -->
|
||||
<!-- closed-by: OpeItcLoc03@DESKTOP-D53K5FB / 2026-05-12T16:35:00.000Z / note: mapping.yaml mode:auto category:mcp; build-hermes.py clean; dist-hermes/mcp/using-synology-ops/ SHA256 match -->
|
||||
|
||||
---
|
||||
|
||||
|
||||
33
dist-hermes/mcp/using-synology-ops/SKILL.md
Normal file
33
dist-hermes/mcp/using-synology-ops/SKILL.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
name: using-synology-ops
|
||||
version: 0.1.0
|
||||
description: Use when diagnosing docker containers on the Synology NAS — the `synology-ops` HTTP MCP server (https://opsmcp.kzntsv.site/mcp) exposes 4 read-only tools — `ops.docker.ps`, `ops.docker.logs`, `ops.docker.inspect`, `ops.docker.stats` — all routed through tecnativa `synology-docker-proxy-ro` with `POST=0` (write-ops return 403). Triggers on container names (`modulair-rag`, `modulair-pipeline`, `lightrag-modulair`, `tier1-converter`, `modulair-mcp`, `synology-ops-mcp`), on NAS-domain words ("на NAS", "Synology", "синолоджи", "Portainer-стек", "ops-mcp", "опс мсп", "opsmcp.kzntsv.site"), or on incident phrases ("падает", "restart-loop", "не стартует", "unhealthy", "посмотри логи") when NAS-context. Read-only by design — no per-session grant needed. Skip for non-incident container mentions, explicit "open Portainer GUI" requests, and write-operations (those go to Portainer manually).
|
||||
---
|
||||
|
||||
# using-synology-ops
|
||||
|
||||
Trigger-and-guidance skill для `synology-ops-mcp` — read-only HTTP MCP-сервера на NAS, дающего Claude'у видимость состояния docker-контейнеров без юзера-моста (без Portainer copy-paste). Тело каркаса дописывается во втором проходе из `~/projects/.workshop/.archive/2026-05-12-using-synology-ops-skill.md` (process trace) и `~/projects/.wiki/concepts/synology-ops-mcp-design.md` (canonical design).
|
||||
|
||||
## When to use
|
||||
|
||||
<пусто — заполняется во втором проходе>
|
||||
|
||||
## Inputs
|
||||
|
||||
<пусто>
|
||||
|
||||
## Steps
|
||||
|
||||
<пусто>
|
||||
|
||||
## Failure modes
|
||||
|
||||
<пусто>
|
||||
|
||||
## Side effects
|
||||
|
||||
<пусто>
|
||||
|
||||
## What NOT to do
|
||||
|
||||
<пусто>
|
||||
@@ -126,6 +126,10 @@ skills:
|
||||
mode: auto
|
||||
category: mcp
|
||||
|
||||
using-synology-ops:
|
||||
mode: auto
|
||||
category: mcp
|
||||
|
||||
project-bootstrap:
|
||||
mode: auto
|
||||
category: software-development
|
||||
|
||||
Reference in New Issue
Block a user