Preflight
Use the package root containing the user-facing cli-exercise/SKILL.md.
This module is bundled with that skill and is loaded as a referenced resource.
Check without changing the machine
If the caller supplies a ready receipt already checked for this task, read and
reuse it when its selected tools and probed formats match the case. Do not repeat
probes or propose installation just because the receipt was produced elsewhere
in the same task. Recheck if its current applicability is uncertain. A receipt
does not grant installation or test-resource authority.
Normal session delivery, even for one case, needs MP4 chapter intermediates;
confirm MP4 capability as well as any requested GIF output.
When a check is needed, first follow the offline-first Go build instructions in
the prerequisite reference. Build the helper
once for this task, outside the skill and repository, then use that executable:
<helper> --skill-root <package-root> preflight check --output <workspace>/preflight.json
Keep Go toolchain auto-downloads and module downloads disabled on the first
build. If a locked dependency is missing from the selected cache, show the
packages, sources, destination and build command, then ask before enabling its
download. A compile error is not permission to try an online build.
Explicit existing Node module, executable, and font paths can be supplied using
the documented overrides. Never embed operator-specific paths in the skill.
Check usable capabilities: the Node/Tuistory API and native PTY,
ffmpeg/ffprobe and requested encoders, and actual Go font rasterization.
Also identify any case-specific shell, editor, or executable. A command on PATH
does not prove that its native bindings or required API work.
Ask before installing
When a dependency is missing or incompatible:
- Check for a suitable existing installation before proposing changes.
- Use the pinned manifests and platform context to propose exact setup commands.
Show versions, sources, destinations, and any system/global changes.
- Obtain caller approval for those commands.
- Execute only the approved setup, then repeat the capability checks.
Use an appropriate dependency location outside the skill and repository.
Do not globally update tools or change project dependency manifests by default.
If system installation or authentication is required, state that separately.
Never enter an OS password or turn a failed privileged command into success.
If approval is declined, unavailable, or the install/recheck fails, report
blocked with the precise remedy. Preserve diagnostics and any partial-install
facts. Do not silently change recorders, output formats, or supplied cases.
The helper only checks capabilities. Perform approved setup with the appropriate
package manager.
Keep authorization separate
Dependency approval does not authorize GitHub writes, filesystem changes outside
the workspace, credential changes, purchases, or other effects. Obtain the
required case-specific authorization separately and record its actual source.
The resulting receipt identifies tools used by the runtime and renderer.
It is readiness evidence, not an OS sandbox or a permission bypass.