Check whether machine learning training is available for a completed Itô GPU booking. Training is currently unavailable; the skill explains this limitation and documents the requirements for a future confirmed handoff of a training plan.
Inspect the availability of ML training on a completed Itô compute booking and, when the canonical backend becomes available, hand off an explicitly confirmed training manifest. Use after ito-compute has booked GPU nodes and the user wants pre-training, fine-tuning, or RL on that metal. ECC implements no training stack of its own.
ito-training checks whether machine learning training is available on an already booked Itô GPU environment. Training is currently unavailable. The skill explains that limitation and organizes the requirements for a future handoff. Its scope includes pre-training, fine-tuning, and reinforcement learning, but it cannot currently run any of them.
The planned training manifest is a JSON document describing the training work. It is designed to include the model revision, data references, training objective, budget ceiling, and policy for saving progress.
Use it after completing a GPU booking with ito-compute when you want to know whether training can begin in that environment. It also helps clarify booking validity, costs, and confirmation requirements for future execution.
The current workflow stops before authentication or command execution. It does not substitute local training or SSH operations. Future execution also requires a server-verified booking and separate confirmation tied to the training details and cost. Credentials are excluded from manifests and conversations.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI rated this skill on four points using only the contents of its SKILL.md. Stars and popularity are not taken into account.
The total counts each point as A = 25, B = 15, C = 5. Rated by AI (OpenAI Codex) as of Oct 19, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
ito-training is the canonical ECC skill for training on Itô compute. ECC
never runs a trainer, scheduler, or data pipeline of its own; it never books,
reserves, or spends. This skill chains off a completed booking from
ito-compute.
Managed training is unavailable today. The ECC bridge exposes only login,
logout, auth, find, status, and explicitly gated evals. It has no
train verb, and the canonical CLI's run verb and desk training-run
backend remain scaffolds. The locally enforceable guarantee is that ECC rejects
train before resolving or spawning the credential-bearing canonical client.
Therefore stop before authentication or any command invocation. Report the missing capability and return to the originating agent. Never substitute a local trainer, SSH helper, browser workflow, or purchase endpoint.
When training is implemented, its first gate is a server-verified completed booking. Harness memory, an RFQ, a quote, node IPs, or SSH access are not proof of entitlement. The backend must return fresh training eligibility bound to the authenticated account, booking, GPU topology, region, fabric, and term. Expired, revoked, mismatched, incomplete, or already-released bookings fail closed before confirmation.
The intended command name is train. The future handoff must be equivalent to:
ecc ito train \
--booking <server-verified-booking-id> \
--manifest <absolute-reviewed-json-file> \
--confirmation-ref <opaque-non-authorizing-reference> \
--idempotency-key <stable-retry-key> \
--json
The reviewed manifest must identify the model size and revision, data references with decontamination provenance, training target, post-training recipe, budget ceiling in USD, checkpoint policy, and maximum incremental cost. No raw API key, SSH key, node password, bearer token, or dataset credential belongs in arguments, manifests, logs, MCP results, or chat.
The client must canonicalize the manifest path, reject symlinks, open a regular file without following links, require appropriate ownership and restrictive permissions, enforce a bounded size, and hash bytes from the opened descriptor. That digest must exactly equal the digest bound into confirmation before any workload mutation. A path swap, digest mismatch, oversized file, or mutable unsafe file fails closed.
The canonical API—not ECC—must own workload creation and return structured JSON
with ok, live_api_contacted, notice, and either data or error.
Training data must include stable booking, run, manifest, and idempotency IDs
plus a state enum. Errors must include a stable code and safe message without
secrets.
Before workload creation, require all of the following:
Authentication is identity, not workload authority. A login, API key, quote, or completed booking never substitutes for the training confirmation. Inspection and plan generation must not create a workload. Cancel and cleanup are separate mutations with their own scoped confirmation and idempotency boundaries.
The production surface is incomplete until the same canonical client exposes tenant-scoped status, logs, metrics, checkpoint listing, cancel, and cleanup. Every operation needs bounded connect and overall timeouts, revocation-aware errors, and structured output. After an ambiguous transport failure, query status by the idempotency key before retrying; never create a second run merely because the first response was lost. A revoked credential stops polling and returns control to the originating agent without starting login automatically.
Report stage gates honestly; never override a failed eval gate. Cleanup must be observable and must not release or modify the underlying booking unless that separate economic action was explicitly authorized.
These stages describe the future backend (Layer 0.3), not code that exists in ECC:
The backend emits desk telemetry (goodput, interruption rate, checkpoint bandwidth) so the desk prices training blocks honestly.
Until every gate and lifecycle operation above exists in the canonical runtime, this skill remains a fail-closed availability check and documentation handoff.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Design and audit interfaces for Web, iOS, and Android using WCAG 2.2 accessibility guidance. Check screen-reader labels, keyboard navigation, contrast, and control sizes to identify barriers and guide implementation for people using assistive technology.
Investigate unreliable AI agents across 12 layers, including instructions, memory, tool execution, and display. Use code and logs to trace failures, rank findings by severity, and produce an ordered repair plan that prioritizes code changes.
Compare coding agents on tasks from your own codebase. Define success checks, run agents in separate Git working directories, and report pass rates, available API costs, completion time, and consistency across repeated trials.
Design and refine an AI agent’s available actions, tool inputs, and result formats. Define recovery steps for errors, manage the information kept in context, and evaluate changes through completion rates, retries, and cost per successful task.
Diagnose failed AI agent runs by capturing errors, checking likely causes, and choosing small, reversible recovery actions. The workflow produces a structured report of the failure, recovery steps, and evidence, helping explain repeated retries or stalled progress.
Diagnose AI agent runs that fail repeatedly, loop through tools, or lose track of the task. Capture errors and environment details, test a focused recovery action, and produce a report explaining the evidence and outcome.