language-performance-safety

Evaluate language and runtime changes for performance and safety with evidence.

4|Updated May 16, 2026
One-click install
npx skills add https://github.com/machenjie/rd-skills --skill language-performance-safety
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: language-performance-safety
Source: https://github.com/machenjie/rd-skills/tree/main/src/foundation/capabilities/language-performance-safety
Command: npx skills add https://github.com/machenjie/rd-skills --skill language-performance-safety

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It prevents performance regressions and safety bugs by forcing language- and runtime-specific changes to be validated with evidence rather than intuition.

Core Features & Use Cases

  • Evidence-first performance validation: requires profiling, traces, allocation logs, and system-level benchmarks to justify optimizations.
  • Runtime safety guardrails: covers allocation/GC behavior, event-loop and scheduler interaction, async cancellation, blocking work, and unsafe/FFI invariants.
  • Bounded resource practices: mandates explicit ceilings for queues, collections, batches, pagination windows, retry accumulators, caches, and fan-out to avoid OOM and denial-of-service patterns.

Quick Start

Ask the skill to evaluate your proposed hot-path or safety-critical change and return the measurement plan, required evidence, and accept/reject criteria.

Frequently Asked Questions about language-performance-safety

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

FAQPage Schema
How do I validate runtime performance and safety changes for hot paths?

Validate runtime performance and safety changes by requiring explicit measurement contracts with profiling, stress evidence, and bounded growth surfaces before approving hot path modifications.

What measurement evidence do I need to prevent GC and allocation regressions?

To prevent GC and allocation regressions, you need profiling traces, allocation logs, and system-level benchmarks to justify optimizations and document correct cleanup invariants.

How do I enforce bounded resource limits for queues, caches, and concurrency primitives?

Enforce bounded resource limits by mandating explicit ceilings for queues, collections, batches, retry accumulators, caches, and fan-out to avoid OOM and denial-of-service patterns in concurrency primitives.

Does async cancellation require special safety validation for event-loop and scheduler interaction?

Async cancellation requires safety validation covering event-loop and scheduler interaction, blocking work, and unsafe/FFI boundaries to ensure correct cleanup and documented invariants.

When should I not optimize native interop or unsafe FFI boundaries without stress evidence?

You should not optimize native interop or unsafe FFI boundaries without stress evidence, as validating runtime safety changes requires bounded growth surfaces and clearly documented invariants to prevent regressions.