메뉴
Build zynk and run a fast end-to-end sanity check of the release binary against an isolated dev runtime (server starts, panes/agents spawn, conversation rows record) before claiming a build works or passing a release gate. Use after a build or before a release.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | smoke-test |
| description | Build zynk and run a fast end-to-end sanity check of the release binary against an isolated dev runtime (server starts, panes/agents spawn, conversation rows record) before claiming a build works or passing a release gate. Use after a build or before a release. |
A fast end-to-end sanity check that the freshly built zynk binary starts, serves its socket API, runs
panes/agents, and records conversation rows. This is NOT just check (unit/integration tests) — it exercises
the REAL binary against an isolated runtime, the gap tests can't cover.
just build / cargo build --release, before claiming the binary works.zynk-pre-release-audit).~/.config/zynk/), the live DB (~/.zynk/zynk.db),
or the default CARGO_TARGET_DIR (the machine runs cargo-watch on it). Use an isolated CARGO_TARGET_DIR
plus isolated XDG_CONFIG_HOME / XDG_RUNTIME_DIR / ZYNK_SOCKET_PATH / ZYNK_SQLITE_HOME under /tmp.CARGO_TARGET_DIR,
ZYNK_SOCKET_PATH, ZYNK_SQLITE_HOME, XDG_*) resolves under /tmp, NOT a live default (echo them).
zynk status reports the active client/server — use it to confirm the server is bound to the isolated
ZYNK_SOCKET_PATH, not the live socket (it does not print config/DB/target paths). If anything resolves live, STOP.zynk --help rather than assuming them.CARGO_TARGET_DIR=/tmp/zynk-smoke-target cargo build --release --locked
→ BIN=/tmp/zynk-smoke-target/release/zynk.XDG_CONFIG_HOME, XDG_RUNTIME_DIR, ZYNK_SOCKET_PATH, ZYNK_SQLITE_HOME
all under /tmp/zynk-smoke/…; mkdir -p them. Confirm each exported var is a /tmp path; "$BIN" status should report the active socket/server as the isolated one (it follows the env vars — it does not print config/DB/target paths).$ZYNK_SOCKET_PATH to exist (poll the condition, never a fixed sleep).zynk pane list shows it.agent send / pane run (native dispatch) → submitted; pane send-text (persist only) → drafted.who --json, thread, inbox, query "<term>" return rows and write NO delivery events.$ZYNK_SQLITE_HOME/zynk.db): the message rows exist and body_hash == sha256(body)./tmp/zynk-smoke*, and confirm the live runtime/DB were never touched.exported env vars all resolve under /tmp · zynk status reports the isolated socket/server · pane/agent spawn · send returns the correct
submitted/drafted status · read paths return data · DB rows exist with a valid body_hash. Any panic, a
bare error without an F4 envelope, a received status (nothing should reach it yet — ADR 0002/0009), or any
touched live path = FAIL.
Control zynk from inside it. Manage workspaces, tabs, and panes, spawn and coordinate agents, read pane output, wait for state changes, and exchange native messages — all via CLI commands that talk to the running zynk instance over a local unix socket. Use when running inside zynk (ZYNK_ENV=1).
Prepares production launches. Use when preparing to cut a release. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.
Optimizes runtime performance. Use when performance requirements exist, when you suspect performance regressions, or when render latency, IPC/PTY throughput, allocation, or async overhead needs improvement. Use when profiling reveals bottlenecks that need fixing.
Manages deprecation and migration. Use when removing old systems, APIs, IPC methods, or features. Use when migrating consumers from one implementation to another, evolving the wire protocol or DB schema, or deciding whether to maintain or sunset existing code.
Audit zynk release readiness by comparing commits since the last release tag against the root CHANGELOG.md and README.md, plus version/tag/Nix-hash consistency. Use when asked to run the repo's pre-release audit or to check that the changelog and docs cover what shipped before a zynk release.
Use early when debugging a medium or hard bug, especially when tests alone may not reveal the real runtime failure. Trigger this before extended TDD iteration when a bug involves runtime state, PTY/terminal ordering, persistence, streaming, async/concurrency, the TUI/manual reproduction, the IPC socket layer, or when a red or newly passing test may not model the real issue. Skip only when the root cause is already directly proven by a stack trace or deterministic test that exercises the real runtime path.