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.

Más de este repositorio

mismo repositorio

persistent-goal

devteapot/sloppy

Drive Sloppy persistent session goals through extension-backed metadata instead of hardcoded planning policy.

2026-05-082

dual-model-development-loop

devteapot/sloppy

Use GPT-5.5 and Claude Opus 4.7 ACP sub-agents in an iterative planner/auditor/implementer loop for development tasks.

2026-05-062

delegation-orchestration

devteapot/sloppy

Coordinate Sloppy child agents through the delegation provider without polling, including parent-side parallel work, result retrieval, and child-session cleanup.

2026-05-062

skill-curator

devteapot/sloppy

Review skill usage, failures, and repeated procedures, then propose minimal skill changes through the skills provider.

2026-05-062

runtime-route-repair

devteapot/sloppy

Diagnose failed meta-runtime route dispatch and propose minimal route or endpoint repairs.

2026-05-062

topology-experiment-evaluator

devteapot/sloppy

Evaluate meta-runtime topology experiments using explicit evidence and promotion criteria.

2026-05-062

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.