library-qa

Execute scratch consumers to verify library behavior via JSON observations.

33|5|Updated Feb 28, 2026
One-click install
npx skills add https://github.com/kylesnowschwartz/ralph-ban --skill library-qa
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: library-qa
Source: https://github.com/kylesnowschwartz/ralph-ban/tree/main/skills/library-qa
Command: npx skills add https://github.com/kylesnowschwartz/ralph-ban --skill library-qa

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

When a library change breaks consumers, the failure often shows up only at integration time, so QA needs a fast, reproducible way to verify the library’s actual runtime behavior against the expected spec.

Core Features & Use Cases

  • Behavioral verification via scratch consumers: Generates a small one-shot program that imports the library, calls the API, and emits structured (JSON) observations for reliable parsing.
  • Change-focused scoping: Uses the recent changeset (git diff/log) to determine which exported symbols/types/behaviors to exercise when scope isn’t explicitly provided.
  • Language-appropriate execution: Supports Go, Ruby (gem vs Rails), and TypeScript with runner-specific gotchas and output discipline.
  • Evidence-driven verdicts: Captures stdout/stderr/exit codes, boot transcripts, parsed JSON envelopes, and a persisted verdict for APPROVE/REJECT/ESCALATE.

Quick Start

Use the library-qa skill to probe the changed exported surface by running a scratch consumer that calls the library API, prints structured JSON output, and produces a verdict from the parsed envelope.

Frequently Asked Questions about library-qa

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify library behavior after code changes to prevent integration failures?

You can verify library behavior by generating a minimal scratch consumer that imports the changed package, calls the API, and emits structured JSON observations to produce a reproducible APPROVE, REJECT, or ESCALATE verdict.

What is the best way to validate runtime semantics for a Go or Ruby module?

The best way to validate runtime semantics is executing a one-shot probe program that calls the module's API and captures structured NDJSON or final JSON envelopes, handling runner-specific setup and boot handling for Go, Ruby, or TypeScript.

How do I test only the changed exported surface of a TypeScript library?

To test only the changed exported surface, you can scope the verification by using the recent git diff or log changeset to automatically determine which exported symbols, types, and behaviors the scratch consumer should exercise.

Does library testing work with Rails-loaded code and require external dependencies?

Yes, library testing supports Rails-loaded code alongside standard gems and TypeScript modules, requires no external dependencies, and enforces side-effect isolation rules to ensure scratch-only probe code does not alter your environment.

How do I capture evidence for an API verification verdict?

To capture evidence for an API verification verdict, the probe runner parses structured JSON envelopes and records stdout, stderr, exit codes, and boot transcripts, persisting these artifacts alongside the final behavioral judgment.