verify-all-runtime-sinks

Verifies that runtime-affecting changes propagate to every consumer, adapter, and cached value.

1.3k|142|Updated Jun 1, 2026
One-click install
npx skills add https://github.com/MiniMax-AI/minimax-code --skill verify-all-runtime-sinks-minimax-ai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: verify-all-runtime-sinks
Source: https://github.com/MiniMax-AI/minimax-code/tree/main/.agents/skills/verify-all-runtime-sinks
Command: npx skills add https://github.com/MiniMax-AI/minimax-code --skill verify-all-runtime-sinks-minimax-ai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Schema, prompt, identity, adapter, cache, or rename changes often pass parser-level tests while stale behavior persists in alternate entry points, persisted state, or generated artifacts. This Skill prevents incomplete runtime validation by systematically mapping every consumer a changed value can reach. ## Core Features & Use Cases - Consumer Mapping: Marks each affected dimension (parser-to-runtime, alternate entry points, generated/cached values, fixtures, string remnants) as covered, not applicable, or unknown with reasons. - Old/New Token Search: Searches for both old and new identifiers beyond source files, including ignored build outputs and raw serialized shapes. - End-to-End Verification: Exercises runtime paths through final consumers such as TUI, exec, ACP, and task/session launches rather than stopping at parser tests. - Use Case: After renaming a configuration field, use this Skill to confirm the new name propagates through launch options, adapters, prompt caches, and historical-data importers before declaring the change complete. ## Quick Start Verify that my recent schema field rename reaches every runtime consumer, including adapters, caches, and persisted state, and report any remaining old-token hits.

Frequently Asked Questions about verify-all-runtime-sinks

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

FAQPage Schema
How do I verify a schema change reaches all runtime consumers?

Map each consumer dimension (parser-to-runtime, alternate entry points, cached values, fixtures, string remnants) and mark it covered, not applicable, or unknown. Then exercise the affected runtime paths through their final consumers rather than relying on parser tests alone.

Why do parser tests pass while old behavior persists at runtime?

Parser tests only cover the first consumer of a changed value. Stale behavior can survive in persisted state, memoized objects, bundled prompts, compiled configuration, or adapters that bypass the tested path.

How do I search for old field names after a rename?

Search for both old and new tokens beyond source files, explicitly including ignored build outputs that ordinary repository searches skip. Inspect raw serialized shapes where types or casts can hide drift.

When is runtime verification considered complete?

Verification is complete only when no relevant consumer remains marked unknown and no unexplained old value persists. Narrower passing checks should be reported alongside the remaining gap rather than declared as full coverage.

Should I clear user sessions or caches during verification?

No. Inspect or regenerate caches using isolated test state instead. Clearing a user's sessions or configuration is not an acceptable part of the verification process.