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.md
source 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

  1. Format changed files.
  2. Run relevant lint or static analysis.
  3. Write unit tests for new or changed behavior (
    M
    and above).
  4. Run the tests written plus any relevant existing tests.
  5. Do manual verification when automated tests are low value.
  6. Escalate to broader regression checks for
    L
    and
    XL
    .

By Task Size

S

  • Format changed files if needed.
  • Run the smallest relevant static check.
  • Run tests only when the change is not purely mechanical.

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

  • 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

  • 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