Give ops some ops-y skills #772

New issue

Open

opened 2026-08-14 04:38:17 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-08-14 04:38:17 +00:00

Owner

https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/src/branch/main/agent/rendered/roles/ops.bundle.txt

but ones it could actually use, and ones that are public safe. probably the entire deck/infra and bridge/deploy repos are useless??? unless... signoz skills perhaps???

Resolved spec (design pass, 2026-08-15)

Decision - ops gets two skill families, not four. Kai's doubt about deck/infra and bridge/deploy is upheld, and those stay out.

SigNoz observability - query traces, logs, and metrics for the agents' own behaviour. This is the one the ticket already suspected, and it is public-safe.
Forgejo issue operations - list, read, comment, and label issues so ops can work its own queue. Already a live MCP, so no new grant shape is invented here.

Out

Node-stats host and k3s diagnostics - declined for this issue. Host shape is not something the ops bundle should carry by default.
deck/infra and bridge/deploy repo skills - declined, as the ticket suspected.

Build

Add the SigNoz and Forgejo skill sources to the ops role bundle at agent/rendered/roles/ops.bundle.txt, through whatever authoring path renders that file. Do not hand-edit the rendered artifact.
Confirm each added skill is public-safe by the repo's own definition before it lands - no host identifiers, no opaque ids, no private overlay content.

Acceptance

The rendered ops bundle contains the SigNoz and Forgejo skill anchors and no node-stats, deck/infra, or bridge/deploy content.
The skill additions grant no new credentials by themselves. Any grant change is a separate bridge/deploy ticket, cross-linked from here.
Ops can answer "why did that turn fail" from SigNoz and "what is on my queue" from Forgejo without a further skill addition.

Note - skills are doctrine and knowledge only. If ops cannot reach SigNoz or Forgejo at runtime today, that is a grant gap and needs its own move-to-repo/coilyco-bridge-deploy issue rather than being absorbed here.

https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/src/branch/main/agent/rendered/roles/ops.bundle.txt but ones it could actually use, and ones that are public safe. probably the entire deck/infra and bridge/deploy repos are useless??? unless... signoz skills perhaps??? --- ## Resolved spec (design pass, 2026-08-15) **Decision** - ops gets two skill families, not four. Kai's doubt about deck/infra and bridge/deploy is upheld, and those stay out. **In** * **SigNoz observability** - query traces, logs, and metrics for the agents' own behaviour. This is the one the ticket already suspected, and it is public-safe. * **Forgejo issue operations** - list, read, comment, and label issues so ops can work its own queue. Already a live MCP, so no new grant shape is invented here. **Out** * Node-stats host and k3s diagnostics - declined for this issue. Host shape is not something the ops bundle should carry by default. * deck/infra and bridge/deploy repo skills - declined, as the ticket suspected. **Build** 1. Add the SigNoz and Forgejo skill sources to the ops role bundle at `agent/rendered/roles/ops.bundle.txt`, through whatever authoring path renders that file. Do not hand-edit the rendered artifact. 2. Confirm each added skill is public-safe by the repo's own definition before it lands - no host identifiers, no opaque ids, no private overlay content. **Acceptance** * The rendered ops bundle contains the SigNoz and Forgejo skill anchors and no node-stats, deck/infra, or bridge/deploy content. * The skill additions grant no new credentials by themselves. Any grant change is a separate bridge/deploy ticket, cross-linked from here. * Ops can answer "why did that turn fail" from SigNoz and "what is on my queue" from Forgejo without a further skill addition. **Note** - skills are doctrine and knowledge only. If ops cannot reach SigNoz or Forgejo at runtime today, that is a grant gap and needs its own `move-to-repo/coilyco-bridge-deploy` issue rather than being absorbed here.