Agent skill

Concept Page Test Writer

by leonardomso in leonardomso/33-js-concepts

Generates Vitest tests for every runnable code example on a JavaScript concept documentation page, following a four-phase extraction and conversion process.

MITAuto-check passedTesting & QA

Install Concept Page Test Writer

skills CLI
$ npx skills add leonardomso/33-js-concepts --skill test-writer -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install leonardomso/33-js-concepts test-writer --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/leonardomso/33-js-concepts.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/test-writer .claude/skills/test-writer && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
test-writer
GitHub stars
67k
Token cost
~5.5k tokens
SKILL.md length
743 words
Files
1
Skills in repo
6
Repo updated
First seen
Licence
MIT

At a glance

Generates Vitest tests for every runnable code example on a JavaScript concept documentation page, following a four-phase extraction and conversion process.

  • Works in 4 steps: Code Example Extraction → Determine Test File Structure → Convert Examples to Tests → …
  • Writing tests for a newly added concept documentation page
  • SKILL.md covers When to Use, Test Writing Methodology, Project Test Conventions and Test Patterns Reference
  • Calls npm

What it does

The agent scans a concept page and sorts each code example into categories: testable examples with a logged or returned expected value, DOM-specific examples needing a separate test file, intentional error examples that should use toThrow, purely conceptual snippets to skip, and browser-only APIs to skip or mock. It then decides the test file path and name under a tests directory organized by concept group, using a .dom.test.js suffix for DOM tests.

Each testable example is converted into expect assertions with its expected output taken from console.log comments or documented behavior, grouped into describe blocks that mirror the page's own sections, and commented with a reference back to the source line. Special cases get specific handling: fake timers for timing-dependent code, captured output for side effects, and async/await for asynchronous examples. Tests import from vitest following the project's existing import conventions.

When your agent uses it

  • Writing tests for a newly added concept documentation page
  • Adding tests after new code examples are added to an existing page
  • Verifying that updated code examples still behave as documented

Example prompts

  • “Write Vitest tests for every code example on the closures concept page.”
  • “Add DOM tests for the new event delegation examples in this page.”
  • “Convert the error-throwing examples in this concept page into toThrow tests.”

Requirements

  • Vitest configured in the project, with jsdom for DOM-specific tests

Workflow steps

4 steps, taken from the step headings in SKILL.md.

  1. Code Example Extraction
  2. Determine Test File Structure
  3. Convert Examples to Tests
  4. Handle Special Cases

What it can do on your machine

Read from SKILL.md and the folder at commit 16d0d95. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npm

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Concept Page Test Writer loads about 5.5k tokens when it runs. Until then it costs about 42 tokens; SKILL.md has 743 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~42
When it runs · the whole SKILL.md, loaded when a task matches
~5.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from leonardomso/33-js-concepts at commit 16d0d95, republished under its MIT licence (© leonardomso). 743 words, ~5,450 tokens.

Download SKILL.mdSave it as .claude/skills/test-writer/SKILL.md (or your agent's skills folder).
name
test-writer
description
Generate comprehensive Vitest tests for code examples in JavaScript concept documentation pages, following project conventions and referencing source lines

Skill: Test Writer for Concept Pages

Use this skill to generate comprehensive Vitest tests for all code examples in a concept documentation page. Tests verify that code examples in the documentation are accurate and work as described.

When to Use

  • After writing a new concept page
  • When adding new code examples to existing pages
  • When updating existing code examples
  • To verify documentation accuracy through automated tests
  • Before publishing to ensure all examples work correctly

Test Writing Methodology

Follow these four phases to create comprehensive tests for a concept page.

Phase 1: Code Example Extraction

Scan the concept page for all code examples and categorize them:

CategoryCharacteristicsAction
TestableHas console.log with output comments, returns valuesWrite tests
DOM-specificUses document, window, DOM APIs, event handlersWrite DOM tests (separate file)
Error examplesIntentionally throws errors, demonstrates failuresWrite tests with toThrow
ConceptualASCII diagrams, pseudo-code, incomplete snippetsSkip (document why)
Browser-onlyUses browser APIs not available in jsdomSkip or mock
Phase 2: Determine Test File Structure
tests/
├── fundamentals/              # Concepts 1-6
├── functions-execution/       # Concepts 7-8
├── web-platform/             # Concepts 9-10
├── object-oriented/          # Concepts 11-15
├── functional-programming/   # Concepts 16-19
├── async-javascript/         # Concepts 20-22
├── advanced-topics/          # Concepts 23-31
└── beyond/                   # Extended concepts
    └── {subcategory}/

File naming:

  • Standard tests: {concept-name}.test.js
  • DOM tests: {concept-name}.dom.test.js
Phase 3: Convert Examples to Tests

For each testable code example:

  1. Identify the expected output (from console.log comments or documented behavior)
  2. Convert to expect assertions
  3. Add source line reference in comments
  4. Group related tests in describe blocks matching documentation sections
Phase 4: Handle Special Cases
CaseSolution
Browser-only APIsUse jsdom environment or skip with note
Timing-dependent codeUse vi.useFakeTimers() or test the logic, not timing
Side effectsCapture output or test mutations
Intentional errorsUse expect(() => {...}).toThrow()
Async codeUse async/await with proper assertions

Project Test Conventions

Import Pattern
javascript
import { describe, it, expect } from 'vitest'

For DOM tests or tests needing mocks:

javascript
import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest'
DOM Test File Header
javascript
/**
 * @vitest-environment jsdom
 */
import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest'
Describe Block Organization

Match the structure of the documentation:

javascript
describe('Concept Name', () => {
  describe('Section from Documentation', () => {
    describe('Subsection if needed', () => {
      it('should [specific behavior]', () => {
        // Test
      })
    })
  })
})
Test Naming Convention
  • Start with "should"
  • Be descriptive and specific
  • Match the documented behavior
javascript
// Good
it('should return "object" for typeof null', () => {})
it('should throw TypeError when accessing property of undefined', () => {})
it('should resolve promises in order they were created', () => {})

// Bad
it('test typeof', () => {})
it('works correctly', () => {})
it('null test', () => {})
Source Line References

Always reference the documentation source:

javascript
// ============================================================
// SECTION NAME FROM DOCUMENTATION
// From {concept}.mdx lines XX-YY
// ============================================================

describe('Section Name', () => {
  // From lines 45-52: Basic typeof examples
  it('should return correct type strings', () => {
    // Test
  })
})

Test Patterns Reference

Pattern 1: Basic Value Assertion

Documentation:

javascript
console.log(typeof "hello")  // "string"
console.log(typeof 42)       // "number"

Test:

javascript
// From lines XX-YY: typeof examples
it('should return correct type for primitives', () => {
  expect(typeof "hello").toBe("string")
  expect(typeof 42).toBe("number")
})

Documentation:

javascript
let a = "hello"
let b = "hello"
console.log(a === b)  // true

let obj1 = { x: 1 }
let obj2 = { x: 1 }
console.log(obj1 === obj2)  // false

Test:

javascript
// From lines XX-YY: Primitive vs object comparison
it('should compare primitives by value', () => {
  let a = "hello"
  let b = "hello"
  expect(a === b).toBe(true)
})

it('should compare objects by reference', () => {
  let obj1 = { x: 1 }
  let obj2 = { x: 1 }
  expect(obj1 === obj2).toBe(false)
})

Pattern 3: Function Return Values

Documentation:

javascript
function greet(name) {
  return "Hello, " + name + "!"
}

console.log(greet("Alice"))  // "Hello, Alice!"

Test:

javascript
// From lines XX-YY: greet function example
it('should return greeting with name', () => {
  function greet(name) {
    return "Hello, " + name + "!"
  }
  
  expect(greet("Alice")).toBe("Hello, Alice!")
})

Pattern 4: Error Testing

Documentation:

javascript
// This throws an error!
const obj = null
console.log(obj.property)  // TypeError: Cannot read property of null

Test:

javascript
// From lines XX-YY: Accessing property of null
it('should throw TypeError when accessing property of null', () => {
  const obj = null
  
  expect(() => {
    obj.property
  }).toThrow(TypeError)
})

Pattern 5: Specific Error Messages

Documentation:

javascript
function divide(a, b) {
  if (b === 0) throw new Error("Cannot divide by zero")
  return a / b
}

Test:

javascript
// From lines XX-YY: divide function with error
it('should throw error when dividing by zero', () => {
  function divide(a, b) {
    if (b === 0) throw new Error("Cannot divide by zero")
    return a / b
  }
  
  expect(() => divide(10, 0)).toThrow("Cannot divide by zero")
  expect(divide(10, 2)).toBe(5)
})

Pattern 6: Async/Await Testing

Documentation:

javascript
async function fetchUser(id) {
  const response = await fetch(`/api/users/${id}`)
  return response.json()
}

Test:

javascript
// From lines XX-YY: async fetchUser function
it('should fetch user data asynchronously', async () => {
  // Mock fetch for testing
  global.fetch = vi.fn(() =>
    Promise.resolve({
      json: () => Promise.resolve({ id: 1, name: 'Alice' })
    })
  )
  
  async function fetchUser(id) {
    const response = await fetch(`/api/users/${id}`)
    return response.json()
  }
  
  const user = await fetchUser(1)
  expect(user).toEqual({ id: 1, name: 'Alice' })
})

Pattern 7: Promise Testing

Documentation:

javascript
const promise = new Promise((resolve) => {
  resolve("done")
})

promise.then(result => console.log(result))  // "done"

Test:

javascript
// From lines XX-YY: Basic Promise resolution
it('should resolve with correct value', async () => {
  const promise = new Promise((resolve) => {
    resolve("done")
  })
  
  await expect(promise).resolves.toBe("done")
})

Pattern 8: Promise Rejection

Documentation:

javascript
const promise = new Promise((resolve, reject) => {
  reject(new Error("Something went wrong"))
})

Test:

javascript
// From lines XX-YY: Promise rejection
it('should reject with error', async () => {
  const promise = new Promise((resolve, reject) => {
    reject(new Error("Something went wrong"))
  })
  
  await expect(promise).rejects.toThrow("Something went wrong")
})

Pattern 9: Floating Point Comparison

Documentation:

javascript
console.log(0.1 + 0.2)         // 0.30000000000000004
console.log(0.1 + 0.2 === 0.3) // false

Test:

javascript
// From lines XX-YY: Floating point precision
it('should demonstrate floating point imprecision', () => {
  expect(0.1 + 0.2).not.toBe(0.3)
  expect(0.1 + 0.2).toBeCloseTo(0.3)
  expect(0.1 + 0.2 === 0.3).toBe(false)
})

Pattern 10: Array Method Testing

Documentation:

javascript
const numbers = [1, 2, 3, 4, 5]
const doubled = numbers.map(n => n * 2)
console.log(doubled)  // [2, 4, 6, 8, 10]

Test:

javascript
// From lines XX-YY: Array map example
it('should double all numbers in array', () => {
  const numbers = [1, 2, 3, 4, 5]
  const doubled = numbers.map(n => n * 2)
  
  expect(doubled).toEqual([2, 4, 6, 8, 10])
  expect(numbers).toEqual([1, 2, 3, 4, 5]) // Original unchanged
})

Pattern 11: Object Mutation Testing

Documentation:

javascript
const obj = { a: 1 }
obj.b = 2
console.log(obj)  // { a: 1, b: 2 }

Test:

javascript
// From lines XX-YY: Object mutation
it('should allow adding properties to objects', () => {
  const obj = { a: 1 }
  obj.b = 2
  
  expect(obj).toEqual({ a: 1, b: 2 })
})

Pattern 12: Closure Testing

Documentation:

javascript
function counter() {
  let count = 0
  return function() {
    count++
    return count
  }
}

const increment = counter()
console.log(increment())  // 1
console.log(increment())  // 2
console.log(increment())  // 3

Test:

javascript
// From lines XX-YY: Closure counter example
it('should maintain state across calls via closure', () => {
  function counter() {
    let count = 0
    return function() {
      count++
      return count
    }
  }
  
  const increment = counter()
  expect(increment()).toBe(1)
  expect(increment()).toBe(2)
  expect(increment()).toBe(3)
})

it('should create independent counters', () => {
  function counter() {
    let count = 0
    return function() {
      count++
      return count
    }
  }
  
  const counter1 = counter()
  const counter2 = counter()
  
  expect(counter1()).toBe(1)
  expect(counter1()).toBe(2)
  expect(counter2()).toBe(1) // Independent
})

Pattern 13: DOM Event Testing

Documentation:

javascript
const button = document.getElementById('myButton')
button.addEventListener('click', function(event) {
  console.log('Button clicked!')
  console.log(event.type)  // "click"
})

Test (in .dom.test.js file):

javascript
/**
 * @vitest-environment jsdom
 */
import { describe, it, expect, beforeEach, afterEach } from 'vitest'

describe('DOM Event Handlers', () => {
  let button
  
  beforeEach(() => {
    button = document.createElement('button')
    button.id = 'myButton'
    document.body.appendChild(button)
  })
  
  afterEach(() => {
    document.body.innerHTML = ''
  })
  
  // From lines XX-YY: Button click event
  it('should fire click event handler', () => {
    const output = []
    
    button.addEventListener('click', function(event) {
      output.push('Button clicked!')
      output.push(event.type)
    })
    
    button.click()
    
    expect(output).toEqual(['Button clicked!', 'click'])
  })
})

Pattern 14: DOM Manipulation Testing

Documentation:

javascript
const div = document.createElement('div')
div.textContent = 'Hello'
div.classList.add('greeting')
document.body.appendChild(div)

Test:

javascript
// From lines XX-YY: Creating and appending elements
it('should create element with text and class', () => {
  const div = document.createElement('div')
  div.textContent = 'Hello'
  div.classList.add('greeting')
  document.body.appendChild(div)
  
  const element = document.querySelector('.greeting')
  expect(element).not.toBeNull()
  expect(element.textContent).toBe('Hello')
  expect(element.classList.contains('greeting')).toBe(true)
})

Pattern 15: Timer Testing

Documentation:

javascript
console.log('First')
setTimeout(() => console.log('Second'), 0)
console.log('Third')
// Output: First, Third, Second

Test:

javascript
// From lines XX-YY: setTimeout execution order
it('should execute setTimeout callback after synchronous code', async () => {
  const output = []
  
  output.push('First')
  setTimeout(() => output.push('Second'), 0)
  output.push('Third')
  
  // Wait for setTimeout to execute
  await new Promise(resolve => setTimeout(resolve, 10))
  
  expect(output).toEqual(['First', 'Third', 'Second'])
})

Pattern 16: Strict Mode Behavior

Documentation:

javascript
// In strict mode, this throws
"use strict"
x = 10  // ReferenceError: x is not defined

Test:

javascript
// From lines XX-YY: Strict mode variable declaration
it('should throw ReferenceError in strict mode for undeclared variables', () => {
  // Vitest runs in strict mode by default
  expect(() => {
    // Using eval to test strict mode behavior
    "use strict"
    eval('undeclaredVar = 10')
  }).toThrow()
})

Complete Test File Template

javascript
import { describe, it, expect } from 'vitest'

describe('[Concept Name]', () => {
  // ============================================================
  // [FIRST SECTION NAME FROM DOCUMENTATION]
  // From [concept].mdx lines XX-YY
  // ============================================================
  
  describe('[First Section]', () => {
    // From lines XX-YY: [Brief description of example]
    it('should [expected behavior]', () => {
      // Code from documentation
      
      expect(result).toBe(expected)
    })
    
    // From lines XX-YY: [Brief description of next example]
    it('should [another expected behavior]', () => {
      // Code from documentation
      
      expect(result).toEqual(expected)
    })
  })
  
  // ============================================================
  // [SECOND SECTION NAME FROM DOCUMENTATION]
  // From [concept].mdx lines XX-YY
  // ============================================================
  
  describe('[Second Section]', () => {
    // From lines XX-YY: [Description]
    it('should [behavior]', () => {
      // Test
    })
  })
  
  // ============================================================
  // EDGE CASES AND COMMON MISTAKES
  // From [concept].mdx lines XX-YY
  // ============================================================
  
  describe('Edge Cases', () => {
    // From lines XX-YY: [Edge case description]
    it('should handle [edge case]', () => {
      // Test
    })
  })
  
  describe('Common Mistakes', () => {
    // From lines XX-YY: Wrong way example
    it('should demonstrate the incorrect behavior', () => {
      // Test showing why the "wrong" way fails
    })
    
    // From lines XX-YY: Correct way example
    it('should demonstrate the correct behavior', () => {
      // Test showing the right approach
    })
  })
})

Complete DOM Test File Template

javascript
/**
 * @vitest-environment jsdom
 */
import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest'

// ============================================================
// DOM EXAMPLES FROM [CONCEPT NAME]
// From [concept].mdx lines XX-YY
// ============================================================

describe('[Concept Name] - DOM', () => {
  // Shared setup
  let container
  
  beforeEach(() => {
    // Create a fresh container for each test
    container = document.createElement('div')
    container.id = 'test-container'
    document.body.appendChild(container)
  })
  
  afterEach(() => {
    // Clean up after each test
    document.body.innerHTML = ''
    vi.restoreAllMocks()
  })
  
  // ============================================================
  // [SECTION NAME]
  // From lines XX-YY
  // ============================================================
  
  describe('[Section Name]', () => {
    // From lines XX-YY: [Example description]
    it('should [expected DOM behavior]', () => {
      // Setup
      const element = document.createElement('div')
      container.appendChild(element)
      
      // Action
      element.textContent = 'Hello'
      
      // Assert
      expect(element.textContent).toBe('Hello')
    })
  })
  
  // ============================================================
  // EVENT HANDLING
  // From lines XX-YY
  // ============================================================
  
  describe('Event Handling', () => {
    // From lines XX-YY: Click event example
    it('should handle click events', () => {
      const button = document.createElement('button')
      container.appendChild(button)
      
      let clicked = false
      button.addEventListener('click', () => {
        clicked = true
      })
      
      button.click()
      
      expect(clicked).toBe(true)
    })
  })
})

Running Tests

bash
# Run all tests
npm test

# Run tests for specific concept
npm test -- tests/fundamentals/primitive-types/

# Run tests for specific file
npm test -- tests/fundamentals/primitive-types/primitive-types.test.js

# Run DOM tests only
npm test -- tests/fundamentals/primitive-types/primitive-types.dom.test.js

# Run with watch mode
npm run test:watch

# Run with coverage
npm run test:coverage

# Run with verbose output
npm test -- --reporter=verbose

Quality Checklist

Show full SKILL.md (306 more words)Show less
Completeness
  • All testable code examples have corresponding tests
  • Tests organized by documentation sections
  • Source line references included in comments (From lines XX-YY)
  • DOM tests in separate .dom.test.js file
  • Edge cases and error examples tested
Correctness
  • Tests verify the actual documented behavior
  • Output comments in docs match test expectations
  • Async tests properly use async/await
  • Error tests use correct toThrow pattern
  • Floating point comparisons use toBeCloseTo
  • Object comparisons use toEqual (not toBe)
Convention
  • Uses explicit imports from vitest
  • Follows describe/it nesting pattern
  • Test names start with "should"
  • Proper file naming ({concept}.test.js)
  • DOM tests have jsdom environment directive
Verification
  • All tests pass: npm test -- tests/{category}/{concept}/
  • No skipped tests without documented reason
  • No false positives (tests that pass for wrong reasons)

Test Report Template

Use this template to document test coverage for a concept page.

markdown
# Test Coverage Report: [Concept Name]

**Concept Page:** `/docs/concepts/[slug].mdx`
**Test File:** `/tests/{category}/{concept}/{concept}.test.js`
**DOM Test File:** `/tests/{category}/{concept}/{concept}.dom.test.js` (if applicable)
**Date:** YYYY-MM-DD
**Author:** [Name/Claude]

## Summary

| Metric | Count |
|--------|-------|
| Total Code Examples in Doc | XX |
| Testable Examples | XX |
| Tests Written | XX |
| DOM Tests Written | XX |
| Skipped (with reason) | XX |

## Tests by Section

| Section | Line Range | Examples | Tests | Status |
|---------|------------|----------|-------|--------|
| [Section 1] | XX-YY | X | X | ✅ |
| [Section 2] | XX-YY | X | X | ✅ |
| [Section 3] | XX-YY | X | X | ⚠️ (1 skipped) |

## Skipped Examples

| Line | Example Description | Reason |
|------|---------------------|--------|
| XX | ASCII diagram of call stack | Conceptual, not executable |
| YY | Browser fetch example | Requires network, mocked instead |

## Test Execution

```bash
npm test -- tests/{category}/{concept}/

Result: ✅ XX passing | ❌ X failing | ⏭️ X skipped

Notes

[Any special considerations, mock requirements, or issues encountered]


---

## Common Issues and Solutions

### Issue: Test passes but shouldn't

**Problem:** Test expectations don't match documentation output

**Solution:** Double-check the expected value matches the `console.log` comment exactly

```javascript
// Documentation says: console.log(result)  // [1, 2, 3]
// Make sure test uses:
expect(result).toEqual([1, 2, 3])  // NOT toBe for arrays
Issue: Async test times out

Problem: Async test never resolves

Solution: Ensure all promises are awaited and async function is marked

javascript
// Bad
it('should fetch data', () => {
  const data = fetchData()  // Missing await!
  expect(data).toBeDefined()
})

// Good
it('should fetch data', async () => {
  const data = await fetchData()
  expect(data).toBeDefined()
})
Issue: DOM test fails with "document is not defined"

Problem: Missing jsdom environment

Solution: Add environment directive at top of file

javascript
/**
 * @vitest-environment jsdom
 */
Issue: Test isolation problems

Problem: Tests affect each other

Solution: Use beforeEach/afterEach for cleanup

javascript
afterEach(() => {
  document.body.innerHTML = ''
  vi.restoreAllMocks()
})

Summary

When writing tests for a concept page:

  1. Extract all code examples from the documentation
  2. Categorize as testable, DOM, error, or conceptual
  3. Create test file in correct location with proper naming
  4. Convert each example to test using appropriate pattern
  5. Reference source lines in comments for traceability
  6. Run tests to verify all pass
  7. Document coverage using the report template

Remember: Tests serve two purposes:

  1. Verify documentation is accurate
  2. Catch regressions if code examples are updated

Every testable code example in the documentation should have a corresponding test. If an example can't be tested, document why.

© leonardomso, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/test-writer of leonardomso/33-js-concepts.

Open the folder on GitHubat commit 16d0d95

Compare with similar skills

Concept Page Test Writer next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Concept Page Test Writer compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Concept Page Test Writer this skillleonardomso/33-js-concepts67k—~5.5kAutomated safety check: PassMIT
Caliber Testingcaliber-ai-org/ai-setup1.3k—~3.2kAutomated safety check: PassMIT
MoAI TDD Workflowmodu-ai/moai-adk1.2k—~3.1kAutomated safety check: PassApache-2.0
Test Coveragescott-fryxell/brayness124—~1.6kAutomated safety check: PassMIT
Verify Changesh0x91b/dev-3.0307—~1.7kAutomated safety check: PassApache-2.0
Gen TestArtexis10/endstate-gui116—~661Automated safety check: PassApache-2.0

Similar skills

  • Caliber Testing

    caliber-ai-org/ai-setup

    Writes Vitest tests following project patterns: tests/ directories, vi.mock() for module mocking with vi.hoisted() for test-time factories, global LLM mock from src/test/setup.ts, environment…

    1.3k GitHub stars~3.2k tokensUpdated 14 days ago
    Testing & QAAuto-check passed
  • MoAI TDD Workflow

    modu-ai/moai-adk

    Drives test-first development through the RED, GREEN, REFACTOR cycle, with a config switch that selects between TDD and a DDD workflow for existing code.

    1.2k GitHub stars~3.1k tokensUpdated yesterday
    Testing & QAAuto-check passed
  • Test Coverage

    scott-fryxell/brayness

    Write Vitest specs for Vue 3 JavaScript (Vite Plus, happy-dom, @vue/test-utils) and analyze V8 coverage + Fallow health to prioritize test-first refactors.

    124 GitHub stars~1.6k tokensUpdated 11 days ago
    Testing & QAAuto-check passed
  • Verify Changes

    h0x91b/dev-3.0

    How to test and verify work in the dev-3.0 repo — which vitest config covers what, how to write a test that fits the house style, mocking Electrobun RPC and i18n providers, what coverage is actually…

    307 GitHub stars~1.7k tokensUpdated yesterday
    Testing & QAAuto-check passed
  • Gen Test

    Artexis10/endstate-gui

    Generate unit tests following project conventions. An agent skill from Artexis10/endstate-gui.

    116 GitHub stars~661 tokensUpdated 2 days ago
    Testing & QAAuto-check passed
  • Testing Orcaq

    cin12211/orca-q

    OrcaQ-specific testing guide. An agent skill from cin12211/orca-q.

    224 GitHub stars~1.6k tokensUpdated 17 days ago
    Testing & QAAuto-check passed

More from leonardomso/33-js-concepts

  • JavaScript Concept Fact Checker

    leonardomso/33-js-concepts

    Verifies the technical accuracy of JavaScript concept pages by checking code examples, MDN and ECMAScript claims and external links through a five-phase method.

    67k GitHub starsUsed in 1 repo~5k tokens
    Auto-check passed
  • JavaScript Concept Page Workflow

    leonardomso/33-js-concepts

    Orchestrates five skills to produce a complete JavaScript concept documentation page, from resource curation through writing, tests, fact-checking and SEO.

    67k GitHub stars~3.9k tokensUpdated 28 days ago
    Auto-check passed
  • JS Concept Resource Curator

    leonardomso/33-js-concepts

    Finds, vets, writes up and maintains external articles, videos and courses for JavaScript concept pages, including audits for broken and outdated links.

    67k GitHub stars~4.9k tokensUpdated 28 days ago
    Auto-check passed
  • JavaScript Concept Page SEO Audit

    leonardomso/33-js-concepts

    Runs a five-step SEO audit on JavaScript concept pages: keyword clusters, on-page checks, featured snippets, internal links and a written report.

    67k GitHub stars~8.8k tokensUpdated 28 days ago
    Auto-check passed
  • JavaScript Concept Page Writer

    leonardomso/33-js-concepts

    Writes or reviews documentation pages for the 33 JavaScript Concepts project, following its structure, a beginner-friendly voice and rules against AI-sounding language.

    67k GitHub stars~14k tokensUpdated 28 days ago
    Auto-check passed

Categories

Questions about Concept Page Test Writer

What does Concept Page Test Writer do?

Generates Vitest tests for every runnable code example on a JavaScript concept documentation page, following a four-phase extraction and conversion process. The agent scans a concept page and sorts each code example into categories: testable examples with a logged or returned expected value, DOM-specific examples needing a separate test file, intentional error examples that should use toThrow, purely conceptual snippets to skip, and browser-only APIs to skip or mock.js suffix for DOM tests.

When should I use Concept Page Test Writer?

Concept Page Test Writer fits situations like: writing tests for a newly added concept documentation page; adding tests after new code examples are added to an existing page; verifying that updated code examples still behave as documented.

How do I install Concept Page Test Writer in Claude Code?

Run `npx skills add leonardomso/33-js-concepts --skill test-writer -a claude-code`. Or copy the skill folder (.claude/skills/test-writer in leonardomso/33-js-concepts) into .claude/skills/test-writer in your project. Claude Code loads it when a task matches its description.

How do I install Concept Page Test Writer in Codex?

Run `npx skills add leonardomso/33-js-concepts --skill test-writer -a codex`. Or copy the skill folder (.claude/skills/test-writer in leonardomso/33-js-concepts) into .agents/skills/test-writer in your project. Codex loads it when a task matches its description.

Can I use Concept Page Test Writer in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add leonardomso/33-js-concepts --skill test-writer -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/test-writer, .gemini/skills/test-writer, .github/skills/test-writer and .opencode/skills/test-writer in your project.

What does Concept Page Test Writer need to run?

Going by SKILL.md and its folder, Concept Page Test Writer needs the command-line tools its instructions call (npm). Our summary lists: Vitest configured in the project, with jsdom for DOM-specific tests.

Does Concept Page Test Writer access the network?

SKILL.md contains no URLs. Its commands use npm, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Concept Page Test Writer safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Concept Page Test Writer use?

Concept Page Test Writer is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Concept Page Test Writer use?

About 5.5k tokens (SKILL.md is roughly 22k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Concept Page Test Writer?

Skills that share tags, products or a category with Concept Page Test Writer: Caliber Testing (caliber-ai-org/ai-setup, 1.3k stars), MoAI TDD Workflow (modu-ai/moai-adk, 1.2k stars), Test Coverage (scott-fryxell/brayness, 124 stars) and Verify Changes (h0x91b/dev-3.0, 307 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Concept Page Test Writer?

leonardomso (a GitHub user) maintains it in leonardomso/33-js-concepts, which has 66,532 GitHub stars. The repository holds 6 skills in this directory. The repository was last updated on September 10, 2026.

Source: leonardomso/33-js-concepts on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.