Federate hyperloom-workload-optimizer from AMD-AGI/Hyperloom - #213
Open
lishuoshuo-amd wants to merge 6 commits into
Open
lishuoshuo-amd wants to merge 6 commits into
lishuoshuo-amd wants to merge 6 commits into
Conversation
Registers Hyperloom as a federation source, so the catalog imports the skill from the product repo that owns it instead of carrying an in-repo copy. The upstream skill is the bootstrap only: install the wheel, run /hyperloom-setup, hand off to the demo skills the wheel installs. The copy in this repo predates federation and carries its own launch.sh, resume.sh and preflight.py, because it was written for a workspace with no Hyperloom in it. Those do not come across -- a second launch path in the product repo would drift from the CLI it wraps -- so the import removes them here, and two behavioral cases that graded them have to go with them. hyperloom-launcher-gates is deleted. It pinned install.sh and kernel-agent.env.sh by name and asked for IR-1/IR-2 by content: the gates belong to the optimizer skill inside the wheel, which a headless run with no wheel installed cannot reach. hyperloom-workload-intake keeps the part that is still true of the design -- a launch plan is presented and confirmed before the optimizer starts -- and drops the workload.env mechanics, which were the catalog launcher's, along with the clause in the prompt that asked about them. The walkthrough loses its pointer to reference.md, which the import also removes, and no longer calls the installed release pinned.
Brings this copy in step with what federation will import, so the diff that ships is reviewable here rather than only in the source repo. The launcher the old copy carried -- launch.sh, resume.sh, launch_health.sh, preflight.py, _env.sh and their tests -- is gone, along with setup.md and reference.md. It existed because a catalog user starts in a workspace with no Hyperloom in it, but everything after the install now comes from the wheel: hyperloom-setup owns credentials and run mode, the demo skills own the workload preset and the container, and inference_optimizer owns the gates, resume and monitoring. A second launch path here could only drift from the CLI it wrapped. evals/ stays: federation does not carry it in either direction. skill-card.md stays as written; the importer regenerates it. No .federated.json, so the first nightly run reads this copy as out of date and re-vendors it, which is what writes the marker with a real commit. That run also re-pins the examples/README.md link, absolute to `main` here, onto the commit it imported.
lishuoshuo-amd
marked this pull request as ready for review
September 16, 2026 06:52
lishuoshuo-amd
deployed
to
behavioral-instinct
September 16, 2026 06:54 — with 
GitHub Actions
Active
GitHub Actions
Active
The demo prompts carried the full flag set, so a CLI change meant a PR here even once the skill itself is federated -- which is what #207 was. The flags live in the demo skills the wheel installs, so the prompts now name the demo and let those skills answer for the values. Same reason drops the module path and install.sh from the launch description and the Step 2 check: they are the wheel's to move. A model path is worth spelling out, though, since it is the one value a user brings, so it joins <framework> and <gpu_type> as a placeholder. What stays is the artifact paths under USER_DATA_PATH. Those are what the run hands back to the user, not internals.
lishuoshuo-amd
had a problem deploying
to
behavioral-instinct
September 16, 2026 08:25 — with
GitHub Actions
Error
GitHub Actions
Error
The prompt said "the 3-hour demo" while the skill behind it is hyperloom-qwen3-8b-3h, so the model was the one thing a reader could not see. Naming it also makes the override unambiguous: the model-path sentence now reads as replacing a named default, and dropping it takes that default.
lishuoshuo-amd
deployed
to
behavioral-instinct
September 16, 2026 08:27 — with
GitHub Actions
Active
GitHub Actions
Active
The Phase 0 / Phase 1 labels were the old in-repo skill's; the upstream one has no such phases, so a reader would never hear the agent use them. Step 2 is now named for what it does: install, then setup. It also claimed Step 2 starts the container. hyperloom-setup says outright that it does not, and each demo skill says it owns the Docker setup, so in Docker mode the container belongs to Step 3 and Step 3 now says so. Step 2's prompt and Step 3's precondition drop the execution-environment wording for the same reason: on bare metal setup does prepare the host, in Docker it writes .env and stops. Setup ends by offering a run, which the walkthrough wants deferred to Step 3, so it says to decline that offer rather than leaving the reader to guess.
lishuoshuo-amd
had a problem deploying
to
behavioral-instinct
September 16, 2026 09:47 — with
GitHub Actions
Failure
GitHub Actions
Failure
The expectation failed and passed on byte-identical inputs: the case passed at 06:54, then failed at 09:47 with only walkthrough commits in between, which a behavioral run never reads. #207 recorded the same flap on this case for a different wording, so this is the case rather than the wording -- its prompt forbids running anything, and the judge then reads a described launch plan as a plan that was never presented. Confirming the plan before a launch is still graded, by the two cases a run actually reaches: hyperloom-optimize-vllm-first-steps and hyperloom-bootstrap-phase-discipline both assert the optimizer does not start before it, and both pass.
lishuoshuo-amd
force-pushed
the
feat/federate-hyperloom-skill
branch
from
September 16, 2026 11:52
fb990f5 to
9c6884c
Compare
lishuoshuo-amd
deployed
to
behavioral-instinct
September 16, 2026 11:53 — with
GitHub Actions
Active
GitHub Actions
Active
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Federates
hyperloom-workload-optimizerfrom the product repo that owns it, and brings this copy in step with what the importer will fetch.{ "repo": "AMD-AGI/Hyperloom", "license": "MIT", "skills": [ { "path": "examples/skills/hyperloom-workload-optimizer", "as": "hyperloom-workload-optimizer" } ] }What the skill is now
The bootstrap only: confirm the workspace,
pip install --target ., run/hyperloom-setup, then hand off to the skills the wheel installs —hyperloom-setupfor credentials and run mode, the demo skills for a workload preset,inference_optimizerfor the launcher gates, resume and monitoring. Those ship with the runtime, so they match the installed version by construction.It is the agent-facing form of Hyperloom's
examples/README.md, which stays the human quickstart.What the old copy carried, and why it goes
launch.sh,resume.sh,launch_health.sh,preflight.py,_env.shand their tests, plussetup.mdandreference.md. That launcher existed for a real reason — a catalog user starts in a workspace with no Hyperloom in it — but everything after the install now comes from the wheel, so a second launch path here could only drift from the CLI it wrapped.evals/stays, since federation does not carry it in either direction.skill-card.mdstays as written; the importer regenerates it on import.Two behavioral cases go with it
hyperloom-launcher-gates— deleted. It pinnedinstall.shandkernel-agent.env.shby name and asked for IR-1/IR-2 by content. Those gates belong to the optimizer skill inside the wheel, which a headless run with no wheel installed cannot reach; grading them at the entry point would only measure whether the entry point reimplemented them.hyperloom-workload-intake— narrowed. It keeps what is still true of the design, that a launch plan is presented and confirmed before the optimizer starts, and drops theworkload.envpersistence mechanics, which were the launcher's. The clause in the prompt that asked about them goes too, since nothing answers it any more.The walkthrough loses its pointer to
reference.mdand no longer describes the installed release as pinned.What the first nightly run will still change
This copy is written by hand, not by the importer, so two things are left for it:
.federated.json. The marker has to carry a real commit, andis_up_to_datecompares the content hash but not the commit — a hand-written one would freeze a placeholder in place for good. Without a marker the copy reads as out of date, so the first run re-vendors it and writes the marker properly.examples/README.mdlink is absolute tomain. The importer re-points outward links at the commit it imported.So expect one small
Bump hyperloom-workload-optimizer to <commit>PR after this merges, adding the marker, re-pinning that link, and regenerating the card.