Talk about “list of prime factors of”. This can be safely simplified to “prime factors of”. No need to talk about “lists” here and conflict with track-specific terminology.
State that “The next possible factor is 4. 4 does not go cleanly into 5”. That’s a mistake. 4 cannot possibly be a factor since it’s not prime.
The example is too short and most likely difficult to follow for those who aren’t familiar with the math
I think “next possible” would be “next potential”, as it is not possible, with what we know, but would be the next thing to check, so potential until we know that it is not.
Also, consider it, as a problem solver, to be “Boss Speak” (or “client speak”) which is not always the most technical, the most accurate, the most correct.
For example “list of prime factors of” is not likely to be programming data structure “list” but rather just the general “list”.
The mistake happens when it tries to divide 5 by 4, which is a composite number. First, we check if 4 is prime — it’s not — so there’s no reason to try dividing by it. But none of that is mentioned in the old instructions.
A different and more typical approach is to skip all composite numbers and iterate only through primes. This makes the example shorter while conveying the same idea: focus on primes, skip composites.
We, as maintainers, are aware of this, but most readers are not. Tracks that have lists but require a different structure need an append file to clarify that there is no error. Similarly, tracks that have lists but leave the return type open to the user also need clarification, as mentioning “lists” might mislead them into using them.
You want to create the PR (It seems to be in a “pre-PR” state. As a patch it is good.
I might consider not using the " ➜ " that is there, as mathematically it may mean something, but we can state “gives us” for clarify, instead, or maybe “results in”.