Dwi evidence

Skill thienhoc/dwi-by-thienhoc/modules/dwi-evidence

A modular human layer that helps reduce overplanning, token waste, context loss, and actions taken without clear permission.

Install

npx -y skills add thienhoc/dwi-by-thienhoc --skill dwi-evidence

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

13 days oldThe repository was created 13 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Label coding-agent claims by evidence status, preserve provenance and failures, and separate static, runtime, and human proof. Use before completion, comparison, promotion, or handoff. Do not upgrade observations into guarantees or fabricate missing measurements and approvals.

SKILL.md

2.5 KB, as published. Nobody here has run it

Dwi Evidence

Make the support for a claim as visible as the claim itself.

Status vocabulary

Use exactly one primary label:

VERIFIED: a defined check passed in the stated environment.
OBSERVED: an event occurred in a bounded case.
ESTIMATED: a method and assumptions produced an approximation.
TARGET: a desired future result with an acceptance condition.
UNKNOWN: support is absent or insufficient.

Do not use VERIFIED for something remembered, inferred, or merely written in a plan.

Evidence record

For each material claim, capture:

Claim:
Status:
Source or producer:
Environment and scope:
Timestamp:
Method or check:
Result:
Exclusions and failures:
Remaining unknown:

Keep the record as small as the decision allows.

Evidence categories

Static

Files, structure, configuration, syntax, types, or offline validators.

Runtime

Behavior observed while the relevant system runs in the stated environment.

Human

A decision, lived-experience judgment, visual approval, or other evidence only the authorized person can provide.

Do not substitute one category silently for another. A static check does not prove a deployment works. A runtime check does not grant human approval.

Claim protocol

Write the narrow claim.
Select the evidence category and status.
Run or inspect the smallest relevant source.
Record scope and time.
Preserve contradictory and failed evidence.
State what the evidence cannot prove.
Ask for human evidence only when the decision genuinely belongs to the person.

Comparisons

A comparison needs:

matching task or population;
matching metric and measurement window;
denominator;
environment;
material exclusions;
uncertainty.

If these do not match, mark the comparison non-comparable.

Promotion and handoff

Never flatten:

one benchmark into universal performance;
cache reuse into money saved;
no observed collision into a safety guarantee;
a script-ready artifact into a released product;
a private preview into a public launch.

Stop condition

Stop gathering evidence when the current decision has sufficient support and remaining uncertainty is explicit. Evidence collection is not a reason to expand the product task.