CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

fla-pr-readiness

Prepare or update an FLA pull request with focused scope, verified evidence, and the current repository template.

Quality

77%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/fla-pr-readiness/SKILL.md
SKILL.md
Quality
Evals
Security

FLA PR Readiness

Read CONTRIBUTING.md and AGENTS.md first. Use the current PR template for headings and checkboxes; contribution policy and template wording are not duplicated here.

Review scope and evidence

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.py

For 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.

Prepare and publish

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.

Repository

fla-org/flash-linear-attention

Path

.agents/skills/fla-pr-readiness/SKILL.md

Last updated
First committed

Is this your skill?

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.