A routine SRE inspection process for general internet-facing systems: collect evidence with an auditable checklist, record conclusions, escalate anomalies, and issue a notice after recovery. It manages the process and deliverables of daily inspections; the specific diagnosis and safe termination of processes, tmux, and long-running task stalls are handled by soia-dev-terminal-ops is responsible for.
Customer-readable description
What this skill can do
Provide the inspection scope, target environment, service entry points, and existing observation channels; without explicit authorization, perform only read-only checks, and do not restart, scale, change configurations, or send external messages.
| The customer wants | The skill will do | The customer can see |
|---|---|---|
| Confirm daily whether the system is healthy | Execute check items one by one or indicate the reason they cannot be executed | Inspection records with time, evidence, and status |
| Sync promptly after discovering an anomaly | Generate a reporting draft based on impact, scope, known facts, and the next update time | A copyable anomaly report message |
| Close the loop after service recovery | Review key metrics, generate a recovery notice, and archive the day's results | Recovery notice draft and daily archive index |
How the customer uses it
Specify the inspection date/time zone, environment, service list, allowed read-only entry points, SLOs or thresholds, archive location, and message receiving channels. Natural language is acceptable, for example: "Perform today's daily check on the example production environment; read-only; record according to the team's archiving conventions; give me a draft first for anomalies."
When thresholds are missing, record the raw observed values and mark them as "pending determination"; do not fabricate a health baseline on your own. When restart, traffic switching, scaling, configuration changes, ticket submission, or external sending is involved, first present the impact and message draft and obtain explicit confirmation for this instance.
Dependencies and installation
Installation:
npx skills add soia-team/soia-open-dev-ts-skills -g -a '*' -s soia-dev-run-ops-inspection -y
Hard dependency: authorized observation entry points or verifiable operational evidence provided by the customer. Optional enhancements: metrics, logs, alerts, status pages, and change record systems; when any entry point is missing, mark the corresponding item as "not checked" and do not fill it in with guesses.
Configuration conventions:
~/.config/soia-skills/soia-dev-run-ops-inspection/config.yml
This skill can be used without configuration; when default checklists, thresholds, time zones, or archive root directories need to be saved, the customer can create this file themselves. Recommended structure:
schema_version: 2
timezone: "<IANA-timezone>"
archive_root: "<user-controlled-archive-root>"
checklist:
- id: availability
source: "<read-only-metric-or-status-source>"
threshold: "<customer-defined-threshold>"
Private information and intermediate data
- Only read operational evidence explicitly provided or authorized by the customer; do not read company knowledge bases, private documents, credential stores, or unrelated directories.
- Tokens, cookies, accounts, and internal addresses remain only in the user's login state or private configuration, and are never written into checklists, inspection records, message drafts, or receipts.
- Sampled screenshots, raw query results, and temporary excerpts are intermediate data and should be stored in a temporary location controlled by the customer; delivery records retain only the necessary aggregated values, times, and redacted evidence. The retention period is determined by the customer's archiving policy.
Logs and completion receipts
完成：<日期> 的 <环境> 日检已完成/部分完成。
日志摘要：
- checked: <通过/异常/未检查数量>
- evidence: <指标、日志、状态页或变更记录的摘要>
- incidents: <异常编号或“无”>
- archive: <归档日期与相对位置>
验证：<复核的检查项和实际证据>
问题与下一步：<待确认阈值、缺失权限或下一次更新时间；无则写“无”>
Inspection boundaries
This skill is responsible for: routine health check orchestration, checklist status, result recording, anomaly communication templates, recovery review, and daily archiving.
soia-dev-terminal-ops Responsibility: PID/tmux/background long-running task observation, multi-signal diagnosis of stalls, and the confirmation gate of TERM→review→KILL. When a daily check finds an abnormal task, this skill only hands off "process diagnosis needed" in the record; before invoking the latter, the required PID, observation window, and termination authorization must still be obtained. This skill does not replace its process recovery rules.
Workflow
- Create the run card for this session. Record the date, time zone, environment, service, on-call contact, authorization scope, checklist version, and archiving rules; distinguish facts provided by the client from items to be verified.
- Confirm the checklist and thresholds. Cover at least availability, error/failure rate, latency, capacity or resource headroom, critical dependencies, alerts, recent changes, and backup/task results (where applicable). For each item, note the data source, observation window, threshold, and owner; if not applicable, state the reason.
- Perform read-only checks. Collect timestamps and verifiable evidence item by item; the status can only be
通过、异常、未检查or待判定. A single sample is not equivalent to a trend; do not declare health without a threshold. - Cross-verify anomalies. For anomalies, re-verify with at least one independent piece of evidence, such as metrics and logs, status page and dependency health, alerts and recent changes. Record "what was seen," "what was inferred," and "what is unknown"; when verification is impossible, increase uncertainty rather than downgrade the issue.
- Determine and escalate. Decide whether to report based on the client-defined SLO, alert level, and scope of impact. If there are no escalation rules, immediately report the visible impact, affected scope, current evidence, and matters requiring a client decision, and do not arbitrarily define an incident level.
- Record recovery. After an anomaly recovers, re-check the triggering metric, critical user path, or dependency status, and compare before and after the anomaly. Use "recovered" only when the evidence shows recovery; otherwise write "mitigating" or "under continued observation."
- Archive daily. Under the client-controlled
archive_rootstore the day's records byYYYY/MM/YYYY-MM-DD/, using the filenameinspection-<environment>.md; before appending on the same day, first show the target and confirm the overwrite/merge strategy. If the client does not provide an archive location, deliver only copyable content and do not write to the current directory on your own.
Inspection checklist record contract
Every check item must have the following fields; "not checked" must not be written as "passed."
| Field | Requirement |
|---|---|
| Check item and scope | Service/dependency, environment, and user path or resource object |
| Time window | Time zone, sampling start and end times, and data delay (if known) |
| Evidence | Data source category, key values or redacted summary, query/observation time |
| Threshold and status | Client threshold or "not provided"; passed/anomalous/not checked/pending determination |
| Conclusion and action | Facts seen, inferences, unknowns, owner, and next review time |
Recommended daily archive skeleton:
# <YYYY-MM-DD> <environment> 系统日检
## 范围与授权
- services: <service list>
- mode: read-only
- checklist version: <version>
## 检查结果
| 检查项 | 证据时间 | 阈值 | 状态 | 结论/动作 |
|---|---|---|---|---|
| 可用性 | <timestamp> | <threshold> | 通过 | <evidence summary> |
## 异常与沟通
- <incident summary or none>
## 归档与复核
- next review: <timestamp or condition>
- owner: <role>
Anomaly escalation and recovery notice template
First fill the square brackets with facts; do not send without confirmation.
【异常上报】[环境] [服务/用户路径]
时间：[首次发现时间，时区]
影响：[已确认影响与范围；未知则写“范围核实中”]
现象：[可观测事实]
证据：[指标/日志/状态页的脱敏摘要]
已采取：[只列实际执行动作]
当前状态：[调查中/缓解中/已恢复]
下一次更新：[时间或触发条件]
负责人：[角色或值班组]
【恢复通告】[环境] [服务/用户路径]
异常窗口：[开始] 至 [恢复确认时间]（[时区]）
影响：[已确认影响与范围]
恢复证据：[已复核的指标、关键路径或依赖状态]
当前状态：已恢复 / 持续观察至 [时间]
后续：[复盘、根因分析或预防措施的负责人和时间；若未确定则明确“待定”]
Output contract
- Required deliverables: This inspection record, check statistics, anomaly list, and, when needed, unsent escalation/recovery notice drafts.
- Status traceable: Each conclusion is linked to time and evidence; facts, inferences, and unknowns are written separately.
- Write boundaries: Create or update records only in the archive location specified by the client; sending messages, creating tickets, and any remediation actions all require explicit confirmation.
- Completion conditions: All checklist items have a valid status, anomalies have been reported or explicitly listed as pending, and the archiving action (or the reason it was not archived) has been explained in the receipt.
Verification
- Check that the number of checklist items is consistent with the result statistics;
- Spot-check whether each anomaly includes time, evidence, impact, and the next update time;
- Recovery notices cite only recovery evidence that has already been reviewed;
- When writing, confirm that the date directory, file name, and overwrite policy comply with the client's agreement.