القائمة
Perform a code-review pass focused on bugs and ship readiness. Use for "review this", "before I ship", "code review", and PR checks.
التثبيت باستخدام 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 | Review |
| description | Perform a code-review pass focused on bugs and ship readiness. Use for "review this", "before I ship", "code review", and PR checks. |
| triggers | ["review this","before I ship","code review"] |
Use this skill when the user asks for review rather than implementation.
Inspect the diff and nearby code before judging. Focus on correctness, security, data loss, concurrency, permissions, performance cliffs, and missing tests. Prefer real findings over style commentary. Cite file and line references for every actionable issue.
Use workspace_context when repository state or likely checks are unknown. Use read-only searches freely. Do not edit files unless the user changes the request from review to fix.
Before the verdict, list the failure modes or risks you checked and the evidence consulted for each one: files, diffs, receipts, contracts, tool metadata, or commands actually observed. Also name any unchecked gaps. If no issues are found, say that clearly without inventing one, but still show what you checked.
Output findings first, ordered by severity. For each finding, include severity, file/line, what can go wrong, and the smallest fix.
End with one verdict line: SHIP when no blocking issues remain, or CHANGES when fixes are required.
Stop when the user has enough evidence to merge, revise, or ask for fixes.
