メニュー
Hot-reload workflow for c11 development: initial setup, tagged Debug builds via reload.sh, Release variants, the debug event log, and the tagged-build reporting format. Use when building, rebuilding, or launching c11 during development.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
c11 is a native macOS terminal multiplexer. Load this skill anytime any of the following attributes are hit: (1) session is inside c11 (`C11_SHELL_INTEGRATION=1`), (2) working with panes, surfaces, workspaces, splits, or tabs, (3) sending text or commands to another surface, (4) launching or orchestrating sub-agents, (5) declaring agent identity, setting title/description, or reporting sidebar status, (6) using the embedded browser or markdown surfaces, (7) any c11-specific command or troubleshooting question. When in doubt, load it.
Stage 4 of the Tone workflow and Stage 11's build engine — takes a complete build contract (SPEC.md, EVALUATION.md, BUILDPLAN.md, and where one exists a binding prototype + DESIGN.md), turns it into Lattice tickets, dispatches a delegator fleet that produces open PRs, and terminally audits the result against a spec its builders did not write. No planning interview — if contract artifacts are missing, run the Tone stage that produces them (tone-architect for spec/plan, tone-initiation for a raw idea). Invoke when the operator says "orchestrate this," "kick off the orchestration," "run the orchestrator," "set up an overnight run," or hands over a finished build contract.
The idea-generation sequence upstream of the Tone/Chord workflows — the operator brings a direction (a market, a hunch, a theme); Sounding arms it with evidence and explores it in dialogue, producing reads — concrete, carded takes on the direction — each ending in a try/not-try call. Where Tone begins with "a raw idea and a client," Sounding is where raw ideas come from. Invoke on "sounding," "take soundings," "sound this," "let's explore ideas," "what should we build next," or whenever the operator brings a direction that isn't yet an idea. Standalone; "try" reads feed venture-partner and the Tone/Chord commissions; composes with Scanner (/scan) for app-level evidence.
Stage 11's marketing-capability program — a working session that turns marketing intent into budgeted, pre-registered experiments and accumulates the verdicts into a playbook of plays with real numbers. Demand generation is the unsolved half of the autonomous-business loop; Resonance reps it daily the way agentic coding was repped in 2023–24. Invoke on "resonance," "make this resonate," "marketing," "get users for this," "demand probe," "test demand," or whenever marketing needs to produce a verdict, not a vibe. Standalone; its probe instruments serve Sounding "try" reads; its playbook feeds the distribution skill (per-project channel planning), which feeds every channel result back.
Stage 3 of the Chord workflow (chord-initiation → chord-prototype → chord-architect → lattice-orchestrator ×K) — codifies K loved designs into K build contracts under one shared rulebook, authors the pre-registered resolution book, then conducts the ×K build (fresh lattice-orchestrator run per candidate) through to the handoff of K live, instrumented probes. Inherits tone-architect by reference. Invoke when the operator says "chord architect," "codify the portfolio," "spec the candidates," or when a portfolio of loved prototypes needs its build contracts — and stay seated: this skill also owns the conductor's build-and-handoff playbook.
Stage 1 of the Chord workflow (chord-initiation → chord-prototype → chord-architect → lattice-orchestrator ×K) — Tone in plural: the portfolio initiation of one problem with several complete answers. Commission a portfolio, research to enumerate, generate ~N candidate bets, voice K uncorrelated ones with a champion each, and write the two-tier philosophy & stories. Inherits tone-initiation by reference. Invoke when the operator says "chord," "chord this," "portfolio this," "build several answers," or when a keystone fork resists resolution by research and dialogue.
| name | c11-hotload |
| description | Hot-reload workflow for c11 development: initial setup, tagged Debug builds via reload.sh, Release variants, the debug event log, and the tagged-build reporting format. Use when building, rebuilding, or launching c11 during development. |
How to build, reload, and tail a c11 dev instance.
./scripts/setup.sh
Initializes submodules and builds GhosttyKit.
Never run bare xcodebuild or open an untagged c11 DEV.app. Untagged builds share the default debug socket and bundle ID with any other agent's running instance, causing conflicts and stealing focus. Always reload with a tag:
./scripts/reload.sh --tag <your-branch-slug>
A tagged build gets its own name, bundle ID, socket, and derived data path so it runs isolated alongside anything else.
| Command | What it does |
|---|---|
./scripts/reload.sh --tag <tag> | Build and launch Debug, tagged (required tag) |
./scripts/reloadp.sh | Build and launch Release (tears down running c11 via pkill -x c11) |
./scripts/reloads.sh | Build and launch Release as "c11 STAGING" (isolated from production c11) |
./scripts/reload2.sh --tag <tag> | Reload both Debug and Release (tag required for Debug) |
Apply Release changes without killing the running app. reloadp.sh starts with pkill -x c11, which tears down every c11 pane — fatal if another agent is mid-task in a sibling pane, or if the current agent session is itself hosted inside c11. To update the .app on disk without disturbing any running process, build only:
xcodebuild -project GhosttyTabs.xcodeproj -scheme c11 -configuration Release -destination 'platform=macOS' build
macOS lets you overwrite a running app's bundle — the already-loaded binary stays in memory, and the rebuilt .app is picked up on the next manual launch (⌘Q then relaunch). Use this when collaborating with other agents or when the user explicitly asks to avoid session churn.
A rebuild-and-relaunch keeps agent resume only on a clean quit. When a reload does restart the app over a running instance, let the script's clean quit drive the teardown — do not pkill -9 / pre-kill it first. Browser and markdown surfaces restore either way, but agent terminals only resume their conversation when the prior process shut down cleanly; SIGKILL'd, they come back as bare shells.
If you only need to verify the build compiles, use a tagged derivedDataPath:
xcodebuild -project GhosttyTabs.xcodeproj -scheme c11 -configuration Debug -destination 'platform=macOS' -derivedDataPath /tmp/c11-<your-tag> build
A Release/staging build (reloads.sh, or a published c11 STAGING …) binds its own socket (e.g. /tmp/c11-rel-<ver>.sock) that a CLI running in a production-c11 shell cannot write to — the writes fail even with the path pointed at it. To run c11 CLI or socket checks against such a build, run them from a terminal inside that build. For socket-level validation during development, prefer a tagged Debug build, whose socket is reachable from any shell via C11_SOCKET=/tmp/c11-debug-<tag>.sock.
A normal launch can present two blocking dialogs before the GUI is usable: the Agent Skills install/update sheet and the "Resume previous session?" picker. For automated QA they're just modals in the way. The C11_QA_LAUNCH env var suppresses both and makes the resume decision deterministic:
C11_QA_LAUNCH | Skill sheet | Resume picker | Session |
|---|---|---|---|
fresh (or any non-resume value) | suppressed | suppressed | clean slate, no restore |
resume | suppressed | suppressed | silently restores the prior session |
| unset / empty | may show | may show | normal interactive launch |
It's read fresh each launch and never persisted, so it can't leak into a later non-QA run. Default is fresh — automation usually wants a known-empty start; resume is the deliberate opt-in.
# Tagged automation launcher — dedicated flag:
./scripts/launch-tagged-automation.sh <tag> --qa # fresh (clean slate)
./scripts/launch-tagged-automation.sh <tag> --qa resume # restore prior session
# Any other launch path — set the env var directly:
C11_QA_LAUNCH=fresh open "/path/to/c11 DEV <tag>.app"
The launcher unsets any inherited C11_QA_LAUNCH/CMUX_QA_LAUNCH and only sets it when --qa is passed, so a stray value in your shell can't silently flip a normal run into QA mode.
When rebuilding GhosttyKit.xcframework, always use Release optimizations:
cd ghostty && zig build -Demit-xcframework=true -Dxcframework-target=universal -Doptimize=ReleaseFast
When reporting a tagged reload result to the user, use the format for your agent type.
Claude Code (markdown link, cmd+clickable):
=======================================================
[c11 DEV <tag-name>.app](file:///Users/<user>/Library/Developer/Xcode/DerivedData/c11-<tag-name>/Build/Products/Debug/c11%20DEV%20<tag-name>.app)
=======================================================
Codex (plain text):
=======================================================
[<tag-name>: file:///Users/<user>/Library/Developer/Xcode/DerivedData/c11-<tag-name>/Build/Products/Debug/c11%20DEV%20<tag-name>.app](file:///Users/<user>/Library/Developer/Xcode/DerivedData/c11-<tag-name>/Build/Products/Debug/c11%20DEV%20<tag-name>.app)
=======================================================
Never use /tmp/c11-<tag>/... app links in chat output. If the expected DerivedData path is missing, resolve the real .app path and report that file:// URL.
Before launching a new tagged run, clean up any older tags you started in this session (quit the old tagged app, remove its /tmp socket / derived data).
Prune stale tags periodically. Each reload.sh --tag leaves ~3.5G behind in DerivedData and /tmp that nothing auto-cleans — across many iterations this consumes hundreds of GB:
./scripts/prune-tags.sh # dry run
./scripts/prune-tags.sh --yes # actually delete
./scripts/prune-tags.sh --keep <tag> # protect an additional tag
Running tags are auto-protected. A weekly launchd job (scripts/launchd/com.stage11.c11-prune-tags.plist) runs --yes automatically; reach for manual prune when you want space back sooner.
All debug events (keys, mouse, focus, splits, tabs) go to a unified log in DEBUG builds:
tail -f "$(cat /tmp/c11-last-debug-log-path 2>/dev/null || echo /tmp/c11-debug.log)"
/tmp/c11-debug.logreload.sh --tag <tag>): /tmp/c11-debug-<tag>.logreload.sh writes the current path to /tmp/c11-last-debug-log-pathreload.sh writes the selected dev CLI path to /tmp/c11-last-cli-pathreload.sh updates /tmp/c11-cli, $HOME/.local/bin/c11-dev, and $HOME/.local/bin/cmux-dev (compat alias) to that CLIThe dlog("message") free function lives in vendor/bonsplit/Sources/Bonsplit/Public/DebugEventLog.swift. The whole file is #if DEBUG, so every call site must also be wrapped in #if DEBUG / #endif. Existing event names include focus.*, tab.*, pane.*, and divider.*; grep for a nearby category before inventing a new one.