菜单
Use when sending a notification to ntfy from a homelab service, loop, or agent. Covers the canonical in-cluster publish pattern and the silent-failure trap of posting to the Authentik-gated public URL.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when asked to document work, record decisions, create session records, write ADRs or RFCs, or update knowledge notes in ~/knowledge. Also use when confused about who a person is, what a company is, what situation the user is referring to, or any personal or professional context — read the vault before asking.
Use when creating or editing notes in an Obsidian vault, writing to ~/knowledge, or using Obsidian-specific syntax (wikilinks, callouts, embeds, frontmatter properties).
Use when reviewing any implementation. Replaces fixed spec+quality two-step with category-driven parallel specialists: an assessor picks relevant categories for the specific artifact, one specialist per category reviews in parallel, controller aggregates. Use after implementer completes a task in subagent-driven-development.
Use when dispatching work to background agents, defining custom subagents, or choosing between local agent dispatch and VM-based workers (claude-ctl).
Use when working with Kubernetes clusters, GitOps deployments, Flux reconciliation, Helm releases, or cluster troubleshooting. Guides declarative cluster management and GitOps workflows. Not for secrets encryption or SOPS operations — route those to secrets-management.
Use when encrypting secrets with SOPS/age, managing Kubernetes Secret manifests, rotating credentials, or setting up secret delivery (sops-nix, sealed secrets). Not for application code that reads env vars or auth tokens at runtime.
| name | ntfy-notifications |
| description | Use when sending a notification to ntfy from a homelab service, loop, or agent. Covers the canonical in-cluster publish pattern and the silent-failure trap of posting to the Authentik-gated public URL. |
| allowed-tools | Bash |
| injectable | true |
Publish notifications by POSTing to the in-cluster ntfy service. Never publish to the public URL — it is behind Authentik forward-auth and silently swallows POSTs.
You need network reach to the ntfy Service in the ntfy namespace. Any of the following works:
If you have a kubectl context for the homelab cluster you almost certainly also have network reach — those two travel together here.
Use this from any pod, any Alertmanager/incident-responder webhook, and any agent or loop running on a host that resolves cluster DNS.
curl -fsS -X POST \
-H "Title: <title>" \
-H "Tags: <tag>" \
-H "Priority: <prio>" \
-d "<body>" \
http://ntfy.ntfy.svc.cluster.local/<topic>
A successful publish returns a JSON body with an "id" field and exit 0.
Use only when the caller has cluster network reach but cannot resolve cluster DNS (e.g. a host cron job whose /etc/resolv.conf does not point at the cluster resolver).
curl -fsS -X POST \
-H "Title: <title>" \
-H "Tags: <tag>" \
-H "Priority: <prio>" \
-d "<body>" \
http://10.43.19.253/<topic>
The ClusterIP is not stable across Service recreation. Re-check with kubectl get svc -n ntfy ntfy if you suspect drift.
Reuse the existing topics. Do not invent new ones unless there is a clear reason — and if you do, add a one-line entry to this table in the same change.
| Topic | Used by |
|---|---|
homelab-improvements | improvement loop, DevEx Monitor |
homelab-alerts | Alertmanager, incident-responder |
| Header | Values used in this repo |
|---|---|
Title | Short human-readable subject |
Tags | Emoji shortcodes — wrench, white_check_mark, warning, etc. |
Priority | min, default, high |
Do not POST to https://ntfy.sammasak.dev/<topic>. The public URL is fronted by Traefik with the authentik-authentik-forward-auth@kubernetescrd middleware (Pattern A). An unauthenticated POST is 302-redirected to /outpost.goauthentik.io/start?..., curl reports exit 0, and the message is silently dropped. The public hostname is for subscribing (mobile app, browser) — not publishing. (Source: ~/homelab-improvement-loop/loop.log, May 2026, four consecutive passes lost notifications this way.)
Prefer the DNS form over the ClusterIP. 10.43.19.253 is the ClusterIP at the time of writing but is not stable across Service recreation. Re-check with kubectl get svc -n ntfy ntfy if a fallback is needed.
Use curl -fsS, not curl -s. -s swallows errors and the 302 above will look like success. -f makes non-2xx responses produce a non-zero exit so the failure surfaces.
kubectl get svc -n ntfy ntfy
# expect: a ClusterIP set on port 80, type ClusterIP
curl -fsS -X POST -H "Title: skill verify" -d "ok" \
http://ntfy.ntfy.svc.cluster.local/homelab-improvements
# expect: JSON body containing "id", exit 0