Menu
Guidelines for determining how to test a project based on its contents.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Guidelines for Michael Vorburger's personal Git commit style.
Guidelines for Michael Vorburger's preferred Git workflow.
Java coding, testing, and logging conventions.
Enforces TypeScript and project-specific coding standards, including Bun usage and the zero-warning policy. Use this skill when creating or modifying any TypeScript or configuration files.
Update Nix flake inputs.
Conventions for naming files within the project.
Basé sur la classification professionnelle SOC
| name | testing |
| description | Guidelines for determining how to test a project based on its contents. |
When asked to "test" a project, you must first inspect the repository to determine what testing frameworks or build tools it uses. The correct command depends heavily on the files present in the root directory.
Use the following rules to figure out the correct test command(s). Note that some projects can be "polyglot" (e.g. they contain a Java backend and a TypeScript frontend, or they use Nix), so you may need to run multiple of these.
If the project contains a ./flake.nix at its root:
nix flake checkIf the project contains a pom.xml:
mvn testIf the project smells of Gradle (contains build.gradle, build.gradle.kts, settings.gradle, or gradlew):
gradle check (or ./gradlew check if the wrapper is present)If the project contains a package.json, you need to figure out whether to use npm, bun, or another package manager based on the lockfile present:
bun.lockb or bun.lock is present: run bun install && bun testpackage-lock.json is present: run npm install && npm testyarn.lock is present: run yarn install && yarn testpnpm-lock.yaml is present: run pnpm install && pnpm testnpm install && npm test (or ask the user).