Dwi lean
A modular human layer that helps reduce overplanning, token waste, context loss, and actions taken without clear permission.
npx -y skills add thienhoc/dwi-by-thienhoc --skill dwi-leanAssembled 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
Keep planning, implementation, and testing proportionate to the actual coding task. Use when work is expanding into speculative architecture, broad exploration, repeated review, or excessive tests. Do not use to skip required safety, migration, release, or acceptance evidence.
SKILL.md
2.6 KB, as published. Nobody here has run it
Dwi Lean
Find the smallest sufficient path from the requested outcome to credible evidence, then stop.
First principle
Do not optimize the process before understanding the finish line.
Name:
- the requested outcome;
- the allowed scope;
- the acceptance condition;
- the evidence needed;
- the actions that are explicitly out of scope.
If these are already clear, do not ask the person to repeat them.
Choose the work shape
Direct
Use for a small, reversible, well-specified change. Act without a formal plan.
Bounded plan
Use when several dependent steps or files are involved. Keep the plan short and outcome-based.
Risk-controlled
Use only when architecture, migration, concurrency, security, irreversible effects, cross-repository work, or ambiguous authority is genuinely present. Narrow the risky part instead of inflating the whole task.
Execution protocol
- Read only the files needed to identify the change.
- Prefer one coherent edit over many exploratory edits.
- Reuse existing conventions before introducing a new abstraction.
- Add no dependency, service, agent, or governance artifact without demonstrated need.
- Keep optional enhancements separate from the requested outcome.
- If a new uncertainty appears, pause only the affected step.
Proportionate evidence
Match checking effort to the claim:
- Text or metadata change: inspect structure and links.
- Local behavior change: run the narrowest relevant check.
- Shared contract change: run contract and focused regression checks.
- High-risk or release claim: use independent evidence appropriate to the risk.
Do not run a broad test campaign merely because tools are available. Do not claim completion without the evidence the finish line requires.
Anti-expansion checks
Before adding work, ask:
- Does this change the requested outcome?
- Does current evidence show the need?
- Is there a smaller reversible way?
- Is this a required gate or only a preference?
- Can it become a clearly labeled next step instead?
If the answer is "no need now," leave it out.
Stop condition
Stop when the requested outcome is met, the agreed evidence is present, remaining uncertainty is disclosed, and no required gate remains. Do not re-review, redesign, or add polish after that boundary unless the person asks.