The first answer explains that it was only supposed to trigger on error cases (no page specified) but due to an oversight also triggered if you specified a man page by the --path flag (rather than just the page name)
It's also great with TDD if you have decent coverage and want to maintain decent coverage.
One thing I dislike about TDD is I sometimes think better in code than use cases. And stuff like mocks etc take far longer to write than a 5 line fix. Say, I have a repo where it takes variable from source A when X happens, and source B when Y happens.
Now I can do reverse TDD. I write the code first. I highlight my code and tell Cursor to write the tests. I tag all the classes and models and other things that I want Cursor to mock. It writes the test, the tests pass, green. Then I stage the code that I wrote, and those tests should fail, red. It also finds all the dumb things I missed out on like imports.
So there, I have a pair programmer that writes the 300 lines of tests while I write the 5 lines of functional code, no worries about hallucinations and all.
>And stuff like mocks etc take far longer to write than a 5 line fix
If you test from the outside in and build up a library of functional and realistic fakes then over time then this gets quicker and easier.
Ideally I think people shouldnt use mock objects at all, ever - only fakes of varying realism at the edge of the project, populated with realistic data.
One reason for doing TDD is that it compels you to match a realistic test with a realistic scenario. I tend to find people lose that when they do test after, and they instead lock the test in to the current behavior of the code instead. This is not just tedious work, it's also harmful.
About the naming and the standard (it's still a proposal), see https://llmstxt.org/
There are also many discussions about llms.txt in HN ;)