القائمة
Build and package Nintendo 64 homebrew ROM artifacts for the pi-n64 preview.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | mapache-n64-build |
| description | Build and package Nintendo 64 homebrew ROM artifacts for the pi-n64 preview. |
Use this skill when creating or updating Nintendo 64 homebrew in a Mapache pi-n64 session.
For a new libdragon project, prefer a small Makefile that includes the installed libdragon n64.mk file and produces a root .z64 ROM, then copy that ROM to /workspace/build/game.z64. Keep source files outside /workspace/build and treat build as generated output. Do not make the primary libdragon ROM target itself live under build/, because libdragon's n64.mk uses BUILD_DIR internally and that can produce paths like build/build/game.elf.
Minimal Makefile shape:
all: game.z64
.PHONY: all
BUILD_DIR = build
include $(N64_INST)/include/n64.mk
OBJS = $(BUILD_DIR)/main.o
game.z64: N64_ROM_TITLE = "Mapache N64"
$(BUILD_DIR)/game.elf: $(OBJS)
preview: game.z64
mkdir -p /workspace/build
cp game.z64 /workspace/build/game.z64
.PHONY: preview
clean:
rm -rf $(BUILD_DIR) *.z64
.PHONY: clean
-include $(wildcard $(BUILD_DIR)/*.d)
QA a Mapache preview with the runner-owned browser QA command, status checks, console logs, screenshots, and structured reports.
Host an app or API behind the Mapache preview gateway.
Work from or create GitHub issues with repository context, labels, clarification, and implementation flow.
Build static web output where the Mapache preview canvas can serve it.
Run or compose Mapache browser QA tests from checked-in e2e/qa case manifests using Chrome DevTools. Use when the user explicitly asks for QA testing, smoke testing, browser testing, end-to-end testing, or a named QA case, and when issue-workflow changes frontend behavior and requires QA before PR completion.
Use when the user provides a GitHub issue number and wants Codex to complete the whole implementation workflow: update local main from remote, read the issue and comments, create an issue-named branch, implement and test the change, compose and run QA for frontend changes, commit, push, open a pull request, return to main, and comment or label the issue when blocked or waiting on user action.