Routine SRE inspection process for general internet 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-task stalls are handled by soia-dev-terminal-ops responsible.
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.
| What the customer wants | What the skill will do | What 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 |
| Synchronize promptly after anomalies are found | Generate an escalation draft based on impact, scope, known facts, and the next update time | Copyable anomaly escalation 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 inspection on the example production environment; read-only; record according to the team's archiving conventions; for anomalies, give me a draft first."
When thresholds are missing, record the raw observed values and mark them as "pending determination"; do not invent health baselines on your own. When restart, traffic switching, scaling, configuration modification, ticket submission, or external sending is involved, first show the impact and message draft and obtain explicit confirmation for this occurrence.
Dependencies and installation
Installation:
npx skills add soia-team/soia-open-dev-ts-skills -g -a '*' -s soia-dev-run-ops-inspection -y
Strong 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 that 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 must never be written into checklists, inspection records, message drafts, or receipts.
- Sampling 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 receipt
完成：<日期> 的 <环境> 日检已完成/部分完成。
日志摘要：
- 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 Responsibilities: observation of PID/tmux/background long-running tasks, multi-signal diagnosis of stalls, and the confirmation gate of TERM→review→KILL. When the daily inspection finds an anomaly in a task, this skill only hands off in the record "requires process diagnosis"; 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
- Establish the run card for this session. Record the date, time zone, environment, services, 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 reviewable evidence item by item; the status can only be
通过、异常、未检查or待判定. A single sample is not equivalent to a trend; without a threshold, do not declare healthy. - Cross-verify anomalies. For anomalies, verify with at least one independent piece of evidence, such as metrics and logs, status pages 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 SLOs, alert severity, and impact scope. If there are no escalation rules, immediately report the visible impact, affected scope, current evidence, and matters requiring client decision, and do not arbitrarily define incident severity.
- Record recovery. After anomaly recovery, recheck the triggering metrics, critical user paths, or dependency status, and compare before and after the anomaly. Use "recovered" only when 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 has not provided an archive location, deliver only copyable content and do not write to the current directory on your own.
Inspection checklist record contract
Each 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/end time, 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 reporting and recovery notice template
First fill the brackets with facts; do not send without confirmation.
【异常上报】[环境] [服务/用户路径]
时间：[首次发现时间，时区]
影响：[已确认影响与范围；未知则写“范围核实中”]
现象：[可观测事实]
证据：[指标/日志/状态页的脱敏摘要]
已采取：[只列实际执行动作]
当前状态：[调查中/缓解中/已恢复]
下一次更新：[时间或触发条件]
负责人：[角色或值班组]
【恢复通告】[环境] [服务/用户路径]
异常窗口：[开始] 至 [恢复确认时间]（[时区]）
影响：[已确认影响与范围]
恢复证据：[已复核的指标、关键路径或依赖状态]
当前状态：已恢复 / 持续观察至 [时间]
后续：[复盘、根因分析或预防措施的负责人和时间；若未确定则明确“待定”]
Output contract
- Required deliverables: The inspection record for this session, check statistics, anomaly list, and, when needed, an unsent draft of the report/recovery notice.
- Status traceability: Each conclusion is linked to time and evidence; facts, inferences, and unknowns are written separately.
- Writing 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, exceptions have been reported or explicitly listed as pending, and the archive action (or reason for not archiving) has been stated in the receipt.
Verification
- Check that the number of checklist items matches the result statistics;
- Spot-check whether each exception 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 agreement.