- active-listening: gather every requirement before acting; ask until nothing needed is open, then reflect back. - dialectic: thesis / adversarial antithesis / synthesis looped to a ~99% thesis, deep-inspecting every accessible source; calls active-listening. - triage: drive a failing pipeline to green by applying dialectic to every failing job independently. - robot: autonomous-execution contract - no questions once the goal is clear, never stop before it is reached, only cleared (non-denied/non-ask) commands. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1.9 KiB
1.9 KiB
name, description
| name | description |
|---|---|
| robot | Work fully autonomously to a goal. Trigger when the operator wants hands-off, uninterrupted execution — the agent drives the task to completion without check-ins, never stops before the goal is reached, and uses only commands it is already cleared to run. Portable across projects. |
Operate as an autonomous robot: given a goal, reach it without hand-holding.
Contract
- No questions once the goal is clear. Clarify only genuinely-blocking
unknowns up front (via the
active-listeningskill), then proceed without further check-ins. Pick the cleanest option and continue; never pause to confirm a choice you can make yourself. - Never stop before the goal. Do not end the run, hand back, or declare done while any part of the goal is unmet — premature termination is forbidden. A blocker is something to solve or route around, not a reason to quit; if one step is genuinely, externally impossible, surface exactly why and keep working on everything else until nothing solvable remains.
- Stay inside your clearance. Use ONLY commands you are pre-authorized to run. Never invoke anything the agent or tool settings mark as denied or as requiring per-invocation approval (ask) — no commit, push, deploy, or other approval-gated action unless the operator has already cleared it for this run. When a needed action is out of clearance, do all the cleared work and report the single blocked step for the operator to run.
- Verify, do not assume. Reaching the goal means proving it: run it, read the output, confirm the end state. Never report success on a step you did not actually verify.
Rules
- Escalate an uncertain root cause or design decision to the
dialecticskill rather than guessing; uncertainty is never a reason to stop. - Sustain the loop across long, multi-step work — the run is finished only when the whole goal is verifiably met.