Thorough Check

Thorough Check skill (thorough-check)

Core principle

Evidence, not vibes. Every conclusion must be backed by concrete command output. Better to list 20 verbose ✅/❌ items for the user than to hand-wave "all OK".

Typical user trigger phrases

English:

• "Double-check everything carefully"
• "Are all the edge cases OK?"
• "Is the entire call chain consistent?"
• "Verify this change won't break anything"
• "Re-check thoroughly before you sign off"

中文 (Chinese):

• "仔细反复的检查 确定都没问题是吧"
• "各种边界 各种情况 各种修改地方的流程链条 都是 ok 的是吧"
• "多次分析 仔细检查"
• "改完仔细检查下"
• "确定没问题再放过"

What the user wants is for every implicit worry in your head to be made explicit and verified — not a polite "all good".

Language policy

This skill's final report (the check table shown to the user) defaults to English and auto-switches to Chinese when:

• The user's last 3 messages are primarily Chinese, OR
• The session history is primarily Chinese, OR
• The user explicitly requests Chinese

The workflow instructions themselves (this document) stay in English. Commands and code examples are language-neutral.

Multi-agent cross-check

When this skill is invoked for an actual code/config verification task, treat that invocation as standing user authorization to use reviewer agents. Start reviewer agents by default whenever the current runtime and tool policy allow subagents. Token cost is not a reason to skip them. The parent agent still owns the final judgment; subagents are used to find missed impact, challenge assumptions, and verify the draft result.

Only skip subagents when:

• The current environment has no subagent capability, or tool policy blocks it.
• The user explicitly says not to use agents/subagents for this run.
• The task is not a verification run at all, such as the user only asking what this skill means.

Default pattern:

1. Start one read-only impact reviewer agent near Block 0. Ask it to independently search for affected files, callers, old/new states, jobs, cache, permissions, data contracts, and rollback risks.
2. Start one read-only final reviewer agent before the final answer. Give it the parent draft findings and ask it to disprove "passed" claims, find missing evidence, and challenge skipped blast-radius areas.
3. While agents work, the parent agent continues Blocks 0/A/B/C/E locally. Do not wait idly unless the next step is blocked by an agent result.
4. For broad or high-risk changes, start additional focused read-only agents with disjoint scopes, such as data/state compatibility, async jobs/cache, auth/API, frontend/publish, or rollback/deploy.
5. Agent handoff must be narrow and evidence-based: tell the subagent which repo/files changed, require read-only commands, require file/line references or command output, and ask for a short findings table.
6. All agents must stay read-only: no code edits, no data mutation, no deploy, no cleanup scripts unless the user explicitly authorizes a separate fixing task.
7. Agent conclusions are not proof unless backed by command output, file references, query results, screenshots, or reproducible test output.
8. Merge agent findings into the final report. Include which agent checks were run, what they found, what the parent accepted or rejected, and any unresolved disagreement.
9. If agents disagree, preserve the disagreement in the final report and mark that area unresolved until evidence decides it.

If subagents cannot be spawned because the runtime or tool policy blocks them, or because the user explicitly opted out, do a sequential fallback and explicitly say: "No independent agent cross-check was run; reason: ...". Never imply agent review happened when it did not.

The required blocks: 0 / A / B / C / E

Run in order. Every block must output concrete commands and their results as evidence. In Codex, parallelize independent reads/searches with the parallel tool when available; otherwise run the smallest clear commands needed.

Use stable labels in every report so the chain is easy to audit later:

• Old value / New value: for parameter, text, enum, status, permission, feature-flag, route, or schema changes, explicitly name the previous value and the new value before judging behavior.
• Upstream / Downstream: in Block E, explicitly label where changed data comes from and who consumes it. Do not rely on vague "callers checked" wording when a reader needs to trace the chain.
• Excluded files: in dirty Git/SVN working copies, explicitly list generated, temporary, QA, report, cache, build, or local-only files to exclude from commit/deploy scope.
• Next run: for scheduled jobs, automations, prompt/memory edits, and publish flows, explicitly describe what the next execution will read and do.

Block 0 — Impact-map first ("how big is the blast radius?")

Before checking details, build an explicit impact map. A tiny edit can be high risk if it changes a shared field, enum, status, endpoint, permission rule, scheduled task, queue message, cache key, config value, or external integration contract.

Run the smallest available commands that reveal scope:

git diff --name-only
git diff --stat
git diff -- <changed-file>
rg -n "<changed function|field|status|route|config key>" .
rg -n "<old value>|<new value>|<enum/status variants>" .

If the repo is SVN or has no git metadata, use its equivalent (svn diff, zsvn st) plus rg.

Classify the change before continuing:

Output a short blast-radius table before saying whether the change is safe:

| Area | Files / commands checked | Risk | Evidence |
|---|---|---|---|
| Direct diff | ... | Low/Medium/High | ... |
| Callers/readers | ... | ... | ... |
| Data compatibility | ... | ... | ... |
| Jobs/events/cache | ... | ... | ... |
| Rollback/mixed deploy | ... | ... | ... |

If this map is incomplete because the repo, database, server, or dependency is unavailable, say exactly which part is unverified and do not call the whole check "passed".

Block A — Change-site verification ("did the edit actually land?")

1. First, have the user (or yourself) recall which files and which positions were changed this round.
2. For each change:
   • grep -n '<new key string>' <file> — confirm new content is present
   • grep -n '<old key string>' <file> — confirm old content is gone (should be 0 matches)
   • Write a short Old value / New value row for every changed threshold, config, label, enum/status, route, or schema field, even when the values are obvious from the diff.
3. If this was a "global replacement / N similar edits":
   • Re-grep the entire file for every variant of the original string to catch misses.
   • Typical miss patterns: 404 / 5xx → forgot 404+5xx / 404 + 5xx / 404/5xx.
   • Command: grep -nE 'pattern1|pattern2|pattern3' <file>
4. Show the user a diff overview (if backups or git exist):

diff -u <file>.bak.YYYYMMDD <file> | grep -E '^[+-]' | grep -v '^[+-]{3}'
# or
git diff <file>

Block B — Boundary condition simulation ("will extreme values blow up?")

For numeric changes, write a quick Python snippet:

for v in [0, threshold-1, threshold, threshold+1, typical, upper_bound]:
    # simulate the code logic, print behavior for each

Example: if you changed if (s5xx > 10), enumerate s5xx ∈ {0, 5, 10, 11, 50, 101, 1001} — show trigger / no-trigger + severity for each.

For string changes, ask yourself:

• Does an empty value render oddly?
• Will null / undefined cause NaN downstream?
• Will an overflow-length string break the layout?
• Special characters in username / URL (quotes, angle brackets) — XSS risk?

Block C — File integrity ("did the syntax / structure break?")

By file type:

Python:

python3 -c "import ast; ast.parse(open('xxx.py').read()); print('✅ valid')"

HTML:

h = open('xxx.html').read()
import re
divs_o = len(re.findall(r'<div\b', h))
divs_c = len(re.findall(r'</div>', h))
# script, style, a, span tags — same pattern
print(f'div: {divs_o}/{divs_c}')
# template literal backticks must be even
print(f'backticks: {h.count(chr(96))}')

JSON:

python3 -c "import json; json.load(open('xxx.json')); print('✅ valid JSON')"

YAML:

python3 -c "import yaml; yaml.safe_load(open('xxx.yml')); print('✅ valid YAML')"

Shell:

bash -n xxx.sh && echo '✅ syntax OK'

Systemd unit:

systemd-analyze verify ~/.config/systemd/user/xxx.service 2>&1

Block E — Call-chain context ("is the modified code still consistent with its surroundings?")

This block is what the user cares most about — the "call chain" (流程链条). When modifying code, don't just look at the changed line; walk the full upstream + downstream path through that line.

Required directions

1. Data flow upstream (where does this variable / field come from?)

• For each variable used in the change, how is it initialized in the same scope?
• If it comes from data.json / API / env var, does the source format match?
• Example: changed the KPI showing s5xx → trace const s5xx = ... back to the source (nginx.s5xx); ask "what if the nginx object is missing? what if s5xx is a string rather than a number?"
• Label this section Upstream in the final report and include file/function/source names, not just prose.

2. Data flow downstream (who uses this thing?)

• grep -n <modified variable/function> across the project — who else references it?
• Changed a KPI formula → check derived vars like nginxErrCount.
• Changed a function signature → every call site must be updated (or runtime TypeError).
• Changed a data.json field → every front-end reader of that field must be checked.
• Label this section Downstream in the final report and include each consumer/caller/read path checked.

Also search by concept, not just exact symbol. Many breakages hide behind aliases:

• Route aliases, controller/action names, template variable names, translated labels.
• DB column names, JSON keys, Mongo field names, SQL aliases, export headers.
• Enum/status values in different spelling/case (active, ACTIVE, 1, enabled).
• Frontend/backend duplicate constants, generated SDKs, mocks, fixtures, docs, tests.
• Shell scripts, cron wrappers, deploy scripts, import/export scripts, one-off repair scripts.

3. Horizontal chain (is the full flow still working?)

• Scheduled-task changes:
  • systemd timer still active? systemctl --user list-timers <name>
  • Wrapper script can still locate the binary?
  • Rules in the prompt file still in place?
  • Memory file still present? Will the next run read it?
  • Linger file /var/lib/systemd/linger/<user> still there?
• Web publish changes:
  • Did the publish script run?
  • Local md5 == remote md5? (curl and compare)
  • Cacheless DOM fetch + visual verify (Playwright)
• Database / schema changes:
  • Can old data be consumed by the new code?
  • Can new data written by new code be read by old clients?

For multi-file flows, explicitly walk the main path end to end:

entrypoint -> validation/auth -> business logic -> storage/write -> async side effects -> read/display/export -> monitoring/logs

At each step, name the exact file/function checked. If a step is outside the current repo, mark it as external/unverified instead of silently skipping it.

4. Time / state consistency

• Date / timezone changes: list current JST / UTC / CST times and confirm which one the user means.
• Deduplication / lock / dedup changes: enumerate all dedup conditions; simulate concurrency / retry.
• Caching changes: list cache layers (local / Cloudflare / browser); when does each invalidate?

5. Existing-state / migration consistency for behavior changes

When a change alters business semantics, not just display text or formatting, treat it as a state migration. Examples: old mode -> new mode, manual step -> automatic step, pending -> completed, soft delete -> hard delete, async processing -> sync processing, optional field -> required field, one provider/channel/rule -> another.

Verify with commands and concrete evidence:

• State inventory: list all existing statuses / enum values / DB records affected by the old and new behavior.
• In-flight records: what happens to records created before deploy but processed after deploy?
• Old clients / old jobs: can old app versions, cron jobs, callbacks, retries, exports, admin tools, and support scripts still consume the new state?
• Cleanup / reconciliation: identify scheduled jobs, queues, timeout handlers, cancel/expire tasks, reconciliation jobs, and manual repair scripts that used to assume the old behavior.
• Idempotency and retry: simulate duplicate webhook, duplicate submit, network timeout after success, retry after failure, and partial write scenarios.
• Rollback path: if code rolls back after some new-state records were created, can old code read or repair them?
• Reporting / audit / user-visible behavior: confirm dashboards, exports, reconciliation, audit logs, notifications, and customer/admin/support messages match the new behavior.
• Mixed deployment: if multiple services deploy at different times, list which combinations are safe and which are not.
• Backfill / migration decision: explicitly state whether old records need migration, cleanup, one-time scripts, or no action, and show the query / grep evidence.

For any state-machine or lifecycle change, also verify:

• Every old state, new state, intermediate state, terminal state, timeout state, and failure state has an explicit next action.
• Historical records created under the old behavior still have a valid path: complete, cancel, expire, retry, migrate, ignore, or manual handling.
• New records created under the new behavior cannot be reprocessed incorrectly by old jobs, old callbacks/events, or retries.
• External callbacks, async events, scheduled jobs, queues, admin actions, and manual repair scripts are still mapped to internal states correctly.
• Empty, duplicate, failed, partial, delayed, out-of-order, and already-processed cases are covered.
• Customer/admin/support wording no longer describes the old behavior if the system now behaves differently.
• Monitoring and alerts distinguish old-state and new-state meanings if those meanings differ.

6. Regression surface and test selection

Do not only run the easiest syntax check. Pick verification proportional to risk:

• Low-risk text/style change: changed file syntax + affected render/output check.
• Shared helper or function change: direct unit tests + every caller signature/search check.
• API/schema/status change: request/response sample, old-data sample, new-data sample, negative auth/validation sample.
• Cron/queue/job change: dry-run or next-run simulation, duplicate/retry scenario, log path, lock/dedup check.
• Frontend workflow change: browser smoke test for desktop/mobile or at least DOM/render check if browser is unavailable.
• Production/config/deploy change: local config, deployed config, secrets/env names, restart/reload path, rollback path.

API contract truth gate

For any API response, payload, generated client, or field-shape change, documentation alone is not proof. Swagger/OpenAPI, interface notes, examples, mocks, and AI-generated code are hypotheses until they are reconciled with an authoritative implementation or an observed response.

Before marking the API path safe:

1. Build a field-by-field table for documented contract -> backend DTO/serializer/controller -> observed response -> client parser/consumer. Mark any unavailable layer as unverified; do not invent, infer, or silently add fields to close a gap.
2. Every newly consumed response field must be supported by at least one authoritative backend implementation source and, when a runnable environment is available, a captured response from the exact endpoint/version. A successful compile or a Swagger match alone does not pass this gate.
3. Exercise a representative success payload, a legitimate empty/no-data payload, missing fields, explicit null, wrong types, and an error/timeout payload. Confirm the client distinguishes these states instead of collapsing them into one default result.
4. Disable or instrument fallback/default/sample data for at least one verification run. Prove whether the primary response parsed successfully before fallback activates. A page that looks normal only because default content appeared is a failed or unresolved check, not a pass.
5. Verify fallback observability: logs, metrics, error state, or test assertions must distinguish "valid empty result" from "contract/parser failure" and "upstream unavailable". If production observability is outside scope, state that explicitly.
6. Preserve raw evidence with secrets and personal data redacted: request path/version, status code, response field names/types, parser result, and whether fallback executed.

Hard-stop conditions: undocumented invented fields, fields present only in mocks/examples, a documented/runtime shape mismatch, or fallback masking a parser/contract failure. Report the exact affected consumer and wait for correction; do not sign off for release.

If tests cannot run, show the command attempted and the blocker. Then list the highest-value remaining tests instead of declaring success.

Typical "chain not fully checked" pitfalls

Output format (shown to the user)

Recommended structure

English:

# Full verification passed ✅  (or ⚠️ N issues found)

| Check | Result | Evidence |
|---|---|---|
| Agent cross-check | ✅ | impact reviewer checked callers/jobs/cache; final reviewer found no unsupported pass claims |
| Agent fallback | ⚠️ | No independent agent cross-check was run; reason: current runtime has no subagent tool |
| Impact map | ✅ | 5 changed files; 11 callers checked; no external readers found |
| Change-site A1 | ✅ | grep found 3 occurrences of the new string |
| Change-site A2 | ✅ | 0 residual old-string matches |
| Boundary s5xx=0 | ✅ | returns green |
| Boundary s5xx=11 | ✅ | yellow + alert triggered |
| HTML structure | ✅ | div 807/807 balanced |
| Chain: callers | ✅ | 3 call sites, signatures consistent |
| Chain: data source | ✅ | nginx.s5xx field exists and is numeric |
| Chain: timer | ✅ | active, next 2h26m |

## What happens on the next execution (full walkthrough)
1. ...
2. ...

中文:

# 全量核验通过 ✅（或者 ⚠️ 发现 N 个问题）

| 检查项 | 结果 | 证据 |
|---|---|---|
| Agent 交叉复核 | ✅ | impact reviewer 已查调用方/任务/缓存；final reviewer 未发现无证据通过项 |
| Agent fallback | ⚠️ | No independent agent cross-check was run; reason: 当前环境没有 subagent 工具 |
| 影响面地图 | ✅ | 5 个改动文件；已查 11 个调用方；未发现外部读取方 |
| 改动点 A1 | ✅ | grep 出 3 处新字符串 |
| 改动点 A2 | ✅ | 0 处残留旧字符串 |
| 边界 s5xx=0 | ✅ | 返回绿色 |
| 边界 s5xx=11 | ✅ | 黄色 + alert 触发 |
| HTML 结构 | ✅ | div 807/807 平衡 |
| 链条：调用方 | ✅ | 3 处调用签名一致 |
| 链条：数据源 | ✅ | nginx.s5xx 字段存在且为数字 |
| 链条：定时器 | ✅ | active, next 2h26m |

## 下次执行时会发生的事（完整推演）
1. ...
2. ...

Absolutely DO NOT

• ❌ Claim "all checked" without showing the command output
• ❌ Skip boundary conditions — the user invoked the skill because they worry about those
• ❌ Equate "no issues found" with "no issues" — admit the scope limit
• ❌ Modify code directly — this skill is read-only verification. Report findings and let the user decide
• ❌ Compress 10 checks into one "all OK" — the user will re-ask when they can't see evidence
• ❌ Look only at the changed line — walk the upstream and downstream chain
• ❌ Treat a small diff as a small risk before building an impact map
• ❌ Search only exact variable names when the same concept may appear as route names, DB fields, labels, enum values, or scripts
• ❌ Ignore old data, old queued jobs, old clients, stale cache, or rollback just because the new code path works once
• ❌ Claim independent agent review happened when no subagent was actually started or when its result was not incorporated

If issues are found

• Highlight clearly (red / ⚠️)
• State in what scenario the issue triggers
• State the impact scope (whole-page crash / single field blank / alert only)
• Suggest a fix but wait for user confirmation before changing code

Extra checks for specific scenarios

Self-check: was this thorough-check actually thorough?

After running, ask yourself:

1. If the user asks "are you sure?" again, do I have any new info to offer? → If no, not thorough enough.
2. Did I write any "speculation" as "confirmation"? → Must be measured, not inferred.
3. Did I actually walk the upstream and downstream chain of the change? → Not just the line itself.
4. Did I search for concept aliases, not only the exact string I edited?
5. Did I explicitly state the blast radius: what is affected, what is checked and unaffected, and what remains unverified?
6. If subagents were available and the user did not opt out, did I start independent reviewers and merge their findings? If not, did I state the runtime/tool-policy blocker?
7. If this is a business behavior change, did I explicitly account for old records, in-flight records, new records, retries, callbacks/events, cleanup, rollback, and mixed deployments?
8. If this blows up tomorrow, can I trace back from my output to the blind spot? → If yes, passing grade.