| name | automation-engineering |
| description | Replace repeated manual operational work with safe scripts, queued tasks, or scheduled CTOX work. Use when the same host or admin procedure keeps recurring, an incident pattern should become automation, or a manual checklist should be turned into tested repo-managed automation without bypassing the existing CTOX queue and schedule flow. |
| cluster | mission_orchestration |
Automation Engineering
CTOX Runtime Contract
- Task spawning is allowed only for real bounded work steps that add mission progress, external waiting, recovery, or explicit decomposition. Do not spawn work merely because review feedback exists.
- The Review Gate is a quality checkpoint, not a control loop. After review feedback, continue the same main work item whenever possible and incorporate the feedback there.
- Do not create review-driven internal work cascades. If more work is needed, reuse or requeue the existing parent work item; create a new task only when it is a distinct bounded work step with a stable parent pointer.
- Every durable follow-up, queue item, plan emission, or internal work item must have a clear parent/anchor: message key, work id, thread key, ticket/case id, or plan step. Missing ancestry is a harness bug, not acceptable ambiguity.
- Rewording-only feedback means revise wording on the same artifact. Substantive feedback means add new evidence or implementation progress. Stale feedback means refresh or consolidate current runtime state before drafting again.
- Before adding follow-up work, check for existing matching internal work, queue, plan, or ticket state and consolidate rather than duplicating.
Automation design and operating assumptions count as durable mission state only when they are reflected in the CTOX runtime store. Reusable operating procedure must be promoted into source skills, skillbooks, runbooks, or runbook items. Workspace plans or notes do not count as durable knowledge by themselves.
Use this skill when repeated operational work should become a repo script, queued work step, or scheduled CTOX task.
Do not use it for live incident handling or one-off system changes:
- use
incident_response for active stabilization
- use
change_lifecycle for deliberate state changes
- use
ops_insight for reporting that does not yet justify automation
This skill uses the shared CTOX knowledge store via skill_key=automation_engineering.
Operating Model
Use CTOX queue, schedule, plan, and harness-mining commands as the execution boundary. Do not execute embedded scripts/ helpers from this system skill; if an automation operation lacks a CTOX command, add that command before relying on it.
Tool Contracts
automation.capture_rawautomation.store_captureautomation.store_graphautomation.queryautomation.bootstrap_recipe
Workflow
- Confirm the pattern is really repeated.
- Capture current CTOX queue/schedule/plan state and repo automation hints.
- Persist a
task_pattern, automation_recipe, workflow_version, test_evidence, and adoption_note.
- Keep the interface explicit and dry-run first.
- Route real rollout work into
change_lifecycle.
Operator Feedback Contract
Answer for the operator first.
Use these exact headings:
**Status****State****Scope****Autonomous Actions****Escalation****Current Findings****Next Step**
State must be one of:
proposedpreparedexecutedblocked
Automation design, recipes, schedules, and test artifacts are prepared. Only call it executed when the recurring or scripted path was actually activated or changed.
Completion Gate
Do not finish the reply until all of the following are true:
- all seven headings are present
- proposed automation and active automation are clearly separated
- test evidence is mentioned before claiming the automation is ready
- if rollout is deferred, a durable next work step exists instead of an implied continuation
Guardrails
- No hidden loops.
- Keep recurring work in CTOX schedule and queue.
- Do not call something automated until it is testable and rerunnable.
Resources
