Prepare or update an FLA pull request with focused scope, verified evidence, and the current repository template.
77%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Low
Low-risk findings worth noting
Fix and improve this skill with Tessl
tessl review fix ./.agents/skills/fla-pr-readiness/SKILL.mdRead CONTRIBUTING.md and AGENTS.md first. Use the current PR template for headings and checkboxes; contribution policy and template wording are not duplicated here.
Read the complete diff against the PR base and audit affected shared callers. State its concrete outcome in one sentence and separate independent work. Check existing issues/PRs and the applicable design discussion. Follow scope and size for a cohesive change above the normal limit, and public compatibility when interfaces or defaults are affected.
When a change needs splitting or dependent PRs need a native GitHub stack, use PR stacks to choose boundaries, reuse existing PRs, and verify the published stack.
For code changes, discover dependent tests and run the relevant targets. For example:
python scripts/find_dependent_tests.py fla/ops/kda/chunk.py
FLA_CI_ENV=0 pytest tests/ops/test_kda.py
pre-commit run --files fla/ops/kda/chunk.py tests/ops/test_kda.pyFor documentation-only changes, validate links, examples, and formatting as described in Evidence by Change Type.
The dependency helper only lists tests. Check that regression coverage exercises the changed path and that required numerical comparisons passed, including supported gradients. Review new test functions and files against test organization and naming; use an existing test case where it fits. Record commands, tested revision, environment, and results; distinguish failures, skips, and unrun checks. Reproduce a failure on the baseline before calling it pre-existing.
For performance-relevant changes, collect same-hardware before/after measurements under Benchmarking and the relevant hardware skill. A neutral result needs numbers; explain inapplicable checks. Inspect the final diff for stale comments and unrelated changes, leaving scratch logs and raw profiles outside it.
Write for a reviewer who has not seen the conversation. Follow PR Description and Evidence by Change Type: explain the problem, resulting behavior, affected users, and evidence. Include only useful rationale or limitations; omit file inventories and the history of attempts. Keep incomplete work in draft and leave claims and checklist items consistent with actual validation.
The check-pr-title workflow also checks the body and size exception on edits. Preserve template checklist wording and distinguish required items from conditional ones.
gh pr edit fails with this repository's classic-Projects integration. Write the complete body to a temporary file and update through REST:
gh api -X PATCH "repos/fla-org/flash-linear-attention/pulls/$pr_number" -F "body=@$pr_body_file"Confirm the published description, head revision, and checks. After review changes, rerun affected validation and update evidence that no longer describes the current code. Publishing and git operations remain subject to the user's authorization and repository rules.
fla-org/flash-linear-attention
9819311
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.