Usage boundaries and preparation
This skill can be installed on its own; the necessary methods are all in this file and it does not depend on the author's machine or other skills. First read the target project's specifications and confirm the target repository/workspace, version, user results, and allowed changes; the reference repository is read-only. When there are no project rules, read the actual README, scripts, and source code to infer the entry points.
Execute with currently available and authorized tools: if there is no independent agent, you may use a new session/manual review or self-check from multiple perspectives, and note the actual review method; if there is no browser/real API, complete the executable parts and hand off the uncovered acceptance items, and do not pretend that independent review, GUI, or real service passed. The project's original runtime environment is still required; do not bind to a model vendor or specific plugin.
For complex tasks, you may use assets/task-record.md to save necessary facts; for simple tasks, record the results directly and do not mechanically add process.
The goal is to prove that the results produced by the current integration are correctly used by real consumers, and that failures and unknown states are not disguised as success.
Determine the real path
Starting from the user action or failure symptom, trace the input, configuration parsing, actual execution values, execution, persistence, subsequent reading, and display. Read the actual consuming code or runtime, not just types, extension point declarations, and write functions.
Record the version, runtime combination, and target platform. For plugin or dependency upgrades, confirm the exact start and end versions, and read the actual interfaces of both versions, change documentation, dependency resolution, and final consumers. If the project already has migration rules, follow them; if not, create a migration record with three columns: change location, target behavior, and verification method. Do not infer the current API from historical cases.
Answer these questions at the relevant boundaries
Select applicable items according to the task; do not treat the table as a repository-wide inspection requirement.
| Contract dimension | Difference to verify |
|---|---|
| Identity and cardinality | Whether the name is unique; whether the path string represents the same object; whether one event corresponds to one task; whether duplicate usage is counted repeatedly |
| Source and priority | Which takes priority, the authoritative directory or the cache/fallback; which value takes effect among environment variables, configuration, and UI; whether the version matches |
| State semantics | Whether existence equals validity; whether not found equals deletion; whether unsupported, invalid, not enabled, and query failure are distinguished |
| Format and consumers | Whether units, schema, enums, extension fields, and encapsulation are still usable after display, recovery, and migration |
| Capabilities and combinations | Which capabilities are actually registered in the current runtime; whether optional capabilities degrade explainably when missing; whether required capabilities fail clearly when missing |
| Lifecycle | Whether state and resources remain consistent after cold start, upgrade, recovery, cancellation, cleanup, or restart |
| Errors and retries | Whether exceptions enter diagnosable channels; how to verify when the result is unknown; whether successful operations are replayed again; whether repeated execution has side effects |
For each actual suspicion, record the producer, consumer, agreement, observed value, consequence of failure, and evidence. Keep unverified contract differences as assumptions.
Verify with counterexamples
Select a small number of bad states that can expose the current problem, such as expired credentials, an old catalog, missing optional tools, newly added fields before and after migration, query failures, duplicate events, and retries after cancellation. Do not run only the happy path.
Check the output and state, and whether failures are visible. A "protective code path" has evidence only when the corresponding bad scenario actually triggers diagnostics or prevents erroneous results. Verify database or historical migrations in an isolated copy.
Absence does not automatically mean deletion; external writes that may have been executed are not automatically retried. First query the real result, then choose a recovery plan based on idempotency and current authorization. The scope of authorization is determined by the current task.
Fix and acceptance
When the user asks only for an inspection, output the findings and do not expand it into a refactor. When a fix is authorized, prioritize correcting the authoritative source, unifying semantics, or adding support for real consumers; do not relax existing safety/integrity constraints just to pass tests.
Whether historical dirty state needs bounded repair, whether subsequent writes will still produce the same kind of problem, and whether consumers can still remain compatible should be judged by actual impact. Self-healing operations need to be justified and observable, and must not overwrite arbitrary unknown state.
Retest from the real entry point through to the actual consumer. Logs use correlation IDs and redacted configuration identities, and do not leak credentials. Asynchronous background tasks may remain asynchronous, but failures must have task status, usable diagnostics, or error presentation appropriate to that flow.
Output
Deliver the relevant contract tables, confirmed differences and consequences, negative experiments, fixes, and uncovered versions/platforms. Distinguish success, failure, and unknown results; process liveness, type checking passing, or UI save success alone does not prove that the entire chain succeeded.