Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

verify

Estrelas3

Forks1

Atualizado10 de julho de 2026 às 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.

Instalação

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ê.

Executar no Manus

Fonte

jpgomesr

jpgomesr/neuralvault

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·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).

Mais deste repositório

mesmo repositório

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).