Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

ctl

Étoiles0

Forks0

Mis à jour25 juin 2026 à 15:16

Operate the funpack binary on a machine — install, update, roll back, pin, scan, and report status of the funpack toolchain on disk. Use when the user wants to install funpack, update/upgrade to the latest release, check which funpack version is installed or on PATH, pin or switch to a specific version, roll back a bad upgrade, or audit every funpack binary on the machine. Triggers on "install funpack", "update funpack", "upgrade funpack", "what funpack version", "funpack binary status", "scan funpack installs", "pin funpack to <version>", "roll back funpack", "funpack on PATH", "manage the funpack binary". Not for authoring funpack programs, engine/runtime code, or project scaffolding — those are funpack-project / funpack-engine-api / funpack-language.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

mjmorales

mjmorales/funpack

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Administrateurs de réseaux et de systèmes informatiquesProfessions informatiques et mathématiques·SOC 15-1244

Explorateur de fichiers

3 fichiers

SKILL.md

readonly

name

ctl

description

funpack:ctl — funpack binary systems operations

Install, update, roll back, pin, and audit the funpack binary on a machine. You decide which operation and whether to gate it; the bundled script scripts/funpackctl does the download/extract/symlink/version-compare mechanics.

Invoke the script with:

${CLAUDE_PLUGIN_ROOT}/skills/ctl/scripts/funpackctl <command> [args]

(In this repo's working tree that resolves to plugins/funpack/skills/ctl/scripts/funpackctl.) Always run scan or status first to learn the machine's current state before any mutating command.

The install model (read this before acting)

funpack ships as a single binary. Three channels can coexist on one machine, and scan reports all of them:

managed — this skill's prefix $FUNPACK_HOME (default ~/.funpack). Holds one dir per version under versions/<semver>/ and an active-version symlink at bin/funpack. Switching versions and rolling back are O(1) symlink swaps with no re-download. Only this channel supports rollback and instant version-pinning — it is the home for everything the user asks about updates/rollbacks/version-setting.
brew — brew install mjmorales/tap/funpack. Simple, but keeps no old versions, so it cannot roll back or pin.
dev-build — a binary compiled from a checkout. scan detects it at ./funpack.bin or ./cmd/funpack/funpack relative to the cwd (e.g. task binary output), never machine-wide.

Source of truth for releases: GitHub releases on mjmorales/funpack, binary line tagged v*, one asset per platform (macos-arm64, linux-arm64, linux-x64). Intel macOS has no prebuilt asset — build from source there.

Runtime prerequisite — SDL2. The run/live/attach verbs link SDL2 dynamically at a build-time-baked absolute path; the pure verbs (build/check/test/warden) do not. The prebuilt macOS binary resolves SDL2 through Homebrew's sdl2-compat (the maintained SDL2-ABI-over-SDL3 provider — Homebrew migrated the sdl2 formula to it), so a machine missing it dies in dyld before main with Library not loaded: …/libSDL2-2.0.0.dylib. Install the provider once — macOS brew install sdl2-compat, Linux apt install libsdl2-dev. funpack cannot self-diagnose this; the loader fails before any funpack code runs.

Critical PATH fact: what funpack actually runs is whatever PATH resolves first. A managed install/update only re-points ~/.funpack/bin/funpack; it does not change PATH or override a brew shim. If the user is on brew and you install into the managed prefix, funpack on PATH is unchanged until ~/.funpack/bin precedes brew on PATH (or you run funpackctl link). Always check status after a mutation and surface this if the on-PATH version did not move.

Intent → command

User wants	Command
"what version / is it current?"	`status`
"show me every funpack on this box"	`scan`
"what releases exist?"	`releases [N]`
"install funpack" / "install v0.10.1"	`install [<ver>]`
"update / upgrade to latest"	`update`
"switch to / pin v0.9.0" (already installed)	`use <ver>`
"undo that upgrade"	`rollback`
"list what I have installed"	`list`
"remove the old v0.9.0"	`uninstall <ver>`
"put funpack on my PATH"	`link [<dir>]`
"why isn't funpack working?"	`doctor`

Confirmation gates

Reads (status, scan, releases, list, which, doctor) run freely — never gate them. Gate the mutations that change which binary runs or destroy a cached version, using AskUserQuestion (binary confirm), and only when the consequence is real:

install / update / use / rollback — confirm once before running, stating the from → to versions. These are reversible (the prior version stays cached), so a single confirm is enough; do not re-gate each step of a multi-version sequence.
uninstall — confirm; it deletes a cached version (re-downloadable, but gone from disk). The script already refuses to remove the active version.
brew/managed conflict — if status shows the on-PATH funpack is brew-managed and the user asked to update, do not silently install into the managed prefix and declare victory. Present the choice via AskUserQuestion: (1) brew upgrade the brew install (recommended if they want to keep brew as the source of truth), or (2) install into the managed prefix and link/PATH-order it ahead of brew. Pick option 1 first unless they want pinning/rollback, which brew can't give.

Standard procedures

Status check / "is my funpack current?" → run status. Read back the active version, the on-PATH version, the latest release, and the drift verdict (up to date / behind / ahead). The verdict compares latest against the active version, or the on-PATH version when nothing is managed — so a "behind" verdict on an unmanaged box is about the brew/dev binary, not a managed install. If behind, offer update.

First install on a fresh machine → scan to confirm none present → confirm → install (latest) → tell the user to add $FUNPACK_HOME/bin to PATH or run link, then doctor to confirm funpack version runs from PATH.

Update → status (capture from-version) → confirm from → to → update → status again. If on-PATH did not move (brew/order), apply the brew/managed conflict gate above.

Roll back a bad upgrade → list to show active + rollback target → confirm → rollback. Rollback toggles between the two most-recent active versions; running it again returns to where you were.

Pin to a specific version → if already installed (list), use <ver>; otherwise install <ver> (which downloads then activates it).

Diagnose "funpack not found / wrong version" → doctor → it checks the prefix, the active symlink, PATH resolution, that funpack version runs, platform asset availability, and gh presence. Then scan to see competing installs.

For the platform/asset matrix, the managed layout, and brew↔managed reconciliation details, see references/operations.md.

Plus depuis ce dépôt

même dépôt

hyperdescribe

mjmorales/funpack

Prune comments to near-zero and rewrite the code to be hyperdescriptive instead — names, types, and tests carry the intent so comments stop poisoning agents. Use to strip comments from a file or directory, drive a tree under the `eir comments` budget, run the comment-removal sweep, or make over-commented host/engine code self-documenting. Triggers on "prune comments", "strip comments", "remove the comments", "make this hyperdescriptive", "comment sweep", "near-zero comments", "decomment", "reduce comments", "sweep this dir for comments".

2026-06-270

funpack-game-model

mjmorales/funpack

The funpack runtime model — things, behaviors, signals, commands, and pipelines. Use when designing or reasoning about how a funpack game is structured and scheduled — what a behavior's parameters/return mean, how things communicate via signals, effect closure, the pipeline schedule and tick fold, the slot contracts (Update/Render/Ui/Audio/Startup), and why behaviors are unit-testable. Triggers on "behavior", "signal", "pipeline", "thing", "tick", "spawn/despawn", "effect closure", "render/audio/ui stage", "how does a funpack game work". Also matches gameplay goals phrased without funpack nouns — "how do I make the player move", "the enemy should chase the player", "make the score go up when the player scores", "how do my objects react to each other", "what runs each frame and in what order".

2026-06-260

funpack-project

mjmorales/funpack

How to lay out and configure a funpack game project — the enforced directory tree, the `.fcfg` config layer (project/entrypoints/builds/tags), directory-derived modules, the schema/seam/behavior module split, derived capabilities, and packages/dependencies. Use when scaffolding a new project, fixing a project-structure error, wiring an entrypoint, registering a @gtag, or adding a dependency. Triggers on "funpack project", "funpack_configs", ".fcfg", "entrypoints", "tags.fcfg", "builds.fcfg", "project layout/structure", "funpack module", "funpack package/dependency", "scaffold a funpack game". Also matches setup goals phrased without funpack terms — "how do I start a new game", "where does this file go", "how do I add a sprite or level or asset", "my game won't build because of its structure", "how do I add a dependency".

2026-06-250

funpack-determinism

mjmorales/funpack

The funpack determinism contract, fixed-point numerics, the compiler's structural quality gates, @stub/@todo typed holes, and which funpack-mcp tool drives each compile/test/index-query op. Use to understand why a build fails (a gate), how to stay deterministic, how Fixed-point math behaves, how to develop incrementally with typed holes, and which MCP tool to call to compile, test, or query the index. Triggers on "fixed-point", "Fixed/Q32.32", "determinism", "why won't it compile", "quality gate", "effect closure", "exhaustive match", "@stub", "@todo", "--release", "build the project", "run the tests", "compile to check", "query the index".

2026-06-240

funpack-engine-api

mjmorales/funpack

The funpack `engine.*` standard library — the API surface a game calls. Use when you need a function or type signature — vectors & fixed-point math, the world (View/Spawn/Ref), device-agnostic input, 2D/3D draw commands, audio, UI widgets, navigation, list/map/grid/string/rand, and the model/anim/render3 trio. Triggers on "engine.math", "engine.world", "engine.input", "engine.render", "what function does/returns", "how do I clamp/fold/draw/spawn", "Vec2", "View[T]", "Draw::", "Bindings", "Input.value/axis", "funpack stdlib/API". Also matches capability goals phrased without an API name — "how do I draw a sprite", "how do I read the keyboard or gamepad", "how do I play a sound", "distance between two points", "pick a random number", "clamp a value".

2026-06-240

funpack-language

mjmorales/funpack

Write and understand funpack `.fun` source — the language's syntax and semantics. Use when authoring, reading, editing, or explaining funpack code — declarations (thing/behavior/signal/pipeline/fn/enum/data/let/test), types, match, the `with` update, lambdas, string interpolation, the @doc/@gtag/@stub/@todo directives, and modules/imports. Triggers on ".fun", "funpack syntax", "write a funpack ...", "how do I declare", "funpack behavior/thing/signal/pipeline", "funpack match/enum/data". Also matches intent-phrased asks that name no funpack term — "how do I write this in funpack", "why won't this compile", "how do I loop over a list", "how do I update one field", "translate this code to funpack".

2026-06-240

name

ctl

description

funpack:ctl — funpack binary systems operations

Invoke the script with:

${CLAUDE_PLUGIN_ROOT}/skills/ctl/scripts/funpackctl <command> [args]

(In this repo's working tree that resolves to plugins/funpack/skills/ctl/scripts/funpackctl.) Always run scan or status first to learn the machine's current state before any mutating command.

The install model (read this before acting)

funpack ships as a single binary. Three channels can coexist on one machine, and scan reports all of them:

managed — this skill's prefix $FUNPACK_HOME (default ~/.funpack). Holds one dir per version under versions/<semver>/ and an active-version symlink at bin/funpack. Switching versions and rolling back are O(1) symlink swaps with no re-download. Only this channel supports rollback and instant version-pinning — it is the home for everything the user asks about updates/rollbacks/version-setting.
brew — brew install mjmorales/tap/funpack. Simple, but keeps no old versions, so it cannot roll back or pin.
dev-build — a binary compiled from a checkout. scan detects it at ./funpack.bin or ./cmd/funpack/funpack relative to the cwd (e.g. task binary output), never machine-wide.

Intent → command

User wants	Command
"what version / is it current?"	`status`
"show me every funpack on this box"	`scan`
"what releases exist?"	`releases [N]`
"install funpack" / "install v0.10.1"	`install [<ver>]`
"update / upgrade to latest"	`update`
"switch to / pin v0.9.0" (already installed)	`use <ver>`
"undo that upgrade"	`rollback`
"list what I have installed"	`list`
"remove the old v0.9.0"	`uninstall <ver>`
"put funpack on my PATH"	`link [<dir>]`
"why isn't funpack working?"	`doctor`

Confirmation gates

install / update / use / rollback — confirm once before running, stating the from → to versions. These are reversible (the prior version stays cached), so a single confirm is enough; do not re-gate each step of a multi-version sequence.
uninstall — confirm; it deletes a cached version (re-downloadable, but gone from disk). The script already refuses to remove the active version.
brew/managed conflict — if status shows the on-PATH funpack is brew-managed and the user asked to update, do not silently install into the managed prefix and declare victory. Present the choice via AskUserQuestion: (1) brew upgrade the brew install (recommended if they want to keep brew as the source of truth), or (2) install into the managed prefix and link/PATH-order it ahead of brew. Pick option 1 first unless they want pinning/rollback, which brew can't give.

Standard procedures

Update → status (capture from-version) → confirm from → to → update → status again. If on-PATH did not move (brew/order), apply the brew/managed conflict gate above.

Pin to a specific version → if already installed (list), use <ver>; otherwise install <ver> (which downloads then activates it).

For the platform/asset matrix, the managed layout, and brew↔managed reconciliation details, see references/operations.md.