Skills Plugins MCP Prompt Model 博客 我的中心
Development #api #ai

codex-qa

QA the omo Codex Light edition (lazycodex / packages/omo-codex) itself, in strict isolation so ONLY our plugin is exercised, never the user's real ~/.codex. The first-party method drives the real `codex app-server` against an isolated CODEX_HOME plus a LOCAL mock model (no real API call), and proves a plugin hook fired by asserting hook/started + hook/completed notifications. Also: isolated install verification, per-component hook probes, a tmux TUI smoke, and runtime log observation (RUST_LOG / logs SQLite / /debug-config). Ships tested helper scripts each with a --self-test. Use whenever someone changes anything under packages/omo-codex or wants to QA, smoke-test, verify, or debug the Codex plugin, its hooks/components, the installer/config.toml, the app-server flow, or the Codex TUI. Triggers: codex qa, qa codex, codex-qa, test codex plugin, verify codex hook, codex app-server, lazycodex qa, isolated CODEX_HOME, prove codex hook fired, codex tui test.

DeepseekModel Curated skill Quality Excellent · 90 v1.0.0

Get

https://deepseekmodel.com/api/download.php?id=code-yeongyu-oh-my-openagent-agents-skills-codex-qa-skill-md&format=skill
Download .skill Standard format with system_prompt and model_config, ready for any agent framework
The actual content of the system_prompt field in the .skill file.
name codex-qa description QA the omo Codex Light edition (lazycodex / packages/omo-codex) itself, in strict isolation so ONLY our plugin is exercised, never the user's real ~/.codex. The first-party method drives the real `codex app-server` against an isolated CODEX_HOME plus a LOCAL mock model (no real API call), and proves a plugin hook fired by asserting hook/started + hook/completed notifications. Also: isolated install verification, per-component hook probes, a tmux TUI smoke, and runtime log observation (RUST_LOG / logs SQLite / /debug-config). Ships tested helper scripts each with a --self-test. Use whenever someone changes anything under packages/omo-codex or wants to QA, smoke-test, verify, or debug the Codex plugin, its hooks/components, the installer/config.toml, the app-server flow, or the Codex TUI. Triggers: codex qa, qa codex, codex-qa, test codex plugin, verify codex hook, codex app-server, lazycodex qa, isolated CODEX_HOME, prove codex hook fired, codex tui test. Codex QA QA the omo Codex Light edition ( packages/omo-codex/ , shipped as lazycodex). We exercise OUR plugin in a REAL Codex while touching nothing of the user's setup: an isolated CODEX_HOME + a local mock model means no real API call and the real ~/.codex is never read or written. Each helper script ships a --self-test that asserts its scenario against the live machine, so the scripts are both the QA tools and their own regression checks. Verified against codex-cli 0.140.0 (node, jq, tmux, bun on macOS). Confirm with codex --version ; check a flag with codex <cmd> --help . Golden rules (read before running anything) QA ONLY our plugin. Everything that spawns codex uses an isolated CODEX_HOME (created by cqa_mk_isolated_home ) and a LOCAL mock model provider ( cqa_start_mock ). Never QA against the real ~/.codex , never hit a real model API. The bundled scripts enforce this; if you run codex by hand, export CODEX_HOME="$(mktemp -d)/codex"; mkdir -p "$CODEX_HOME" FIRST (a set CODEX_HOME must already exist or codex hard-errors). Prove the real home stayed clean. Every script shasums ~/.codex/config.toml before and after and asserts it is unchanged. If you script by hand, do the same. The interactive codex is a shell function that injects --profile quotio . Bash scripts bypass it and get the real binary; never rely on the interactive alias. See references/isolation.md . The first-party way to prove a hook fired is the app-server notification stream ( hook/started / hook/completed ), not log scraping. See references/app-server.md . The captured JSON / pane IS the evidence — write it under .omo/evidence/<YYYYMMDD>-<slug>/ (no evidence file == the QA did not happen). Setup cd <this-skill-dir> # .agents/skills/codex-qa bash scripts/lib/common.sh --self-check # confirm deps + isolation harness Docker is the default QA surface. Run this QA inside a disposable container that has the latest codex and a copy of your config, with the host ~/.codex untouched: script/agent/qa-docker.sh (see references/docker-qa.md ). The local scripts below are the fallback for when Docker is unavailable or on Windows. Router: pick your case You need to… Run Deep dive Prove a plugin hook fires in a LIVE Codex turn (first-party) scripts/app-server-drive.sh --plugin app-server.md Prove the app-server driver itself works (no plugin, fast) scripts/app-server-drive.sh --self-test app-server.md Install the LOCAL build into an isolated home + assert it landed scripts/install-verify.sh --self-test install-verify.md Pin ONE component's hook logic deterministically (no codex) scripts/hook-unit-probe.sh --self-test components-hooks.md Smoke the real TUI under tmux (boots, renders, survives) scripts/tui-smoke.sh --self-test logging-debug.md Watch runtime logs while QAing (see reference; RUST_LOG / logs DB / /debug-config ) logging-debug.md Scripts index (each is its own regression test) Script --self-test asserts scripts/lib/common.sh --self-check deps present; isolated CODEX_HOME is created inside a sandbox and auto-removed on exit; mock model serves the Responses SSE; real ~/.codex unchanged scripts/app-server-drive.sh --self-test : a bare turn completes and the mock assistant text comes back. --plugin : installs local omo, drives a turn, and asserts hook/completed for sessionStart,userPromptSubmit scripts/install-verify.sh local omo installs into the isolated home; config.toml enables omo@sisyphuslabs ; component bins + agent TOMLs linked in the sandbox; real ~/.codex unchanged scripts/hook-unit-probe.sh the ultrawork component injects <ultrawork-mode> on an ulw UserPromptSubmit (also a manual --component/--event mode) scripts/tui-smoke.sh the real codex TUI boots in the isolated home, renders, and survives (no early exit); captures the pane To tell a dev dogfood build apart from a published one on a REAL ~/.codex (NOT the isolated QA home), the repo ships bun run install:codex-dev , which stamps the plugin version as dev — visible as the (OmO dev) hook-status prefix every turn and as a [DEV] badge in omo get-local-version . Use it to confirm which build is loaded during manual dogfooding; it writes to the real home, so it is NEVER part of the isolated QA flow above. When TUI visual QA evidence is needed, follow docs/reference/web-terminal-visual-qa.md : render the TUI through the real xterm.js web terminal - NEVER the tmux capture-pane frame, which degrades color and CJK width: node script/qa/web-terminal-visual-qa.mjs --title "Codex TUI QA" \ -- command "codex" --input "{Enter}" \ --evidence-dir .omo/evidence/<slug>/codex-web-terminal The helper runs a real pty, renders it in xterm.js under Chrome, and writes terminal.txt , terminal-ansi.txt , terminal.png (true color), and metadata.json ( --from-file <capture.ansi> replays a saved raw stream). Use that artifact set for TUI visual QA; use app-server-drive.sh --plugin for assertion-grade hook behavior. Match QA to your change scope Component / hook logic ( packages/omo-codex/plugin/components/* ): hook-unit-probe.sh for the exact stdout, THEN app-server-drive.sh --plugin to prove the live wiring. See components-hooks.md . Installer / config.toml ( packages/omo-codex/src/install/* ): install-verify.sh . Anything that affects a live session (hooks, agents, MCP wiring): app-server-drive.sh --plugin , and tui-smoke.sh --plugin if the TUI path matters. Capturing evidence ev= ".omo/evidence/ $(date +%Y%m%d) -codex-qa-<slug>" ; mkdir -p " $ev " bash scripts/app-server-drive.sh --plugin > " $ev /app-server-drive.json" 2>&1 bash scripts/install-verify.sh --self-test > " $ev /install-verify.txt" 2>&1 On /debugging There is no /debugging command in Codex. To observe a run: the app-server notification stream (above), RUST_LOG=debug on the app-server's stderr, the logs SQLite under $CODEX_HOME , the TUI's /debug-config , and the codex debug … subcommands. See logging-debug.md .
Keywords that activate this skill. Click one to copy it.

This skill does not provide trigger words.

The downloaded .skill package contains the following fields.
Field Description
formatFormat tag (skill/v1)
skill_idUnique skill ID
nameSkill name
versionVersion
descriptionDescription
categoryCategories (array)
trigger_wordsTrigger words
tagsTags
sourceSource
source_urlSource URL (this page)
exported_atExported at (set per download)
system_promptSystem prompt body
model_configModel config: provider / model / temperature / max_tokens / top_p
examplesExamples
install_guideImport guide for Coze / Dify / Claude / custom frameworks
The same skill can be exported in different platform formats.
.skill Standard format with system_prompt and model_config, ready for any agent framework Download
.skillpro Enhanced format with scripts, tools, dependencies and hooks Download
.json Plain JSON export with system_prompt and model parameters only Download
Coze Markdown with frontmatter, for Coze platform import Download
Dify Dify DSL, import directly after creating an app Download

每日精选 Skill 推荐,免费送到你邮箱

输入邮箱,每天接收一个精选 AI Agent 技能推荐。完全免费,持续更新。

提交后我们会发送一封确认邮件,点击邮件里的链接才会开始收信。

完全免费,取消任意时间。我们不会发送垃圾邮件。