memex-verify
Acerca de
La habilidad `memex-verify` ejecuta una puerta de pre-commit local para el repositorio memex, realizando verificaciones de formato, análisis estricto de clippy y la suite de pruebas unitarias para reflejar el CI. Úsala antes de confirmar cambios en las crates de Rust o cuando depures fallos del CI localmente. Opcionalmente puede ejecutar pruebas de integración si el contenedor de Postgres está activo, sirviendo como una detección temprana de fallos en lugar de un reemplazo del CI.
Instalación rápida
Claude Code
Recomendadonpx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/memex-verifyCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
Verify the Memex Repo Before Committing
Run memex's three CI gates locally — cargo fmt --check, cargo clippy
with warnings denied, and the workspace test suite — so a red CI is caught
on your machine before you push. Optionally extend the run with the
Postgres-gated integration suite. This complements, and does not replace,
memex's own CI (.github/workflows/ci.yml); CI stays the authority.
When to Use
- Immediately before invoking
commit-changeson a memex working tree. - After editing any Rust source under
crates/(cli, sync, db, mcp, extract),Cargo.toml, orrust-toolchain.toml. - When a memex CI run went red and you want to reproduce the failing gate locally with the same toolchain.
- Before opening a pull request against
pjt222/memex.
Inputs
- Required: A checkout of the memex repo (a clone of
github.com/pjt222/memex) withcwdset to the repo root. The gates readrust-toolchain.toml(pinned1.96.0+ rustfmt/clippy components), so run from the root, not a subcrate. - Required: A Rust toolchain on
PATH(rustupprovisions the pinned channel viarustup show). Confirm withcommand -v cargo. - Optional (integration gate only): A running Postgres+pgvector on
:5433(thememex-pgcontainer) and a sourced.envsupplyingMEMEX_TEST_PG_URL(andVOYAGE_API_KEYfor embedding-backed tests).
Procedure
Step 1: Confirm the toolchain and working directory
The gates must run from the repo root so rust-toolchain.toml selects the
pinned 1.96.0 toolchain — local and CI rustfmt/clippy then match.
# From the memex repo root
test -f rust-toolchain.toml || { echo "not at memex repo root"; exit 1; }
rustup show # provisions/reports the pinned 1.96.0 toolchain
command -v cargo # toolchain must be on PATH
Expected: rust-toolchain.toml exists, rustup show reports the
active toolchain as 1.96.0, and cargo resolves to a path.
On failure: If you are not at the repo root, cd there first. If
cargo is missing, add it to PATH (e.g. export PATH="$HOME/.cargo/bin:$PATH")
and re-run.
Step 2: Gate 1 — format check
Mirrors the CI rustfmt job (cargo fmt --all --check). Read-only: it
reports formatting drift without rewriting files.
cargo fmt --all --check
Expected: Exit 0 and no diff output — the tree is already formatted.
On failure: Non-zero exit prints the unformatted hunks. Apply the
fix with cargo fmt --all, re-stage, and re-run this gate. Mark the
overall verify FAIL until this gate is clean.
Step 3: Gate 2 — clippy with warnings denied
Mirrors the CI clippy step (cargo clippy --workspace --all-targets -- -D warnings).
--all-targets lints tests and examples too; -D warnings makes any
lint a hard error, matching CI exactly.
cargo clippy --workspace --all-targets -- -D warnings
Expected: Exit 0 with no warnings emitted.
On failure: Each warning is promoted to an error and listed with its
lint name and source span. Fix the code (or, only when justified, add a
scoped #[allow(...)]), then re-run. Mark the overall verify FAIL until
clean.
Step 4: Gate 3 — workspace unit tests
Mirrors the CI unit-tests step (cargo test --workspace). This runs the
non-ignored suite across every crate.
cargo test --workspace
Expected: Exit 0 and a test result: ok. line for each crate's test
binary. The unit count is ~49 at v0.4.0 and grows per milestone
(M5 adds watcher tests). Treat the count as informational only — assert
on exit 0 / test result: ok, never on a specific number.
On failure: A non-zero exit and test result: FAILED. name the
failing tests. Reproduce a single one with
cargo test --workspace <test_name> -- --nocapture, fix, and re-run.
Mark the overall verify FAIL.
Step 5: Gate 4 (optional) — Postgres-gated integration suite
The #[ignore]-gated integration suite is omitted from CI today (it needs
a Postgres+pgvector service and a VOYAGE_API_KEY secret — see
docs/CONTINUE_HERE.md §5). Run it locally only when the database and
.env are available; skip this gate otherwise without failing verify.
# Only when the memex-pg container is up and .env is sourced:
docker start memex-pg # idempotent if already running
set -a && . ./.env && set +a # exports MEMEX_TEST_PG_URL, VOYAGE_API_KEY, ...
MEMEX_TEST_PG_URL="$MEMEX_TEST_PG_URL" cargo test --workspace -- --include-ignored
Expected: Exit 0 with test result: ok. including the integration
binaries. The total is ~60 at v0.4.0 (unit + ~11 integration) and
also grows per milestone — informational only.
On failure: If the suite fails because Postgres is unreachable or
MEMEX_TEST_PG_URL is unset, that is an environment gap — note it as
"integration gate skipped" rather than a code FAIL. If it fails with
actual test result: FAILED., treat it as a real FAIL and fix.
Step 6: Report per-gate results and the overall verdict
Summarize each gate (PASS/SKIP/FAIL) and the rolled-up verdict.
# Conceptual rollup: overall is non-zero if ANY required gate failed.
echo "fmt: <PASS|FAIL> clippy: <PASS|FAIL> unit-tests: <PASS|FAIL> integration: <PASS|SKIP|FAIL>"
Expected: Gates 1–3 (required) all PASS. The integration gate is PASS or SKIP. Overall verdict PASS.
On failure: Exit non-zero overall if ANY required gate (1–3) or a
non-skipped integration run failed. Do not proceed to commit-changes
until the verdict is PASS.
Validation
- Run from the memex repo root (
rust-toolchain.tomlpresent;rustup showreports1.96.0) -
cargo fmt --all --checkexits 0 with no diff -
cargo clippy --workspace --all-targets -- -D warningsexits 0 -
cargo test --workspaceexits 0 withtest result: ok.per crate - Test counts reported as informational (
~49unit /~60total at v0.4.0), never asserted as a pass/fail threshold - Integration gate either run (Postgres up +
.envsourced) and green, or explicitly recorded as SKIPPED - Overall verdict is non-zero if any required gate failed
Common Pitfalls
- Asserting a fixed test count. Counts grow each milestone; a literal
assert 49turns a healthy run red. Assert exit 0 /test result: okand report the count as~N at v0.4.0. - Running from a subcrate. Outside the repo root,
rust-toolchain.tomlis not picked up, so local fmt/clippy can drift from CI's1.96.0and give false greens or reds. Always run from the root. - Treating a skipped integration gate as a failure. No Postgres / no
.envmeans SKIP, not FAIL. Onlytest result: FAILED.on a run that actually executed is a real failure. - Dropping
--all-targetsfrom clippy. Without it, lints in test and example code are missed, so local clippy passes while CI fails. Match CI's--workspace --all-targets -- -D warningsexactly. - Treating this as a CI replacement. This is a local early-warning
gate. The authority remains
.github/workflows/ci.yml; a green local run does not exempt a PR from CI. - Forgetting to source
.envbefore the integration gate. A.env-loading gotcha is documented indocs/OBSERVATIONS.md; export the file (set -a && . ./.env && set +a) soMEMEX_TEST_PG_URLreaches the test process.
Related Skills
memex— the umbrella skill for agent-native shared memory; this gate guards commits made within its workflow.memex-wrap— session-close ritual; run memex-verify as its pre-commit gate before the wrap commits.memex-init— session-start ritual that pairs with this close-side gate.commit-changes— the next step once all required gates pass.
Repositorio GitHub
Frequently asked questions
What is the memex-verify skill?
memex-verify is a Claude Skill by pjt222. Skills package instructions and resources that Claude loads on demand, so Claude can perform memex-verify-related tasks without extra prompting.
How do I install memex-verify?
Use the install commands on this page: add memex-verify to Claude Code as a plugin, or clone its repository into your skills directory, then restart Claude so it picks up the skill.
What category does memex-verify belong to?
memex-verify is in the Testing category, tagged ai, testing and design.
Is memex-verify free to use?
Yes. memex-verify is listed on AIMCP and free to install. It runs inside Claude, so no separate service account is required to use the skill itself.
Habilidades relacionadas
Esta Skill de Claude ejecuta el benchmark lm-evaluation-harness para evaluar modelos de lenguaje en más de 60 tareas académicas estandarizadas como MMLU y GSM8K. Está diseñada para que los desarrolladores comparen la calidad de los modelos, realicen seguimiento del progreso del entrenamiento o reporten resultados académicos. La herramienta admite varios backends, incluidos modelos de HuggingFace y vLLM.
Esta habilidad proporciona conocimiento integral para implementar Cron Triggers de Cloudflare y programar Workers mediante expresiones cron. Cubre la configuración de tareas periódicas, trabajos de mantenimiento y flujos de trabajo automatizados, manejando problemas comunes como expresiones cron inválidas y inconvenientes de zonas horarias. Los desarrolladores pueden utilizarla para configurar manejadores programados, probar activadores cron e integrar con Workflows y Green Compute.
Esta habilidad de Claude proporciona un kit de herramientas basado en Playwright para probar aplicaciones web locales mediante scripts de Python. Permite verificación de frontend, depuración de interfaz de usuario, captura de pantallas y visualización de registros, mientras gestiona los ciclos de vida del servidor. Úsela para tareas de automatización de navegadores, pero ejecute los scripts directamente en lugar de leer su código fuente para evitar contaminación del contexto.
Esta habilidad ayuda a los desarrolladores a completar el trabajo terminado verificando que las pruebas pasen y luego presentando opciones estructuradas de integración. Guía el flujo de trabajo para fusionar, crear PRs o limpiar ramas después de que se completa la implementación. Úsala cuando tu código esté listo y probado para finalizar sistemáticamente el proceso de desarrollo.
