Menu
Verify recent changes with the right checks. Use for "verify", "did it work", "check the change", and pre-commit validation.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
How changes are classified, gated, approved, committed, and shipped in the Lamprey Harness repo. Load this BEFORE making any change — code, docs, config, or release — or when you see terms like P-SPR, STS, verify gate, era-lock, commit trailer, push policy, or when a commit/push is rejected by a hook.
How Lamprey runs and ships — run modes, userData layout, Windows release artifacts, the one-command "Bucket" pipeline, macOS/Linux CI mirroring, GitHub publication, CDN purge, and failure recovery. Load when the user says "ship", "release", "tag it", "Bucket", or when a release step fails partway.
The multi-provider LLM domain pack for Lamprey — OpenAI-compatible streaming across 17 built-in providers (frontier labs, open-source hosts, keyless local runtimes) plus user-defined custom endpoints, per-provider quirks (reasoning field names, Anthropic's compat-layer limits, base-URL overrides), capability flags, the native-vs-fallback tool-calling contract, retry/backoff, retired-model handling, and the checklists for adding a model or a provider. Load when touching electron/services/providers/, debugging provider HTTP errors, or adding/retiring models.
Lamprey's load-bearing design decisions, the invariants that must hold, what was deliberately deleted, and the honestly-stated weak points. Load before modifying electron/ipc, electron/services, the provider or tool layers, or the renderer stores — or when you need to know WHY the system is shaped the way it is.
Recreate the Lamprey dev environment from scratch and get past its known traps — Node/Electron/better-sqlite3 ABI story, the ELECTRON_EXEC_PATH dev-server workaround, esbuild antivirus blocks, the tsconfig node/web split, electron-vite and electron-builder specifics. Load when setting up a machine, when npm install / dev server / build fails, or before touching build configuration.
Catalog of every Lamprey configuration axis — AppSettings keys with defaults and readers, inert retired keys, keychain/keys.json, custom models, loop and timeout knobs, environment variables, per-conversation runtime state — plus the exact checklist for adding a setting without breaking the parity-lock test. Load when reading/changing settings.json, adding a setting, or wondering what a flag does or whether anything still reads it.
| name | Verify |
| description | Verify recent changes with the right checks. Use for "verify", "did it work", "check the change", and pre-commit validation. |
| triggers | ["verify","did it work","check the change"] |
Use this skill when the user asks whether work is correct, or after you have edited code.
Start with verify_workspace unless the user gave a more specific check. It infers common test, typecheck, lint, and verify commands from the active workspace. Read its JSON report carefully: passing commands are evidence, skipped commands are gaps, and failed commands need a concrete follow-up.
If the change touched frontend behavior and the user supplied a dev-server URL, use frontend_qa after code checks. Include expected visible text or selectors when the user gave them; otherwise report page health as needs review rather than inventing assertions.
Do not treat a saved file, a successful build step, or a green unrelated command as complete verification. Name exactly what ran and what did not run.
Stop when the relevant checks passed, or when a failure/gap is clearly documented with the next fix or manual check.
