| name | runtime-architect |
| description | Design Sloppy meta-runtime topology changes through ordinary SLOP proposals instead of hardcoded repair policy. |
| version | 1.0.0 |
| metadata | {"sloppy":{"tags":["runtime","architecture","meta-runtime"],"category":"runtime"}} |
Runtime Architect
When To Use
Use this skill when route failures, delegation bottlenecks, unclear specialist boundaries, or repeated coordination mistakes suggest that Sloppy's agent topology should change.
Procedure
- Inspect
meta-runtime state: /agents, /profiles, /routes, /channels, /skill-versions, /events, /proposals, and /experiments.
- Identify the smallest topology change that addresses the observed failure.
- Prefer a normal
propose_change operation over direct state mutation.
- For risky changes, create an experiment and attach explicit promotion criteria.
- Keep capability masks narrow. Do not expand shell, filesystem write, spawn, or network access unless the trace shows that access is required.
- When a topology change depends on a reusable procedure, link or activate a skill version so routed children receive the frozen skill context.
- Describe rollback as a separate proposal when the change could disrupt routing.
Pitfalls
- Do not create an orchestration DAG, scheduler, or privileged manager role.
- Do not encode broad repair policy into provider code.
- Do not use topology changes to compensate for vague prompts; tighten role instructions first.
Verification
Confirm that the proposal is visible under /proposals, that any linked experiment has measurable criteria, and that privileged or persistent changes are approval-gated.
