Run any Skill in Manus with one click

verify

Stars3

Forks1

UpdatedJuly 10, 2026 at 23:25

This skill should be used before committing a nontrivial NeuralVault change, or when asked "verify this works", "check this end-to-end", "does this pass CI". Mirrors NeuralVault's actual CI gates (ci-api.yml, ci-web.yml, the swagger-drift check, test-coverage-web.yml) and describes how to exercise the affected flow live, not just run tests.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

jpgomesr

jpgomesr/neuralvault

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	verify
description	This skill should be used before committing a nontrivial NeuralVault change, or when asked "verify this works", "check this end-to-end", "does this pass CI". Mirrors NeuralVault's actual CI gates (ci-api.yml, ci-web.yml, the swagger-drift check, test-coverage-web.yml) and describes how to exercise the affected flow live, not just run tests.

Verifying a NeuralVault change

Two parts. Running only the first without the second is not a complete verification — CI passing doesn't mean the feature works.

1. Automated checks (mirror CI exactly)

Run only the side(s) that changed.

Backend (api/) — mirrors ci-api.yml:

cd api
go test ./... -race
golangci-lint run
go build ./cmd/server

If a swaggo annotation changed (a handler doc comment), also check for swagger drift — CI fails the build if api/docs is stale:

make swag
git diff --quiet -- api/docs || echo "swagger docs are stale — commit the regenerated api/docs"

Per AGENTS.md, only run make swag when annotations actually changed, not routinely.

Frontend (web/) — mirrors ci-web.yml + test-coverage-web.yml:

cd web
npm run lint
npm run type-check
npm run test          # vitest run — real, CI-enforced, not listed in AGENTS.md's own command block historically
npm run build

2. Drive the actual flow

Tests and lint confirm the code compiles and known cases don't regress — they don't confirm the feature works. Start the app (see the run skill) and exercise the specific path the change touches:

Sources/ingestion change → upload a file via the UI or POST /sources, watch GET /sources/{id}/status (SSE) reach indexed, confirm chunks via GET /sources/{id}/chunks
Retrieval/query change → ask a question via the chat UI or POST /query / POST /query/stream, confirm the answer is grounded in real chunks with correct source citations
Auth/workspace change → sign out and back in as the seeded dev user, confirm the session cookie and workspace membership guard (403 on cross-workspace access) behave as expected
Config/provider change → restart the API and confirm it starts cleanly with the new config; if a provider was swapped, confirm the concrete implementation is wired only in cmd/server/main.go

Skip this step only for changes with no runtime surface (docs-only, test-only diffs).

More from this repository

same repository

retrieval

jpgomesr/neuralvault

This skill should be used when modifying api/internal/retrieval/ (query, streaming answers, chunk hydration), or when asked "how does retrieval work", "why re-filter after Qdrant already filtered", "add a new caller of loadChunks", "why does Retrieve query Postgres full-text too". Documents four non-obvious invariants in the retrieval pipeline that look redundant or arbitrary but aren't.

2026-07-133

auth

jpgomesr/neuralvault

This skill should be used when modifying api/internal/auth/ (login, session, RequireUser middleware), or when asked "how does login work here", "how are sessions handled", "add a protected route". Documents the three login surfaces and the custom session scheme, since neither is a standard JWT/OIDC-library setup.

2026-07-103

code-review

jpgomesr/neuralvault

This skill should be used automatically before finishing a nontrivial NeuralVault diff, or when asked to "review this", "check this against conventions", "does this follow the codebase style" — without requiring the explicit /review command. Checks a diff against NeuralVault's own layering and terminology rules.

2026-07-103

go-feature-domain

jpgomesr/neuralvault

This skill should be used when adding or modifying a feature domain under api/internal/ (auth, health, retrieval, sources, workspaces, or a new one), or when asked "how do I add a new endpoint/domain", "where does this logic go", "how are Go tests structured here". Documents the three-file domain layout, its justified exceptions, and the testing conventions.

2026-07-103

go-provider-interface

jpgomesr/neuralvault

This skill should be used when adding a new backend to embedding, llm, vectorstorage, objectstorage, or storage (e.g. "add an OpenAI provider", "add a new LLM backend", "swap the vector database"), or when asked how NeuralVault's pluggable-provider pattern works. Documents the interface-package shape, the fail-fast startup convention, and two known exceptions that look like bugs but aren't.

2026-07-103

ollama

jpgomesr/neuralvault

This skill should be used when modifying api/internal/embedding/ollama/ or api/internal/llm/ollama/, or when asked "why did the server fail to start over Ollama", "how does streaming work here", "add timeout handling to the LLM client". Documents the fail-fast model check and why the LLM client has no HTTP timeout.

2026-07-103

name	verify
description	This skill should be used before committing a nontrivial NeuralVault change, or when asked "verify this works", "check this end-to-end", "does this pass CI". Mirrors NeuralVault's actual CI gates (ci-api.yml, ci-web.yml, the swagger-drift check, test-coverage-web.yml) and describes how to exercise the affected flow live, not just run tests.

Verifying a NeuralVault change

Two parts. Running only the first without the second is not a complete verification — CI passing doesn't mean the feature works.

1. Automated checks (mirror CI exactly)

Run only the side(s) that changed.

Backend (api/) — mirrors ci-api.yml:

cd api
go test ./... -race
golangci-lint run
go build ./cmd/server

If a swaggo annotation changed (a handler doc comment), also check for swagger drift — CI fails the build if api/docs is stale:

make swag
git diff --quiet -- api/docs || echo "swagger docs are stale — commit the regenerated api/docs"

Per AGENTS.md, only run make swag when annotations actually changed, not routinely.

Frontend (web/) — mirrors ci-web.yml + test-coverage-web.yml:

cd web
npm run lint
npm run type-check
npm run test          # vitest run — real, CI-enforced, not listed in AGENTS.md's own command block historically
npm run build

2. Drive the actual flow

Tests and lint confirm the code compiles and known cases don't regress — they don't confirm the feature works. Start the app (see the run skill) and exercise the specific path the change touches:

Sources/ingestion change → upload a file via the UI or POST /sources, watch GET /sources/{id}/status (SSE) reach indexed, confirm chunks via GET /sources/{id}/chunks
Retrieval/query change → ask a question via the chat UI or POST /query / POST /query/stream, confirm the answer is grounded in real chunks with correct source citations
Auth/workspace change → sign out and back in as the seeded dev user, confirm the session cookie and workspace membership guard (403 on cross-workspace access) behave as expected
Config/provider change → restart the API and confirm it starts cleanly with the new config; if a provider was swapped, confirm the concrete implementation is wired only in cmd/server/main.go

Skip this step only for changes with no runtime surface (docs-only, test-only diffs).