メニュー
Verify recent changes with the right checks. Use for "verify", "did it work", "check the change", and pre-commit validation.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
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.
