Menu
Checklist and workflow for preparing an MR/PR in the FLA repo. Covers CONTRIBUTING.md compliance, test plan, benchmark evidence, and PR body structure.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Guidelines for Ascend NPU kernel / Triton-Ascend backend performance work in the FLA repo. Covers profiling with torch_npu, PipeUtilization/MemoryUB CSV analysis, Cube/Vector/MTE/UB bottleneck diagnosis, and kernel optimization (UB tiling, grid splits, fusion/split, varlen, G_T_CONTIG gate loading, correctness gates). NPU kernels must not use num_warps/num_stages. Use when working on NPU profiling, kernel_details/op_statistic, aic_metrics, fla triton_ascend backends, g transpose stride-1, UB overflow, grid limits, or Ascend performance.
Disciplined, reproducible loop for making an FLA kernel faster (Triton, Gluon, TileLang, CuTe) without ever breaking or gaming correctness. Synthesizes the task-contract / three-phase / iteration-protocol / silent-bug-catalog discipline of agent kernel-optimization frameworks (KDA, the MLSys FlashInfer contest workflow, AKO4ALL/AKO4X), and anchors all of it on FLA's frozen pytest (forward AND backward, under NaN poisoning) as the immutable correctness gate. Use when iterating on `fla/ops/**` performance over multiple rounds.
Workflow for porting an existing Triton kernel in `fla/ops/**` to Gluon (`triton.experimental.gluon`) to gain explicit control over tensor layouts, shared memory, async data movement (cp.async / TMA), MMA (WGMMA / tcgen05), and scheduling (persistent kernels, warp specialization). Covers when a port is worth it, an incremental porting sequence that keeps numerical parity at every step, a Triton-to-Gluon API mapping, compile-time / autotune / smem-budget management for heavily unrolled kernels, and a pitfall checklist (proxy fences, mbarrier semantics, layout costs, bitwise-cancellation traps, NaN-poisoned OOB handling). Use when a Triton kernel is register-bound, when `num_stages` pipelining underperforms, or when Hopper/Blackwell features (TMA, TMEM, tcgen05) are needed.
Guidelines for NVIDIA GPU kernel / Triton / Gluon / TileLang / CUDA backend performance work in the FLA repo. Covers profiling workflow, hardware baselines, and MR-ready performance evidence requirements. Uses an installed ncu-report-skill when a task needs detailed Nsight Compute collection and diagnosis.
Guidelines for kernel correctness testing and coverage in fla/ops/** and related modules, including common Triton grid/addressing pitfalls. Helps decide what tests to add or run before an MR.
Workflow for FLA backend dispatch decorators and backend implementations. Use when touching fla.ops.backends, @dispatch-decorated functions, BaseBackend subclasses, backend verifier methods, backend env vars, or backend tests.
| name | fla-mr-readiness |
| description | Checklist and workflow for preparing an MR/PR in the FLA repo. Covers CONTRIBUTING.md compliance, test plan, benchmark evidence, and PR body structure. |
Use this skill before opening a pull request to make sure the change is well-scoped, well-tested, and well-documented.
Read CONTRIBUTING.md
main (or the target branch).Confirm change scope
Check for duplicate work
gh pr list --repo fla-org/flash-linear-attention --state open --search "<keywords>"
Run dependent tests
python scripts/find_dependent_tests.py <changed_file_or_dir>
Performance evidence (if touching kernel code)
fla-nvidia-performance skill for the full evidence requirements.Write PR summary
Code style review
CONTRIBUTING.md for Python style, docstrings, comments, and commit prefixes.fla.utils
(device, device_platform, IS_NVIDIA, IS_NVIDIA_HOPPER,
IS_NVIDIA_BLACKWELL, IS_AMD, IS_INTEL) instead of new direct
torch.cuda platform checks. Add a small fla.utils helper first when
the existing wrappers are not enough.## Summary
One-paragraph description of what changed and why.
## Test plan
- Unit tests added/modified: `<list>`
- Dependent tests run: `<list>`
- Varlen / CP / model tests: `<yes/no + details>`
## Benchmark / NCU
- Hardware: `<e.g., H100>`
- Workload: `<batch, seq_len, dtype>`
- Before: `<throughput or latency>`
- After: `<throughput or latency>`
- Conclusion: `<improvement / neutral / trade-off>`
## Breaking changes
- None / list any API or behavior changes.
Do not put raw performance numbers without context. Always include:
Do not commit .ncu-rep files or raw profile dumps. Summarize results in
the PR body and keep artifacts local.
No busywork PRs: bundle trivial cleanups into a substantive change; do not open a PR for a single typo unless it is part of a larger fix.