dsh-slopo agent
31991143e4
The three skills are ports of slopo's own agent configs, published user-invocable and NOT model-invocable. Slopo makes that choice upstream and the reason holds here: every one of these commands can spend minutes embedding, so a model that decides to "check for duplication" mid-task can do it repeatedly. settings goes through ctx.inject(['settings'], ...) rather than the top-level inject, so a profile without a settings provider still gets the tool and the skills and degrades to the composition config. A required dependency would have suppressed apply entirely -- a silent whole-plugin failure for an optional capability. The tool resolves the CLI, materialises the config, and runs the long actions as background jobs. Background is the right default because embedding takes minutes and slopo writes progress to a log file rather than stdout, so there is nothing to stream; the job handle carries the log path instead. Nothing is defaulted. Guessing an embedding backend would mean guessing where money is spent, so status says what is missing and configure sets it.