I do this a lot and you have to be really careful to clean these up or qualify/steer agents around them. They’ll often be very emphatically confident about some assumption or implication they made, and if another agent stumbles upon them they’ll get mislead.
They don’t really know what they’re handing off or what you’re trying to actually do, so in a sense it’s not a grounded task for them. Actually, if you think about it, any scenario in which a handoff doc might be valuable is probably almost always better as a subagent thread, because you are paying the same amount of read/write tokens but you can clear things up synchronously.
I’ve found two-way message passing (each get their own write file, they read each others) to work much better because the communication is more grounded in actual coordination/work. You can also give each an inbox so that multiple can write to it. If you do the “progressive disclosure” right it scales subquadratically because they only read/write to others when it’s relevant to what they’re working on.
But IMO “write a handoff” is a trap, as a human you end working in some kind of robot-graffiti codebase full of junk, and it ends up being a booby trap for agents literally within days.
I agree that if a sub agent could work then handoff is the wrong skill. These docs on the site agree too:
> What it buys is portability, not compression. That makes the skill narrower than it sounds. You need a file only when the work has to travel — to a new harness, a new directory, a colleague, or a side task you want to fork off. If nothing is travelling, you do not need a handoff: staying in the session, /clear, a subagent and /compact cover the ordinary end-of-phase case, and /compact covers it more often than this skill does.
No, but after looking it up, his skill doesn't differ that much from how I do it, with prompting the agent to boil down the whole conversation into a handoff prompt for context to next agent.
I agree. If you use the AI for (4), it's pretty much guaranteed to hallucinate whatever it wants and then approve it. For small projects, it might be good enough. For anything serious, it's not.
I find I get the best results when I just use it for (3), and sometimes a bit for (2). Going in with at least an idea of how to make it work has the best chance of ending up with a good changeset. And if you already know how to make it work, don't leave it to chance. Tell the LLM what to do, then let it do it.
I definitely appreciate being told "I don't know", but I've found in business settings that people expect to get reprimanded for saying that more than a couple times a year, and they refuse to say it.
They will invent crazy workarounds to avoid those 3 words.
Even if I ask "Do you know X?" they will not just say "no" most of the time, unless it's really outside their wheelhouse. If they think they should know it, they'll spit out statements worthy of an LLM.
And I admit, I felt the same at first. The first few times I told the CTO (my boss) that, I cringed. But he just told me to put aside time to research it. He knew I couldn't know everything, especially about things that we hadn't done before.
It's also not worth posting "I tried didn't work" because nobody knows what you tried. There is zero information in it, and it's a waste of bits that just pollutes the discussion.
It seems like that, but it's not. When trying to figure out a problem, even that tiny bit of information is worthwhile. If nobody else has posted it, it's the first indication that it doesn't work.
If others have posted, it's an indication that it's a wider-spread problem than you knew.
I'd still rather have more information, and I look down on people who only post something that useless. But it does have information I've used to figure problems out.
If it was actually a $2 part, I'd agree with you. But it's enough that it's probably worth returning, especially since he had to try a few to get it right, and then he can return them all at once.
It's not his fault if it ends up in the landfill. That's on Amazon. Also, they have discount stores they ship returned stuff to before it hits the landfill.
In Chrome, I just right-clicked the link above and hit "open in split view" and it did.
It was 50/50, with HN on the left, so maybe it's not as easy to read the post in smaller windows. Otherwise, seems to provide the same service, essentially.
I've been using Matt Pocock's skills at home, and they seem pretty great. He makes a great case for them vs other skills in his videos. I don't remember the exact arguments, but basically they're designed to be called by the user instead of called automatically, and that makes them take less context merely because they exist.
I've also found that they tend to coerce the programmer into thinking about the end result, rather than try to push them out of that role. His grill skills are about making sure the actual requirements are known, and his prototype skill can help explore things that need to be experienced to make a hard decision on.
reply