Agent skill

Solution Testing

by kid-sid in kid-sid/claude-spellbook

A skill your agent uses when writing Playwright E2E tests for critical user journeys, setting up post-deployment smoke tests, debugging flaky browser automation, or implementing BDD feature files…

MITAuto-check passedTesting & QA

Install Solution Testing

skills CLI
$ npx skills add kid-sid/claude-spellbook --skill solution-testing -a claude-code

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

GitHub CLI
$ gh skill install kid-sid/claude-spellbook solution-testing --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/kid-sid/claude-spellbook.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/solution-testing .claude/skills/solution-testing && 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
solution-testing
GitHub stars
189
Token cost
~3.9k tokens
SKILL.md length
1,101 words
Files
1
Skills in repo
52
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when writing Playwright E2E tests for critical user journeys, setting up post-deployment smoke tests, debugging flaky browser automation, or implementing BDD feature files…

  • Writing Playwright E2E tests for critical user journeys
  • SKILL.md covers When to Activate, E2E vs Integration: The Boundary, Playwright Setup and Patterns and API E2E Tests, plus 7 more sections
  • Calls npx and npm; reaches github.com; needs SMOKE_PASSWORD
  • Setting up post-deployment smoke tests

What it does

Solution Testing is an agent skill from kid-sid/claude-spellbook. Use when writing Playwright E2E tests for critical user journeys, setting up post-deployment smoke tests, debugging flaky browser automation, or implementing BDD feature files with Gherkin.

Its SKILL.md is about 3.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering End-to-end testing, Customer journey mapping and Browser testing. It works with Playwright. The repository describes itself as: A curated collection of skills, prompts, and workflows that extend Claude's capabilities — your personal grimoire for AI-powered development. The licence is MIT.

When your agent uses it

  • Writing Playwright E2E tests for critical user journeys
  • Setting up post-deployment smoke tests
  • Debugging flaky browser automation
  • Implementing BDD feature files with Gherkin

Example prompts

  • “/solution-testing”

Requirements

  • Python 3
  • Node.js

What it can do on your machine

Read from SKILL.md and the folder at commit a7c2ac9. 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:

    • npx
    • npm

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

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • github.com

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

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • SMOKE_PASSWORD

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

Context cost

Solution Testing loads about 3.9k tokens when it runs. Until then it costs about 52 tokens; SKILL.md has 1,101 words of instructions outside code blocks.

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

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 kid-sid/claude-spellbook at commit a7c2ac9, republished under its MIT licence (© kid-sid). 1,101 words, ~3,911 tokens.

Download SKILL.mdSave it as .claude/skills/solution-testing/SKILL.md (or your agent's skills folder).
name
solution-testing
description
Use when writing Playwright E2E tests for critical user journeys, setting up post-deployment smoke tests, debugging flaky browser automation, or implementing BDD feature files with Gherkin.

Solution Testing

End-to-end and acceptance testing techniques for verifying that a feature works correctly across the full stack — browser, API, and data layer — from the user's perspective.

When to Activate

  • Writing browser automation tests for user journeys
  • Verifying a full feature works end-to-end (UI through DB)
  • Setting up Playwright or Cypress for a project
  • Writing BDD feature files with Gherkin syntax
  • Designing smoke tests for post-deployment verification
  • Debugging flaky E2E tests
  • Deciding how many E2E tests to write for a feature

E2E vs Integration: The Boundary

E2E tests cover things integration tests cannot:

  • Real browser rendering and JavaScript execution (layout, event handling, hydration)
  • Full stack traversal: UI → API → DB → UI response cycle
  • Multi-step user journeys across pages, sessions, and auth boundaries
Cost of Each Test Level
TypeSpeedFlakiness RiskMaintenance Cost
UnitmsVery lowLow
IntegrationsecondsLowMedium
E2E10s–minutesHighHigh
The Honeycomb Model

Prefer more service-level integration tests over E2E tests. E2E tests are expensive to write, slow to run, and prone to flakiness. Use them sparingly.

  • Write E2E tests only for critical user journeys: login, checkout, core business workflows
  • Do not write E2E tests for every edge case — cover those with unit and integration tests
  • Aim for: many unit tests → more integration tests → few targeted E2E tests

Playwright Setup and Patterns

Project Setup
bash
npm init playwright@latest
# or add to an existing project:
npm install -D @playwright/test
npx playwright install

Config (playwright.config.ts):

typescript
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './e2e',
  fullyParallel: true,
  retries: process.env.CI ? 2 : 0,
  reporter: [['html'], ['list']],
  use: {
    baseURL: process.env.BASE_URL ?? 'http://localhost:3000',
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
    trace: 'on-first-retry',
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  ],
  webServer: {
    command: 'npm run start',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
  },
});
Page Object Model (POM)

Each page or major component has a class that encapsulates its selectors and actions. Test files use POM methods — never raw locators.

typescript
// pages/login.page.ts
import { Page, Locator } from '@playwright/test';

export class LoginPage {
  private readonly emailInput: Locator;
  private readonly passwordInput: Locator;
  private readonly submitButton: Locator;

  constructor(private page: Page) {
    this.emailInput = page.getByLabel('Email');
    this.passwordInput = page.getByLabel('Password');
    this.submitButton = page.getByRole('button', { name: 'Sign in' });
  }

  async goto() {
    await this.page.goto('/login');
  }

  async login(email: string, password: string) {
    await this.emailInput.fill(email);
    await this.passwordInput.fill(password);
    await this.submitButton.click();
  }
}

// e2e/auth.spec.ts
import { test, expect } from '@playwright/test';
import { LoginPage } from '../pages/login.page';

test('user can log in with valid credentials', async ({ page }) => {
  const loginPage = new LoginPage(page);
  await loginPage.goto();
  await loginPage.login('user@example.com', 'password123');
  await expect(page).toHaveURL('/dashboard');
});
Locator Strategy (Priority Order)
LocatorExampleWhy preferred / when to use
getByRolegetByRole('button', { name: 'Submit' })Accessibility-based, most stable, mirrors how users perceive UI
getByLabelgetByLabel('Email address')Form inputs — semantically tied to label text
getByTextgetByText('Welcome back')Unique visible text content
getByTestIdgetByTestId('submit-btn')When no semantic selector works; use data-testid attribute
CSS selectorlocator('.btn-primary')Last resort — fragile, breaks on markup changes, avoid
typescript
// BAD
page.locator('#root > div > form > button:nth-child(2)')
// Fragile CSS path — breaks on any DOM restructure

// GOOD
page.getByRole('button', { name: 'Submit' })
// Semantic, resilient, matches accessibility tree
Waiting Strategy

Never use hardcoded sleeps. Always wait for an observable UI state.

typescript
// BAD
await page.click('#submit');
await page.waitForTimeout(2000);  // never do this — hides real timing issues

// GOOD
await page.click('#submit');
await expect(page.getByText('Payment confirmed')).toBeVisible();
// or wait for navigation:
await page.waitForURL('/confirmation');

API E2E Tests

Test complete API workflows over the network — not just service-level unit behavior. This verifies the full auth lifecycle, serialization, and routing.

Key patterns:

  • Obtain an auth token, use it in subsequent requests, refresh before expiry
  • Use Playwright's request fixture for co-located API and browser tests
  • Assert on response status, body shape, and downstream side effects
typescript
test('create and retrieve payment', async ({ request }) => {
  // authenticate
  const authRes = await request.post('/api/auth/token', {
    data: { email: 'test@example.com', password: 'password' }
  });
  const { access_token } = await authRes.json();

  // create resource
  const createRes = await request.post('/api/payments', {
    headers: { Authorization: `Bearer ${access_token}` },
    data: { amount: 100, currency: 'USD' }
  });
  expect(createRes.ok()).toBeTruthy();
  const { id } = await createRes.json();

  // retrieve and verify
  const getRes = await request.get(`/api/payments/${id}`, {
    headers: { Authorization: `Bearer ${access_token}` }
  });
  const payment = await getRes.json();
  expect(payment.amount).toBe(100);
});

BDD with Gherkin

When to Use BDD

Use BDD when:

  • A product owner, QA, and developer need shared, readable test documentation
  • Business rules are complex and non-engineers need to verify coverage

Do not use BDD when:

  • The team is small and tickets already capture intent clearly
  • The overhead of step definitions outweighs the communication benefit
Feature File Structure
gherkin
Feature: User Authentication
  As a registered user
  I want to log in with my credentials
  So that I can access my account

  Background:
    Given a user exists with email "user@example.com"

  Scenario: Successful login
    When I submit valid credentials for "user@example.com"
    Then I should be redirected to the dashboard
    And I should see a welcome message

  Scenario: Failed login - wrong password
    When I submit the wrong password for "user@example.com"
    Then I should see "Invalid credentials"
    And I should remain on the login page

  Scenario Outline: Login with various invalid inputs
    When I submit email "<email>" and password "<password>"
    Then I should see error "<error>"

    Examples:
      | email            | password | error                    |
      | invalid-email    | pass123  | Invalid email format     |
      |                  | pass123  | Email is required        |
      | user@example.com |          | Password is required     |
BDD Tooling
LanguageTool
Node.js@cucumber/cucumber
Pythonbehave
Gogodog
JavaCucumber-JVM

Use tags to filter test runs: @smoke, @regression, @wip.

bash
# Run only smoke-tagged scenarios
npx cucumber-js --tags @smoke

# Skip work-in-progress scenarios
npx cucumber-js --tags "not @wip"

Smoke Tests

Smoke tests answer one question: "Is the deployed system alive?" They are not comprehensive — they verify only the critical path. If a smoke test fails, the deployment must be rolled back or halted immediately.

Run smoke tests automatically after every deployment to staging and production.

Criteria for inclusion: if this breaks, the system is unusable for most users.

typescript
test.describe('Smoke', () => {
  test('health endpoint returns 200', async ({ request }) => {
    const res = await request.get('/health');
    expect(res.status()).toBe(200);
  });

  test('home page loads', async ({ page }) => {
    await page.goto('/');
    await expect(page.getByRole('heading', { level: 1 })).toBeVisible();
  });

  test('user can log in', async ({ page }) => {
    const loginPage = new LoginPage(page);
    await loginPage.goto();
    await loginPage.login(process.env.SMOKE_USER!, process.env.SMOKE_PASSWORD!);
    await expect(page).toHaveURL('/dashboard');
  });
});

Run with:

bash
npx playwright test --grep @smoke

Tag smoke tests with @smoke in Playwright using test.describe metadata or a custom tag fixture so they can be selected independently from the full suite.

Flakiness Prevention

Root Causes and Fixes
CauseFix
Hardcoded waitForTimeoutReplace with observable state assertions (toBeVisible, etc.)
Shared test data across parallel testsUse unique IDs per test run (e.g., Date.now() suffix)
Tests depend on execution orderEach test must set up its own state in beforeEach
Timezone or locale sensitivityFix locale in test environment config
Race conditions in UI during animationUse toBeVisible() / toBeEnabled() — not isVisible()
Network variability in CIIncrease timeouts in CI config, not with waitForTimeout
Quarantine Pattern

When a test is flaky and cannot be fixed immediately, quarantine it rather than deleting it. Deletion loses coverage history; quarantine preserves intent and tracks remediation.

typescript
test.fixme('payment flow — FLAKY: race condition in payment widget', async ({ page }) => {
  // tracked in: https://github.com/org/repo/issues/123
  // do not delete — re-enable once widget stabilised
});

test.fixme skips the test and marks it as expected to fail. Remove the .fixme once the underlying issue is resolved.

Show full SKILL.md (428 more words)Show less

Test Data Management

Never use production accounts or shared test users in E2E tests. Shared state causes interference between parallel runs and makes failures non-deterministic.

API-Driven Setup and Teardown
typescript
let testUser: { id: string; email: string };

test.beforeEach(async ({ request }) => {
  // create an isolated test user for this test run
  const res = await request.post('/api/test/users', {
    data: { email: `test-${Date.now()}@example.com` }
  });
  testUser = await res.json();
});

test.afterEach(async ({ request }) => {
  // clean up — do not leave test data in the database
  await request.delete(`/api/test/users/${testUser.id}`);
});
Rules for Test Data
  • Test data helper endpoints (/api/test/*) must only be available in test and staging environments
  • Gate them with a NODE_ENV check in the server — never expose in production
  • Prefer creating data via API over direct DB mutations for portability
  • Do not rely on seed data that may change — generate data at test time
typescript
// server-side guard (Express example)
if (process.env.NODE_ENV !== 'test' && process.env.NODE_ENV !== 'staging') {
  throw new Error('Test helpers only available in test/staging environments');
}

CI Integration

yaml
# .github/workflows/e2e.yml
name: E2E Tests
on: [push, pull_request]

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test
        env:
          CI: true
          BASE_URL: http://localhost:3000
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

Key CI settings:

  • Set CI=true so Playwright applies retries: 2 from config
  • Upload playwright-report/ as artifact on failure for post-mortem debugging
  • Run smoke tests as a separate faster job on staging deploy; run full suite on PRs

Red Flags

  • Locators by CSS class or generated attribute — class names change during refactoring; use getByRole, getByLabel, or data-testid attributes that survive UI changes
  • waitForTimeout as an explicit sleep — arbitrary sleeps make tests slow and flaky; always wait on observable state (waitForSelector, expect(locator).toBeVisible())
  • One long E2E test that covers the entire user flow — a 200-step test is slow, provides poor failure diagnosis, and fails for unrelated reasons; split into focused user-journey tests
  • E2E tests run against a shared staging environment — tests that create or delete shared state break other developers' work; use isolated per-run environments or UUID-suffixed test data
  • Hardcoded test user credentials — parallel CI runs create conflicts; generate unique test users per run or use an isolated test account per CI job
  • No smoke test post-deployment — a full E2E suite takes too long to run immediately after deploy; define a 2-minute smoke test of critical paths that runs on every deployment
  • Quarantining flaky tests indefinitely — flaky tests erode trust in the suite and mask real failures; quarantine with test.fixme and a tracking issue, fix within the same sprint

Checklist

  • E2E tests cover only critical user journeys (login, core workflows, checkout)
  • Page Object Model used — no raw locators in test files
  • Locators use getByRole / getByLabel — no fragile CSS selectors
  • No waitForTimeout — all waits are based on observable state
  • Tests are fully isolated — no shared mutable state between tests
  • Smoke tests defined and run automatically after every deployment
  • Flaky tests are quarantined with test.fixme and a tracking issue, not deleted
  • Test data created via API in beforeEach and cleaned up in afterEach
  • CI retries E2E tests 2x before failing (retries: 2 in CI config)
  • Screenshots and video captured on failure for debugging (playwright.config.ts)
  • Test data endpoints are gated and unavailable in production
  • BDD feature files reviewed by a non-engineer to confirm readability

© kid-sid, 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 skills/solution-testing of kid-sid/claude-spellbook.

Open the folder on GitHubat commit a7c2ac9

Compare with similar skills

Solution Testing 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.

Solution Testing compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Solution Testing this skillkid-sid/claude-spellbook189—~3.9kAutomated safety check: PassMIT
Agentic Browser Testingpetrkindlmann/qa-skills165—~4.5kAutomated safety check: PassMIT
playwright-cli Browser Automationgithub/gh-aw5.4k24 repos~2.8kAutomated safety check: PassMIT
Glance TestDebugBase/glance156—~827Automated safety check: PassMIT
Open BrowserJasonHonKL/Openbrowser114—~1.6kAutomated safety check: PassMIT
Playwright Testingchongdashu/vibejam-starter-pack149—~2.2kAutomated safety check: PassNone

Similar skills

  • Agentic Browser Testing

    petrkindlmann/qa-skills

    Goal-driven E2E testing where a browser agent (Playwright MCP / computer-use) reads a natural-language goal and explores the app via the accessibility tree to assert outcomes — no pre-written script.

    165 GitHub stars~4.5k tokensUpdated 4 mo ago
    Testing & QAAuto-check passed
  • Official

    Drives a real browser from the command line with playwright-cli to open pages, interact, mock requests, save state and work with Playwright tests.

    5.4k GitHub starsUsed in 24 repos~2.8k tokens
    Testing & QAAuto-check passed
  • Glance Test

    DebugBase/glance

    Run E2E browser tests on any web application using Glance MCP.

    156 GitHub stars~827 tokensUpdated 5 mo ago
    Testing & QAAuto-check passed
  • Open Browser

    JasonHonKL/Openbrowser

    A skill your agent uses whenever the task involves browsing web pages, extracting page content, clicking forms, or completing web workflows.

    114 GitHub stars~1.6k tokensUpdated 5 mo ago
    Testing & QAAuto-check passed
  • Playwright Testing

    chongdashu/vibejam-starter-pack

    Plan, implement, and debug frontend tests: unit/integration/E2E/visual/a11y.

    149 GitHub stars~2.2k tokensUpdated 5 mo ago
    Testing & QAAuto-check passed
  • Playwright Expert

    cin12211/orca-q

    Playwright E2E testing expert for browser automation, cross-browser testing, visual regression, network interception, and CI integration.

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

More from kid-sid/claude-spellbook

All 52 skills in this repo
  • Accessibility

    kid-sid/claude-spellbook

    A skill your agent uses when building or reviewing UI components for keyboard and screen reader compatibility, adding ARIA to custom widgets, auditing a page for WCAG AA conformance, or preparing…

    189 GitHub stars~3.2k tokensUpdated 2 mo ago
    Auto-check passed
  • Agentex

    kid-sid/claude-spellbook

    A skill your agent uses when building, wiring, or debugging an Agentex agent — choosing agent type, configuring acp.py and manifest.yaml, using adk.messages or adk.state, or resolving…

    189 GitHub stars~2.2k tokensUpdated 2 mo ago
    Auto-check: notes
  • AI Engineer

    kid-sid/claude-spellbook

    A skill your agent uses when building production LLM applications — designing RAG pipelines, choosing vector databases, implementing agent orchestration, optimizing cost, or adding AI safety…

    189 GitHub stars~3.7k tokensUpdated 2 mo ago
    Auto-check passed
  • Angular

    kid-sid/claude-spellbook

    A skill your agent uses when building or refactoring Angular applications — choosing between signals, RxJS, and NgRx for state, configuring routing with guards and lazy loading, optimizing change…

    189 GitHub stars~5k tokensUpdated 2 mo ago
    Auto-check passed
  • API Design

    kid-sid/claude-spellbook

    A skill your agent uses when designing new REST endpoints, reviewing an existing API contract, adding pagination or filtering, planning a versioning strategy, or building a public or partner-facing…

    189 GitHub stars~3.6k tokensUpdated 2 mo ago
    Auto-check passed
  • Auth

    kid-sid/claude-spellbook

    A skill your agent uses when implementing login flows, issuing or validating JWTs, setting up OAuth2/OIDC with a provider, designing role-based or attribute-based access control, securing API…

    189 GitHub stars~3.2k tokensUpdated 2 mo ago
    Auto-check passed

Works with

Categories

Questions about Solution Testing

What does Solution Testing do?

A skill your agent uses when writing Playwright E2E tests for critical user journeys, setting up post-deployment smoke tests, debugging flaky browser automation, or implementing BDD feature files…. Solution Testing is an agent skill from kid-sid/claude-spellbook. Use when writing Playwright E2E tests for critical user journeys, setting up post-deployment smoke tests, debugging flaky browser automation, or implementing BDD feature files with Gherkin.

When should I use Solution Testing?

Solution Testing fits situations like: writing Playwright E2E tests for critical user journeys; setting up post-deployment smoke tests; debugging flaky browser automation; implementing BDD feature files with Gherkin.

How do I install Solution Testing in Claude Code?

Run `npx skills add kid-sid/claude-spellbook --skill solution-testing -a claude-code`. Or copy the skill folder (skills/solution-testing in kid-sid/claude-spellbook) into .claude/skills/solution-testing in your project. Claude Code loads it when a task matches its description.

How do I install Solution Testing in Codex?

Run `npx skills add kid-sid/claude-spellbook --skill solution-testing -a codex`. Or copy the skill folder (skills/solution-testing in kid-sid/claude-spellbook) into .agents/skills/solution-testing in your project. Codex loads it when a task matches its description.

Can I use Solution Testing 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 kid-sid/claude-spellbook --skill solution-testing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/solution-testing, .gemini/skills/solution-testing, .github/skills/solution-testing and .opencode/skills/solution-testing in your project.

What does Solution Testing need to run?

Going by SKILL.md and its folder, Solution Testing needs the command-line tools its instructions call (npx and npm) and credentials named SMOKE_PASSWORD. Our summary lists: Python 3; Node.js.

Does Solution Testing access the network?

SKILL.md names 1 domain. In commands or code: github.com; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.

Is Solution Testing 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 Solution Testing use?

Solution Testing 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 Solution Testing use?

About 3.9k tokens (SKILL.md is roughly 16k 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 Solution Testing?

Skills that share tags, products or a category with Solution Testing: Agentic Browser Testing (petrkindlmann/qa-skills, 165 stars), playwright-cli Browser Automation (github/gh-aw, 5.4k stars), Glance Test (DebugBase/glance, 156 stars) and Open Browser (JasonHonKL/Openbrowser, 114 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Solution Testing?

kid-sid (a GitHub user) maintains it in kid-sid/claude-spellbook, which has 189 GitHub stars. The repository holds 52 skills in this directory. The repository was last updated on August 5, 2026.

Source: kid-sid/claude-spellbook on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.