fla-mr-readiness

Validates pull requests against contribution guidelines, test plans, and benchmark evidence requirements.

Updated Aug 18, 2026
One-click install
npx skills add https://github.com/weichengz0616/fla --skill fla-mr-readiness-weichengz0616
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fla-mr-readiness
Source: https://github.com/weichengz0616/fla/tree/main/.agents/skills/fla-mr-readiness
Command: npx skills add https://github.com/weichengz0616/fla --skill fla-mr-readiness-weichengz0616

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Contributors to the Flash Linear Attention repository often open pull requests that miss required tests, lack benchmark evidence, or duplicate existing work, causing review delays and rejections. ## Core Features & Use Cases - Pre-flight Checklist: Walks through CONTRIBUTING.md compliance, change scoping, and duplicate PR detection using GitHub CLI searches. - Test Plan Enforcement: Locates and runs dependent tests affected by your changes, with guidance on handling flaky tests. - Benchmark Evidence Standards: Defines required performance evidence for kernel changes, including hardware, workload shapes, and before/after comparisons. - Use Case: Before opening a PR that modifies a Gated DeltaNet kernel, run through this checklist to confirm dependent tests pass, gather H100 benchmark numbers, and structure the PR body with summary, test plan, and benchmark sections. ## Quick Start Review my current branch changes and check whether my pull request is ready to submit according to the FLA contribution requirements.

Frequently Asked Questions about fla-mr-readiness

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

FAQPage Schema
How do I prepare a pull request for the flash-linear-attention repo?

Follow the pre-flight checklist: read CONTRIBUTING.md, confirm your change scope, search for duplicate PRs with gh pr list, run dependent tests, and gather benchmark evidence if you touched kernel code. Then structure the PR body with summary, test plan, and benchmark sections.

How do I find which tests are affected by my code changes?

Run python scripts/find_dependent_tests.py with your changed file or directory as the argument. Execute those tests locally and ensure they pass before opening the PR; if a test is flaky, retry once and explain persistent failures in the PR.

What benchmark evidence is required for kernel changes in a PR?

Include before and after throughput or latency on the same hardware, the workload shape (batch, seq_len, heads, dims, dtype), the benchmark command used, and a conclusion. Cover dense and varlen workloads where applicable, and summarize any NCU profiling.

Can I commit NCU profiling reports to the repository?

No. Do not commit .ncu-rep files or raw profile dumps. Summarize the profiling results in the PR body and keep the artifacts local.

Should I use torch.cuda checks directly in tests?

No. Use the device and platform wrappers from fla.utils such as device, device_platform, IS_NVIDIA, IS_AMD, and IS_INTEL. If existing wrappers are insufficient, add a small helper to fla.utils first.