القائمة
Use when the user wants to verify a Gaia installation -- "probemos", "verify", "test installation", "gaia-verify"
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when constructing or interpreting the approval handoff envelope between subagent and orchestrator -- sealed_payload schema, approval_id format, APPROVAL_REQUEST contract shape, and reading a granted approval from the DB
Use when producing any agent response
Use when classifying any operation before executing it, or deciding whether user approval is required
Use when a mutative command was blocked by the hook and you need to request user approval, or when presenting a plan for a T3 operation before executing it
Use when the user wants to build, design, or extend a diagram — an architecture overview, a timeline, a planner board, a flow diagram, a presentation, a comparison, or a mind-map — as a portable, data-driven deck rendered from plain YAML. Triggers — "build a diagram", "architecture diagram", "diagram deck", "timeline", "flow diagram", "planner board", "add a page/section/component to the diagram".
Use when the user wants something to run routinely / on a schedule rather than once now -- "tarea programada", "rutinariamente", "cada mañana", "cada N horas", "todas las noches", "schedule", "cron". Covers mounting, structuring, and running an unattended headless task that reports back, plus consuming its reports. NOT for a live in-session agentic loop (that is agentic-loop).
| name | gaia-verify |
| description | Use when the user wants to verify a Gaia installation -- "probemos", "verify", "test installation", "gaia-verify" |
| metadata | {"user-invocable":true,"type":"technique"} |
Confirm that a Gaia installation actually works. Given a workspace and a delivery surface, run the checks that match that surface and report PASS/FAIL. This skill owns the definition of "a healthy install" -- the wire-up checklist and the per-surface checks. It is the check that gaia-release calls at the close of every layer; here it stands alone so the user can invoke it directly against whatever they just installed.
Gaia ships as one npm artifact (@jaguilar87/gaia) reaching a workspace through two surfaces -- npm/pnpm (symlinks + settings.local.json) and the Claude Code plugin (source: npm -- CC installs the package into its plugin cache and reads the package root's inline-hooks plugin.json; there is no dist/ bundle). A change can pass on one surface and break on the other, so the mode you pick must match the surface you are validating.
"probemos" / "verify" / "test installation"
├─ Already installed in a workspace (npm/pnpm), just edited source? -> live
├─ Proving the npm tarball before a release? -> npm-sandbox
├─ Proving the npm tarball as a plugin before a release? -> plugin
└─ Confirming a version already published to npm? -> registry
If the user does not name a mode, ask: "Which mode -- live, npm-sandbox, plugin, or registry?"
Validates a workspace that is already wired (npm/pnpm surface). No build, no temp dir, no cleanup.
Run against the workspace: gaia doctor then gaia status, then the wire-up checklist below. This is the mode gaia-release Layer 1 and Layer 3 call after installing into the target (via gaia dev --workspace <TARGET>, the one-command install).
Validates the npm surface of exactly what a registry publish would ship -- pack, install into a clean sandbox, run the harness, clean up. No accumulated workspace state.
Primary path: gaia release check runs this gate (as gate 2, gaia:verify-install:local) inside the full Layer 2 sequence. To run just this surface in isolation, npm run gaia:verify-install:local (packs, installs into /tmp/gaia-sandbox-<ts>-<pid>/, runs the harness, cleans up) is what gaia release check wraps -- manual step-by-step in reference.md. This is the mode gaia-release Layer 2 gate 2 calls.
Validates the Claude Code plugin surface -- the exact npm tarball, extracted, with its root mounted as a plugin. This is the only mode that exercises the root inline plugin.json / hooks.json, the packaged agents/skills, and bin/gaia on PATH; the npm surface never touches any of it.
Primary path: gaia release check runs this gate (as gate 3, gaia:plugin-dryrun) inside the full Layer 2 sequence, and SKIPs it gracefully when the claude binary is absent. To run just this surface, npm run gaia:plugin-dryrun (bin/plugin-dryrun.sh, what gaia release check wraps) packs the tarball, extracts it to a throwaway temp dir, and runs a headless, offline gate -- filesystem asserts (root inline plugin.json, hooks/hooks.json, bin/gaia, agents/, skills/, and NO dist/) + claude plugin validate. It touches no real workspace and spawns no session; the temps are trap-cleaned. Add gaia release check --functional (or npm run gaia:plugin-dryrun -- --functional) for an optional live claude --plugin-dir <temp> -p '...' probe (needs Claude auth/tokens). This is the mode gaia-release Layer 2 gate 3 calls. Do NOT publish or install to the real registry to run this.
Validates a version already published to npm -- fresh temp dir, install from the registry tag, verify, clean up.
Core flow: npm run gaia:verify-install:rc (the @rc tag) or npm run gaia:verify-install:latest (the @latest / stable tag). Step-by-step in reference.md. This is the mode gaia-release Layer 3 step (h) calls after the pipeline publishes.
After wiring a workspace, these checks catch what gaia doctor cannot reach when the wire-up is so broken that doctor itself walks up to the user .claude/ instead of the workspace. If any check fails, jump to gaia-release/reference.md -> "Diagnostic guide".
ls -la <workspace>/.claude/ -- 5 symlinks (agents, tools, hooks, config, skills) + a CHANGELOG.md link, plus logs/, approvals/, plugin-registry.json, settings.local.json. (_SYMLINK_NAMES + _SYMLINK_FILES in bin/cli/_install_helpers.py.)cat <workspace>/.claude/plugin-registry.json -- installed[].name at the expected version. Decided: the canonical registry identity is gaia (_read_plugin_name in _install_helpers.py strips the npm scope from @jaguilar87/gaia and falls back to "gaia"). A fresh install always writes gaia; fail the check if the name is anything other than gaia.cat <workspace>/.claude/settings.local.json | jq '.hooks | keys' -- hook events registered (npm surface only; the plugin surface reads hooks from the bundle's hooks.json / inline plugin.json, not from settings.local.json).ls ~/.gaia/gaia.db -- DB file exists. It is bootstrapped lazily on first gaia CLI use (_ensure_db_bootstrapped in bin/gaia) or by gaia install -- there is no postinstall.cat ~/.gaia/last-install-error.json -- file does not exist. gaia install writes this marker on any bootstrap or wire-up failure; treat its presence as a hard failure regardless of what gaia doctor reports.cd <workspace> && gaia doctor -- Status: HEALTHY, checks pass, 0 errors.Every mode ends with a structured result:
Mode: <live | npm-sandbox | plugin | registry>
Surface: <npm/pnpm | plugin>
Version: <version installed, or "symlinked source" for live>
Doctor: PASS | FAIL
Status: <`gaia status` output summary>
Checklist: <n/n wire-up checks passed, or n/a>
Cleanup: done | n/a (live)
If gaia doctor fails, report the exact error and stop -- do not continue to gaia status.
gaia is the sole canonical registry identity (check 2). A fresh install that writes anything other than gaia is a real bug.gaia install); if it is missing, run a gaia command, not "re-run postinstall"./tmp/gaia-sandbox-* and registry temp dirs accumulate; always delete after reporting (n/a for live).