Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

verify

Sterne3

Forks1

Aktualisiert10. Juli 2026 um 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

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

jpgomesr

jpgomesr/neuralvault

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

Softwarequalitätssicherungsanalysten und -testerInformatik- und Mathematikberufe·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).

Mehr aus diesem Repository

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