
Bambu Labs
Dry-run and safely start validated plain G-code jobs on a Bambu Lab printer over the local LAN before committing filament and machine time.
Overview
Bambu Labs is an agent skill for the Operate phase that dry-runs and starts validated plain G-code handoffs to a local Bambu Lab printer over LAN.
Install
npx skills add https://github.com/earthtojake/text-to-cad --skill bambu-labsWhat is this skill?
- Default workflow: dry-run a validated plain G-code handoff, then start only when checks pass
- Interface copy targets `$bambu-labs` for agent-driven local Bambu handoffs
- Reference notes flag that Bambu has no stable public local-print API contract—treat LAN behavior as debug-first
- Explicit split between planning or debugging against a real printer vs assuming cloud-only slicer flows
- MIT-licensed skill package from the earthtojake text-to-cad catalog
Adoption & trust: 436 installs on skills.sh; 5.8k GitHub stars.
What problem does it solve?
You have validated G-code and a Bambu on your network, but starting a print blindly risks wasted filament, failed jobs, or confusing LAN behavior without a dry-run gate.
Who is it for?
Solo builders running Bambu Lab printers locally who generate or receive plain G-code from CAD or agent pipelines and want a dry-run before start.
Skip if: Teams without a Bambu printer, cloud-only slicer workflows with no LAN control, or anyone expecting a guaranteed stable vendor local-print API without hands-on debugging.
When should I use this skill?
Use when you have validated plain G-code for a Bambu on your LAN and want to dry-run the handoff before starting the print, or when debugging local protocol behavior against a real machine.
What do I get? / Deliverables
Your agent walks through a dry-run of the local handoff, then starts the job only when the validated plain G-code path looks safe on your printer.
- Dry-run result for the local G-code handoff
- Started print job when dry-run checks pass
- Debug notes aligned with local Bambu LAN protocol behavior
Recommended Skills
Journey fit
Local print handoffs are a running-production concern once G-code exists and you are operating hardware on your network, not an early ideation task. Infra covers local device orchestration, LAN protocols, and dry-run gates before a real print start.
How it compares
Agent handoff and dry-run discipline for local Bambu jobs—not a replacement for Bambu Studio slicing or cloud print queues.
Common Questions / FAQ
Who is bambu-labs for?
Indie makers and agent-assisted builders who operate a Bambu Lab printer on the local network and need help dry-running G-code handoffs before a real start.
When should I use bambu-labs?
Use it in Operate when plain G-code is ready and you want `$bambu-labs` to dry-run the local handoff, debug LAN behavior, or start the job after validation—not during early CAD ideation alone.
Is bambu-labs safe to install?
It targets real hardware on your LAN; review the Security Audits panel on this Prism page and treat network and filesystem access as sensitive before enabling autonomous runs.
SKILL.md
READMESKILL.md - Bambu Labs
interface: display_name: "Bambu Labs" short_description: "Dry-run and start local Bambu G-code handoffs" default_prompt: "Use $bambu-labs to dry-run a validated plain G-code handoff before starting it." MIT License Copyright (c) 2026 earthtojake Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. # Bambu Lab Local LAN Protocol Notes Use this reference only when planning or debugging against a real local printer. Bambu does not provide this skill with a stable public local-print API contract, so treat these as observed FTPS/MQTT behaviors. ## Required Inputs - Validated plain `.gcode`. - Printer LAN IP/hostname. - Printer access code. - Printer serial for MQTT topic `device/{serial}/request`; fetch it from the printer TLS certificate with `serial` or let `send` fetch/cache it. - Handoff mode: `template-project`, `plain`, or `bambox-project`. Workspace-root `bambu-printers.json` stores printer IDs, hostnames, access codes, models, and cached serials. It is local config and should be ignored by Git. ## Transport - FTPS upload: implicit TLS on port `990`. - MQTT control/status: TLS on port `8883`. - Username: `bblp`. - Password: printer access code. - TLS verification is off by default because local printers commonly use device/self-signed certificates. - The helper rejects public IPs/hostnames unless `--allow-nonprivate-host` is set. - FTPS data connections may require TLS session reuse. The helper reuses the control TLS session for uploads and listings. ## MQTT Topics - Request topic: `device/{serial}/request`. - Report topic: `device/{serial}/report`. - `status --push-all` subscribes to reports, then publishes `pushing.pushall` to request a full state report. - Publishing a start payload is a request, not proof of accepted motion. ## Handoff Payloads ### Template Project Validated on an A1 Mini during local LAN debugging: 1. Start from a validated plain `.gcode`. 2. Copy a known-good same-printer `.gcode.3mf` template. 3. Replace `Metadata/plate_N.gcode` and update `Metadata/plate_N.gcode.md5`. 4. Upload the resulting `.gcode.3mf` to FTPS root, not `cache/`. 5. Publish `print.project_file` with root FTP URL. Representative payload: ```json { "print": { "command": "project_file", "param": "Metadata/plate_1.gcode", "project_id": "0", "profile_id": "0", "task_id": "0", "subtask_id": "0", "subtask_name": "job", "url": "ftp:///job.gcode.3mf", "md5": "PROJECT_MD5_UPPERCASE", "timelapse": false, "bed_type": "auto", "bed_levelling": true, "flow_cali": true, "vibration_cali": false, "layer_inspect": true, "use_ams": false, "ams_mapping": "" } } ``` ### Plain G-code The plain path uploads `cache/<job>.gcode` and publishes: ```json { "print": { "command": "gcode_file", "param": "cache/job.gcode" } } ``` On the tested A1 Mini, byte-for-byte verified uploads still produced `gcode_file` failure/idle behavior. Use this path only for diagnostics or printer firmware wher