fla-design-coverage

Defines contract-first design and coverage requirements for FLA kernel and numerical changes.

5.7k|685|Updated Dec 20, 2023
One-click install
npx skills add https://github.com/fla-org/flash-linear-attention --skill fla-design-coverage
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fla-design-coverage
Source: https://github.com/fla-org/flash-linear-attention/tree/main/.agents/skills/fla-design-coverage
Command: npx skills add https://github.com/fla-org/flash-linear-attention --skill fla-design-coverage

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Kernel and numerical changes in the flash-linear-attention library can silently break supported configurations, change tolerances, or regress performance. This Skill enforces a contract-first design discipline before implementation so every reachable configuration is classified, budgeted, tested, and benchmarked.

Core Features & Use Cases

  • Contract cell enumeration: Enumerate every reachable combination of operator, backend, leaf pipeline, chunk geometry, bound regime, routing capability, dtype staging, and input numerical domain, with each row ending in an optimized path, existing fallback, or explicit unsupported error.
  • Numerical budgets per stage: Record load, operand, accumulation, store, range, and error budgets for each leaf stage in both forward and backward directions, with documented algebraic derivations for safety thresholds.
  • Three-layer coverage model: Separate production-representative hard gates, public-contract boundary gates, and beyond-contract adversarial coverage, with route-parity tests when multiple routes claim the same cell.
  • Use Case: Before adding a new TileLang backend for Gated DeltaNet, use this Skill to build the contract table, record per-stage numerical budgets, define fallback semantics, and freeze the benchmark baseline.

Quick Start

Ask the AI to apply the fla-design-coverage contract process to plan a new kernel backend or numerical change before writing any implementation code.

Frequently Asked Questions about fla-design-coverage

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

FAQPage Schema
How do I design a new kernel backend for flash-linear-attention?

Start by enumerating every reachable contract cell across operator, backend, chunk geometry, dtype staging, and bound regime. Classify each cell as an optimized path, existing fallback, or explicit unsupported error, then record numerical budgets and coverage before implementing.

What is a contract cell in FLA kernel design?

A contract cell is one reachable combination of operator, backend route, leaf pipeline, chunk geometry, bound regime, routing capability, dtype staging, and input numerical domain. Each cell must end in exactly one disposition: optimized path, existing fallback, or explicit unsupported error.

How do I handle numerical tolerances when changing kernel precision?

Record forward and backward budgets per leaf stage covering load, operand, accumulation, store, range, and error. Changing compute precision or relaxing a committed tolerance requires the RFC process in AGENTS.md, with tolerance changes landing in a separate commit.

Does this design process cover fallback and dispatch behavior?

Yes. A fallback counts only when it preserves return structure, output dtypes, autograd behavior, and the cell's oracle within tolerances, verified by a route-parity test. Under context parallelism, routing decisions must be identical on every rank using a collective accept check.

When should I benchmark kernel changes in FLA?

Benchmark production-dispatched cells first, recording oracle, effective arguments, input distribution, baseline latency, environment, and commit SHA. Then benchmark public-contract boundaries that change routing, chunk geometry, dtype staging, or expected performance.