Strengthen wording around skill usage and generators

[lucieleblanc]

This PR aims to address the top 2 issues from last night's test runs:

1. Not finding the skill.
   I want to fix this by explicitly saying the skill must be used in the top-level AGENTS.md, in the hopes that this will push the agent to proactively look for it.

2. Claiming all commands are static and not writing generators at all.
   I think more note-taking about this up-front in the research phase will alleviate this. Specifically, I include direct links to the fish generators and instruct the agent to read them as part of the research phase.
   I also changed the wording around generators to plural to reinforce that multiple generators may be needed.

(Plus issue 5, including screenshots for flags, which is unnecessary.)

VERY open to suggestions, wording edits, etc.

[vkodithala]

LGTM, added a small note but dogfooding is the way to go here!

[vkodithala]

I don't think this hurts, but you shouldn't need to include this in an AGENTS.md. The way that progressive disclosure works, the agent receives a list of skill names/description as part of its system prompt, and should invoke them based on how closely a query/task matches a skill description.

[lucieleblanc]

I thought this was the case as well, but I became skeptical after the vast majority of the test runs I did last night didn't find it on their own. I suspect it's because the skills never get loaded into the agent's context if it never cds into the project directory. See this run -- it looks like the generic agent started from Linear doesn't have any of its project-specific skills available at first and only discovers them when it changes its working directory.

I'm going to keep this wording for now and see if it helps! I'm hoping we can find general solution for this issue eventually, too.

[vkodithala]

Hm, AFAIK that shouldn't be the case. Ian made a change that loads skills into agent context directly from repos added to a cloud environment. Will investigate.