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.

| Block | What to verify | |---|---| | 0 — Impact map | What changed, what it touches, and what files/contracts could be affected | | A — Change sites | New strings are present; old strings are fully removed; no missed variants | | B — Boundary conditions | Threshold neighbors, null, empty, and extreme values don't blow up | | C — File integrity | Syntax is legal; tags / brackets are balanced | | E — Call-chain context | Upstream/downstream of the modified code is still consistent |

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 -- 
rg -n "" .
rg -n "||" .

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

Classify the change before continuing:

| Change type | Required extra attention | |---|---| | Function signature / return shape | Every caller, tests, mocks, API wrappers, background jobs | | Field name / schema / enum / status | Old data, new data, exports, imports, SQL/Mongo queries, admin pages | | Config / feature flag / parameter | Defaults, env overrides, deploy config, rollback, mixed old/new processes | | Endpoint / route / payload | Frontend callers, mobile/old clients, auth, validation, logs, webhooks/events | | Permission / scope / role | Positive cases, negative cases, cross-role leakage, public/anonymous behavior | | Async job / queue / cron | Retry, dedup, lock, partial failure, next scheduled run, old queued messages | | Cache / CDN / local storage | Cache keys, TTL, invalidation, stale readers, browser/server mismatch | | External provider / integration | Sandbox vs prod, callback mapping, rate limits, timeout/retry, idempotency | | Deletion / cleanup | Who still imports/reads it, packaging, deploy scripts, docs, generated files | | UI/display text | Matching legend, tooltip, export label, screenshot/mobile layout, i18n copy |

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 '' — confirm new content is present
• grep -n '' — 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.

1. 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'

1. Show the user a diff overview (if backups or git exist):

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

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'', 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 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
• 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/ 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 helpe

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: zhujian0409
• Source: zhujian0409/thorough-check-skills
• License: MIT

Install and usage instructions live in the source repository linked above.