SkillFab

A skill that teaches how to manage a Docker-based development environment well. Core model: development environment = image (static) x container (runtime) x mount (code) x cache (dependencies), four independent lifecycles. Must teach: 1. Inventory-first discipline: docker ps -a + docker images + git worktree list before any container operation 2. Image strategy: docker commit slow dependency installs immediately; commit-vs-rebuild decision table; naming project-env:purpose-date 3. Container strategy: docker run -d one-shot jobs; sleep infinity + docker exec persistent containers; warn against docker exec -d without main process 4. Mount strategy: readlink -f physical paths (symlinks); git worktree checkouts are independent directories; separate code/data/cache mounts 5. Symptom-to-root-cause diagnostic table 6. Cleanup policy: containers are build-time cache pools Based on real kernel-build workflow (Asterinas RISC-V): every fresh docker run re-downloaded the full toolchain (15-20 min wasted), docker exec -d lost jobs, wrong worktree mount compiled wrong code. Encode as decision tables + checklists.

Create a broader successor skill to qemu-debug-basics (skill #26, issue #38, completed): QEMU is not only a debugger — it is the first site for OS/kernel research. This skill documents both the research roles and the debugging craft, with the debugging content fully retained from the predecessor. **Research roles covered (each with field evidence from real work):** - Architecture bring-up experiments (RISC-V port: page tables, memory model, boot chain — 12 kernel fixes validated in QEMU before hardware) - MMU/memory-model behavior research: Svade/Svadu A/D-bit tests, svpbmt/PBMT, forced-Svade boot paths ("Test RISC-V Svade in CI") - Memory-subsystem analysis: meta::init complexity modeling, separating inherent cost from bug cost (1/64 zeroing bug reproduced and quantified in QEMU) - SMP/multi-core studies: 4-HART boot, spin/IPI behavior - Hardware design comparison: dumpdtb authoritative layout vs physical board DTB (UART/PLIC/CLINT/timebase), deciding which real-board issues reproduce in the emulator - Boot protocol research: booti/multiboot2/U-Boot chains, image format validation - Emulator-based CI/regression: 246 ostd unit tests inside QEMU, feature-forced paths - Reproducible experiments: static-init recipes for PR/community reproduction - QEMU version behavior studies (9.2.4 → 10.0.2 upgrade observations) - General capabilities: user-mode emulation, deterministic execution (-snapshot/-icount), parallel experiment instances, isolated environments **Debugging (unchanged from predecessor):** -d int MVP, monitor info registers/xp, kernel cmdline logging, -no-reboot panic-loop detection, -smp 1 isolation, gdb -s -S, boot marker bisection, llvm-nm symbol resolution, slow-vs-hung discrimination via memory-size comparison, Docker canonical-mount discipline, common-mistakes table. **Deliberately out of scope:** gate/verification engineering processes; physical-board boot safety (safe-physical-os-boot). Relationship: qemu-os-lab is the broader successor of qemu-debug-basics (skill #26, v1.0.0, published 2026-08-07). The predecessor stays published; this issue intentionally creates a wider-named skill rather than a version update, per requester decision.

Create a skill capturing practical QEMU usage for OS/kernel bring-up and debugging, distilled from real RISC-V porting experience (Asterinas on QEMU virt): **What the skill covers:** - What QEMU can do for kernel development: fast iteration loop (edit → ~5s incremental build → boot), reproducible failure localization, hardware-layout comparison via dumpdtb (board quirk vs real bug), debugging backends (-d logs, monitor, gdb stub), artifact generation (booti validation, DTB capture), regression environment - Basic usage: qemu-system vs qemu-user modes, common launch flags (-machine, -cpu with feature extensions like svpbmt, -m, -smp, -kernel, -append, -nographic, -serial, -monitor, -s -S, -d int -D, -no-reboot, -snapshot), and running QEMU from a Docker image when the host has no QEMU binaries — including the canonical mount discipline that avoids the classic "ELF not found in container" failure - Debugging methods ranked by field-proven value (from a real RISC-V kernel port that went from silent hang to userspace hello): -d int exception logging (MVP — do this before adding prints), monitor info registers/xp, kernel cmdline logging via -append log_level, -no-reboot to expose panic loops, -smp 1 multi-core isolation, gdb -s -S, boot progress marker bisection (sbi_putchar 'A'…'L'), llvm-nm symbol resolution of epc/ra, script-verified bit arithmetic - Distinguishing "slow" vs "hung": same stall point regardless of memory size (-m 2G vs 8G) means hung, not slow — with the reasoning why - Common mistakes table: non-canonical Docker mounts, feeding physical-board DTB/PMA config to QEMU (board quirk, not kernel bug), introducing new variables while reducing others, multiple independent bugs stacking behind one symptom, pure-emulation CPU contention (~130%+ for riscv64), debugging order (exception log before prints) **Deliberately out of scope:** gate/verification engineering processes (how much validation is enough is the user's call), and physical-board boot safety (covered by the complementary published skill safe-physical-os-boot). **Background:** distilled from July 2026 sessions debugging an Asterinas RISC-V port on QEMU virt — 12+ kernel fixes (write_bytes unit error, PTE U-bit, SBI SRST registers, svpbmt CPU flag, VDSO path, FpuState stub...), Docker-based QEMU wrapper scripts, and retrospective analyses ranking the debugging methods by actual value.

A skill for designing, validating, and analyzing survey instruments in social science research. Features: generate Likert items from construct definitions, expert content validity checklist, pilot study item analysis (discrimination, item-total correlation, floor/ceiling effects), EFA/CFA with fit indices, reliability analysis (alpha, omega, test-retest ICC), measurement invariance testing, common method bias diagnostics. Outputs validated scale table, factor loading diagram, reliability report, final questionnaire .docx. For psychology, sociology, education, and management researchers.

A skill for conducting reflexive thematic analysis of qualitative data (interview transcripts, field notes, open-ended survey responses). Features: ingest .txt/.docx/.csv files, auto-generate initial open codes using semantic similarity, cluster codes into candidate themes via hierarchical clustering, interactive theme refinement, structured codebook generation with theme definitions and example quotes, thematic map visualization. Follows Braun & Clarke reflexive TA framework. Outputs: codebook .csv, coded excerpts .xlsx, thematic network .png, methods-section draft .md.

A skill that analyzes public discourse frames on social media (Weibo, Twitter/X, Reddit) using framing theory from political communication and sociology. Features: scrape posts by keyword/hashtag/time range, detect dominant frames using Entman 1993 four-function model (problem definition, causal attribution, moral evaluation, treatment recommendation), classify into episodic vs thematic / gain vs loss / human interest vs conflict frames, stance and sentiment analysis per frame, temporal frame evolution tracking, frame co-occurrence network visualization. For social movement research, political communication, public opinion analysis, and media studies.

docker-env-management

How to manage a Docker-based development environment well: reuse cached images instead of re-downloading toolchains, keep build containers alive, mount the right directory, and know when to commit vs rebuild. Use when starting any containerized build/test, debugging "container compiled the wrong code", "ELF/file not found in container", "stale build artifacts", "downloads toolchain every time", or when a repo has multiple worktrees and you must mount the correct checkout. Triggers: - Starting a containerized build or test (long-running or not) - Container can't see files that exist on the host - Build outputs look stale or come from the wrong branch - Every build re-downloads toolchains/dependencies - `docker commit` decision: save a configured environment or rebuild - Multiple checkouts (git worktrees) and choosing what to mount - Container exited and the background job vanished

qemu-os-lab

Use when using QEMU for OS/kernel research or debugging — architecture bring-up experiments (e.g. RISC-V), MMU/memory-model behavior tests (Svade/Svadu, svpbmt, SMP), hardware-vs-emulator comparison (DTB, board quirks), reproducible experiments, emulator-based CI/regression, or debugging silent hangs, panic loops, and hosts without QEMU binaries (Docker fallback).

qemu-debug-basics

Use when booting or debugging an OS/kernel under QEMU — silent hangs with no console output, panic loops that look like silence, distinguishing "slow" from "hung", hosts without QEMU binaries installed, or when choosing launch flags, serial/monitor setup, and kernel cmdline logging for a QEMU guest.

safe-physical-os-boot

Use when preparing, executing, observing, or diagnosing an OS/kernel boot on physical development hardware through firmware, a bootloader, or serial transport, especially when emulator evidence, artifact identity, recovery availability, one-shot boot commands, or early-boot silence must be handled safely.

build-interactive-paper-maps

Design, implement, and debug publication-ready interactive research architecture maps for technical blogs and research notes. Use when Codex needs to organize related papers by mathematical role, turn a static architecture diagram into clickable HTML/SVG, map citations onto a non-serial topology, distinguish pipeline factorization from CNN/Transformer backbones and diffusion/flow inference semantics, or integrate and validate such a figure in Markdown, Jekyll, or GitHub Pages.