# Validate

> Validate Changes Skill

- Skill: `valasubramanian-kr/validate` (Agent Skill)
- Install (CLI): `npx skillmds@latest add valasubramanian-kr/validate`
- Raw SKILL.md: https://api.skillmd.com/api/skills/valasubramanian-kr/validate/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: valasubramanian-kr (https://skillmd.com/u/valasubramanian-kr)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/valasubramanian-kr/validate

---


# Validate Changes Skill

## Purpose

Run linting, type checking, and unit tests to validate changes before pushing to GitHub.

## Usage

```bash
/validate
```

(Must be run after `/test`)

## What This Skill Does

1. **Load Test Files**: Reads unit test files from `unit-tests.md`
2. **Run Linting**: Executes ESLint/Stylelint/TypeScript checks
3. **Run Type Checking**: Validates TypeScript types
4. **Run Unit Tests**: Executes all unit tests
5. **Validate Coverage**: Ensures coverage meets thresholds
6. **Output Results**: Saves validation results to `validation-results.md`

## Implementation Plan Context

The unit tests should be located in the most recent directory under `workflow/jira-to-github/*/unit-tests.md`. You will need to find and read this file in Step 1.

## Instructions

You are validating the code implementation through testing. Follow these steps:

### Step 1: Validate Prerequisites and Load Repo Context

Verify that:
1. Code changes have been implemented
2. Unit tests have been created

**CRITICAL — Load validation commands from repo context BEFORE running anything:**

1. Read `workflow/jira-to-github/*/target-repo.md` to get the repo path and profile path
2. Read the repo profile at the path specified (e.g., `context/repos/esperanto.md`) to get the `Context Files` pointers and `PR Template > Testing` checklist
3. Read the repo's own CLAUDE.md at `<repo-path>/CLAUDE.md` and look for a `Commands` section (or similar: "Validation Commands", "Testing", "Development Commands")
4. If CLAUDE.md lacks validation commands or has only repo-wide commands:
   - Read the module context file (README.md or MODULE.md as specified in the profile's `Primary Module` field)
   - Look for module-specific validation/testing commands there
5. **You MUST use the discovered commands for Steps 2-6 below.** Store them in a list before proceeding.
6. **Fallback**: If no commands are found from ANY source (target-repo.md missing, context files missing, or context files exist but contain no command references), fall back to these defaults: `yarn lint`, `yarn tsc --noEmit`, `yarn test`. These are the ONLY acceptable fallback commands.

> **MANDATORY RULE**: You MUST ONLY use the validation commands discovered from the repo's CLAUDE.md, module context files, or the repo profile's PR Template Testing checklist. If none of those sources specify commands, use the yarn-based defaults listed in step 6. **NEVER** use `npx`, `node`, `npm run`, or any other arbitrary commands in place of the repo's specified commands — not even as a fallback. For example, if the repo specifies `yarn lint:fix` — use exactly `yarn lint:fix`, not `npx eslint`. If the repo specifies `yarn test:buy` — use exactly `yarn test:buy`, not `node node_modules/.bin/jest` or `npx jest`. The repo team has configured these commands with the correct flags, configs, and scoping. Using different commands will produce incorrect or incomplete results.

### Step 2: Run Linting

Execute linting using the command from repo context (default: `yarn lint`):

```bash
# Run linting command from repo context
# Default fallback:
yarn lint

# Capture exit code
LINT_EXIT_CODE=$?

# Display results
if [ $LINT_EXIT_CODE -eq 0 ]; then
  echo "✓ Linting passed"
else
  echo "❌ Linting failed"
  echo "Fix linting errors before proceeding"
  exit 1
fi
```

**Common lint errors**:
- Unused variables
- Missing types
- Console.log statements
- Import order issues

**Auto-fix when possible**:
```bash
yarn lint --fix
```

### Step 3: Run TypeScript Type Checking

Verify TypeScript types using the command from repo context (default: `yarn tsc --noEmit`):

```bash
# Run type check command from repo context
# Default fallback:
yarn tsc --noEmit

# Capture exit code
TSC_EXIT_CODE=$?

# Display results
if [ $TSC_EXIT_CODE -eq 0 ]; then
  echo "✓ Type checking passed"
else
  echo "❌ Type checking failed"
  echo "Fix type errors before proceeding"
  exit 1
fi
```

### Step 4: Run Unit Tests

Execute unit tests using the command from repo context (default: `yarn test`):

**Option A: Run tests using repo context command**
```bash
# Use the test command from repo CLAUDE.md or module context file
# e.g., "yarn test:buy" for esperanto, "yarn test" as default
yarn test
```

**Option B: Run specific test files**
```bash
# Test specific files
yarn test path/to/test.spec.ts

# Test with coverage
yarn test --coverage
```

**Option C: Run tests in watch mode (for iterative development)**
```bash
yarn test --watch
```

**Capture results**:
```bash
TEST_EXIT_CODE=$?

if [ $TEST_EXIT_CODE -eq 0 ]; then
  echo "✓ All tests passed"
else
  echo "❌ Tests failed"
  echo "Review test output above"
  exit 1
fi
```

### Step 5: Run Additional Validation Commands

If the repo context specifies additional validation commands beyond lint/typecheck/test (e.g., `yarn depcheck`, `yarn workspace:verify`, `yarn build`), run them in the order listed:

```bash
# Run each additional command from repo context
# Capture and report results for each
```

If no additional commands are specified, skip this step.

### Step 6: Analyze Test Coverage

Check test coverage for new/modified code:

```bash
# Generate coverage report
yarn test --coverage

# Check coverage thresholds
# Ensure new code has >80% coverage
```

**Coverage requirements**:
- Statements: 80%
- Branches: 75%
- Functions: 80%
- Lines: 80%

### Step 7: Generate Validation Results Report

Create a comprehensive validation results document:

```markdown
# Validation Results: <JIRA-KEY>

## Summary

- **Date**: <timestamp>
- **Branch**: <branch-name>
- **All Tests Passed**: ✓ / ❌

## Linting

- **Status**: ✓ Passed / ❌ Failed
- **Command**: `yarn lint`
- **Issues**: <count>

```
<lint output if errors>
```

## Type Checking

- **Status**: ✓ Passed / ❌ Failed
- **Command**: `yarn tsc --noEmit`
- **Errors**: <count>

## Unit Tests

- **Status**: ✓ Passed / ❌ Failed
- **Command**: `yarn test`
- **Tests Run**: <count>
- **Tests Passed**: <count>
- **Tests Failed**: <count>
- **Duration**: <time>

### Test Files

1. `path/to/test.spec.ts` - ✓ Passed (<count> tests)
2. `path/to/another.spec.ts` - ✓ Passed (<count> tests)

### Failed Tests (if any)

```
<test output for failed tests>
```

## Test Coverage

- **Statements**: <percentage>% (threshold: 80%)
- **Branches**: <percentage>% (threshold: 75%)
- **Functions**: <percentage>% (threshold: 80%)
- **Lines**: <percentage>% (threshold: 80%)

### Coverage Details

| File | Statements | Branches | Functions | Lines |
|------|------------|----------|-----------|-------|
| path/to/file.ts | 90% | 85% | 95% | 90% |

## Issues Found

### Critical Issues
<List any critical issues that block PR>

### Non-Critical Issues
<List any minor issues or tech debt>

## Recommendations

- <Any recommendations for follow-up>
- <Performance optimizations>
- <Additional test coverage needed>

---
*Tests executed: <timestamp>*
```

Save to:
```
workflow/jira-to-github/<JIRA-NUMBER>/validation-results.md
```

### Step 8: Display Summary

Display a concise summary to the user:

```
✓ Testing Complete

Linting: ✓ Passed
Type Check: ✓ Passed
Unit Tests: ✓ <count> passed
Coverage: <percentage>%

Validation results saved to: workflow/jira-to-github/<JIRA-NUMBER>/validation-results.md

Next step: Run /push to create pull request
```

**If tests failed**:
```
❌ Testing Failed

Linting: ✓ Passed
Type Check: ❌ Failed (<count> errors)
Unit Tests: ❌ <count> failed
Coverage: <percentage>%

Fix the errors above before proceeding.

To see details: cat workflow/jira-to-github/<JIRA-NUMBER>/validation-results.md
```

## Error Handling

If errors occur:
1. Log error to `workflow/jira-to-github/<JIRA-NUMBER>/errors.log`
2. Display user-friendly message
3. DO NOT proceed to push-to-github if tests fail

Common errors:
- **Linting failed**: Fix ESLint errors (run `yarn lint --fix` for auto-fixes)
- **Type errors**: Fix TypeScript type issues
- **Unit tests failed**: Debug failing tests, update test data or implementation
- **Coverage too low**: Add more tests for new code
- **Tests timeout**: Increase timeout or optimize slow tests

## Test Debugging Tips

**For failing unit tests**:
```bash
# Run single test file
yarn test path/to/failing.spec.ts

# Run with verbose output
yarn test --verbose

# Run in debug mode
node --inspect-brk node_modules/.bin/jest path/to/test.spec.ts
```

**For linting errors**:
```bash
# Show all errors
yarn lint

# Auto-fix formatting
yarn lint --fix

# Check specific file
yarn lint path/to/file.ts
```

**For type errors**:
```bash
# Check specific file
yarn tsc --noEmit path/to/file.ts

# Verbose type checking
yarn tsc --noEmit --listFiles
```

## Examples

Example 1: All tests pass
```bash
/validate
# → ✓ All tests passed (45 tests, 92% coverage)
# → Ready to create PR
```

Example 2: Linting errors
```bash
/validate
# → ❌ Linting failed (3 errors)
# → Fix errors with: yarn lint --fix
```

Example 3: Unit test failures
```bash
/validate
# → ❌ 2 tests failed
# → CardList.spec.ts - "should render cards" failed
# → Fix tests before proceeding
```