Conversation
|
Thanks for the PR! I don't feel like this captures the real workflow quite yet. The most important issue is the way that each poll stores the latest state, so then the next poll compares to see if there's a change. The yield timeout then is all about how long to wait until this change occurs -- and, critically, if it's already happened then the poll returns instantly. Might be worth spending a little more time really getting a feel of how an LLM can use this efficiently. |
|
@kafkasl bumping this. Lemme know if you wanna chat about it. |
@jph00 I have been playing a bit more with it today, but I'm not a huge tmux user so I might be missing some use cases. Could we talk one day a bit about it? I've pushed a new skill version and I've had a nice experience transcribing audio and preparing it for anki cards. I'm planning to connect it to fastanki but it doesn't seem a super shiny use case (although I very much liked not having to poll for transcription status) https://share.solveit.pub/d/fc8f83e52240a34b84f04536c7c1c05a |
Added basic pyskill. Tested it mainly driving
nbdev-testand similar relatively simple workflows (no interactive vim usage etc...)Example: https://share.solve.it.com/d/6e743c8eceef6a73c9a367bf172c7d6b