If your Nixpkgs input uses a specific Git branch, such as nixpkgs-unstable, it needs to be a supported release branch.

Don’t like this. Some projects are only intended to use nixos-unstable. And it wouldn’t make sense to expect users to override the flake’s nixpkgs input with .follows, if they use unstable, because often there are significant differences between code that uses stable and unstable. If the flake targets stable and this is overridden, it’s likely things will break.

Your Nixpkgs input must have been updated in the last 30 days.

Seems reasonable.

If your Nixpkgs input is a GitHub repo, it needs to have the NixOS org as the owner. In principle, you could have a Nixpkgs input owned by someone else, for example inputs.nixpkgs.url = "github:EvilCo/nixpkgs".

The reasoning behind this is valid but what if it is a project that needs a fork? This is probably rare, so I guess I’m okay with it.

All in all, I think these are the wrong checks to be doing. There are probably many other assurances that could be made, like correct output attributes (what is known of the official schema plus ones made standard by precedent), validate the values, and suggest making tests for certain common outputs.

The project makes me think that if it gains popularity and people start following these guidelines, you’ll see badges on repositories that make newbies think that’s the sanctioned way to do things. But there is no sanctioned way to do things yet, flakes are supposed to be freeform.

I think these checks need to be thought out more than they have been, and I think especially the first check has the potential to fragment the community more.

For businesses using Nix, maybe it makes sense.