My_harness validate-and-test
install
source · Clone the upstream repo
git clone https://github.com/WeiJun0507/my_harness
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/WeiJun0507/my_harness "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.cursor/skills/validate-and-test" ~/.claude/skills/weijun0507-my-harness-validate-and-test && rm -rf "$T"
manifest:
.cursor/skills/validate-and-test/SKILL.mdsource content
Validate and Test
Choose the lightest validation that safely fits the task. Do not run heavyweight checks by default on a trivial change.
Default Order
- Format changed files.
- Run relevant lint or static analysis.
- Write unit tests for new or changed behavior (
and above).M - Run the tests written plus any relevant existing tests.
- Do manual verification when automated tests are low value.
- Escalate to broader regression checks for
andL
.XL
By Task Size
S
S- Format changed files if needed.
- Run the smallest relevant static check.
- Run tests only when the change is not purely mechanical.
M
M- Format changed files.
- Run static analysis on the affected area.
- Write unit tests for any new or changed behavior.
- Run the new tests plus targeted existing tests.
L
L- Format changed files.
- Run broader static analysis for the affected module or package.
- Write unit tests for new and changed behavior.
- Run those tests plus nearby regression checks.
- Verify shared callers, contracts, or user flows touched by the change.
XL
XL- Validate by phase.
- Write tests for each phase before moving to the next.
- Use broader regression coverage.
- Re-check assumptions after each phase.
- Treat unresolved risk as a blocker, not a footnote.
Output Format
Format: PASS / FAIL Static checks: PASS / FAIL Tests written: YES / NO / NOT APPLICABLE Tests result: PASS / FAIL / NOT RUN Manual verification: PASS / FAIL / NOT RUN Residual risk: none / [details] Result: PASS / BLOCKED