6 ms·

Callable skills can’t activate on a schedule or listen for events. Making a daemon which invokes other callable skills is a great use case! I’m an eng on the t

Callable skills can’t activate on a schedule or listen for events. Making a daemon which invokes other callable skills is a great use case! I’m an eng on the team that built this, in full disclosure.

Bootvis 6mo ago
I do really like the idea. But pardon my ignorance, but one could quite easily roll this themselves? Script the hooks and fire off a headless agent with a hook specific prompt.
- rybosome 6mo ago
  Very fair question. One could build a simple version of this easily - e.g. setup an endpoint that listens for the particular event you are concerned with, and fire off the headless agent with your hook specific prompt - but the amount of work involved to listen for that particular event while filtering out noise and orchestrating the task is actually not trivial. Plus, that involves writing a lot of code. It's really magical to express all of this in natural language. For example, this is the YAML frontmatter for a a daemon that keeps a GitHub PR in a mergeable state in the event of CI failures or branch base changes. --- id: pr-mergeability purpose: Keep non-draft pull requests mergeable and CI-green without changing PR intent/scope, while staying anchored to one trigger context per run. watch: - Branch sync and update events on non-draft PRs. - Check-status signals on non-draft PRs for checks that affect mergeability. routines: - Resolve mechanical merge conflicts when the safe resolution is clear and preserves PR intent/scope. - 'Apply low-risk mergeability fixes: snapshot updates, lockfile drift fixes, lint autofix, and flaky-test retries when tied to the trigger context.' - Escalate semantic/intention conflicts between base and branch instead of auto-resolving. deny: - When triggered by a check-status signal, do not fix or comment on unrelated failing checks. - Do not open new pull requests or new issues. - Do not review, approve, or request changes on pull requests. - Do not implement review-comment suggestion patches. - Avoid force-push by default; if force is absolutely required, use `--force-with-lease` only after fresh remote verification. - Do not make changes beyond mergeability maintenance. --- Note the lack of any code or required knowledge of GitHub webhooks.
  - scriptingLLM 5mo ago
    Seems the markdown input, code output is a very common theme, I use OpenSoucreContracts(https://github.com/s1ugh34d/osc https://github.com/s1ugh34d/osc) to have LLM's build software, but building the harness into the contracts is elegant. Combined with prose I sort of have this. With LLM's and the sandbox life, software generation is coming.
- viktorianer 5mo ago
  [dead]
acron0 6mo ago
> Callable skills can’t activate on a schedule or listen for events I feel like they can. cron and git hooks have existed for a long time.

Bootvis 6mo ago

I do really like the idea. But pardon my ignorance, but one could quite easily roll this themselves? Script the hooks and fire off a headless agent with a hook specific prompt.

rybosome 6mo ago
Very fair question. One could build a simple version of this easily - e.g. setup an endpoint that listens for the particular event you are concerned with, and fire off the headless agent with your hook specific prompt - but the amount of work involved to listen for that particular event while filtering out noise and orchestrating the task is actually not trivial. Plus, that involves writing a lot of code. It's really magical to express all of this in natural language. For example, this is the YAML frontmatter for a a daemon that keeps a GitHub PR in a mergeable state in the event of CI failures or branch base changes. --- id: pr-mergeability purpose: Keep non-draft pull requests mergeable and CI-green without changing PR intent/scope, while staying anchored to one trigger context per run. watch: - Branch sync and update events on non-draft PRs. - Check-status signals on non-draft PRs for checks that affect mergeability. routines: - Resolve mechanical merge conflicts when the safe resolution is clear and preserves PR intent/scope. - 'Apply low-risk mergeability fixes: snapshot updates, lockfile drift fixes, lint autofix, and flaky-test retries when tied to the trigger context.' - Escalate semantic/intention conflicts between base and branch instead of auto-resolving. deny: - When triggered by a check-status signal, do not fix or comment on unrelated failing checks. - Do not open new pull requests or new issues. - Do not review, approve, or request changes on pull requests. - Do not implement review-comment suggestion patches. - Avoid force-push by default; if force is absolutely required, use `--force-with-lease` only after fresh remote verification. - Do not make changes beyond mergeability maintenance. --- Note the lack of any code or required knowledge of GitHub webhooks.
- scriptingLLM 5mo ago
  Seems the markdown input, code output is a very common theme, I use OpenSoucreContracts(https://github.com/s1ugh34d/osc https://github.com/s1ugh34d/osc) to have LLM's build software, but building the harness into the contracts is elegant. Combined with prose I sort of have this. With LLM's and the sandbox life, software generation is coming.
viktorianer 5mo ago
[dead]

acron0 6mo ago

> Callable skills can’t activate on a schedule or listen for events I feel like they can. cron and git hooks have existed for a long time.