소스 정보
- 저장소
- notque/vexjoy-agent
- 최근 소스 활동
- 2026년 5월 6일 17:43
- 감지된 SKILL.md 언어
- 영어
- 스타
- 415
- 포크
- 44
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
메뉴
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/notque/vexjoy-agent --skill vitest-runner명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
Run the full evidence-to-live implementation workflow for large, multi-system, multi-wave, or CPU-delegated 5 Star Booker GM programs.
Classify user requests and route to the correct agent + skill. Primary entry point for all delegated work.
Structured multi-phase workflows: review, debug, refactor (tidy, clean up, untangle messy code without behaviour change), deploy, create, research.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | vitest-runner |
| description | Run Vitest tests and parse results into actionable output. |
| user-invocable | false |
| allowed-tools | ["Read","Bash","Grep","Glob"] |
| routing | {"triggers":["run vitest","JavaScript tests","TypeScript tests","vite tests","vitest output"],"category":"testing","pairs_with":["test-driven-development","typescript-check","e2e-testing"]} |
This skill runs Vitest tests and parses results into actionable reports. It executes tests in non-interactive mode, extracts failure details (test name, assertion error, stack trace), and organizes results by test file with timing information. Use this skill when tests need to run and results need structured, complete reporting—not when tests need installation, creation, modification, or auto-fixing.
Before running tests, confirm Vitest is installed and configured. Why: Running tests in a non-Vitest project wastes time and produces misleading results. This skill is designed only for Vitest—not Jest, Mocha, or Playwright.
Verify vitest is available:
# Check for vitest configuration
ls vitest.config.* vite.config.* 2>/dev/null
grep -q "vitest" package.json && echo "vitest found in package.json"
If no vitest configuration found, stop and inform the user. Do not attempt to install dependencies or configure Vitest—that is outside this skill's scope.
Execute Vitest using the run subcommand (not bare npx vitest, which starts interactive watch mode and will never complete in a non-interactive shell). Why: Watch mode is interactive and incompatible with automation. The run mode executes all tests once and exits with a status code reflecting pass/fail.
Default execution:
npx vitest run --reporter=verbose 2>&1
For specific files or patterns (optional behavior):
npx vitest run path/to/test.ts 2>&1
npx vitest run --grep "pattern" 2>&1
For coverage reporting (when user requests coverage):
npx vitest run --coverage 2>&1
Capture the full exit code and output. Why: The exit code is the source of truth for pass/fail—code 0 = pass, nonzero = fail. Never assume tests passed based on partial output. Show all failures completely, including test names, assertion errors, and stack traces. Hiding failures prevents users from fixing them.
Extract for each test:
Present output in a format that groups failures by test file and includes complete error details. Why: Users need to see which tests failed, why they failed, and where in the code the assertions failed—this prevents wasted debugging time.
Example format:
=== Vitest Test Results ===
Status: PASS / FAIL (X passed, Y failed, Z skipped)
Failures:
---------
FAIL src/utils/__tests__/helpers.test.ts > parseData > handles null input
AssertionError: expected null to equal { data: [] }
- Expected: { data: [] }
+ Received: null
at src/utils/__tests__/helpers.test.ts:25:10
Summary:
--------
Test Files: 12 passed, 2 failed (14 total)
Tests: 45 passed, 3 failed, 2 skipped (50 total)
Duration: 4.23s
Cause: Vitest not installed or node_modules missing
Constraint: This skill does not install dependencies; it assumes a fully configured Vitest project.
Solution: Advise user to check grep vitest package.json for presence, then run npm install or npm install -D vitest. After installation, re-run this skill.
Cause: Test file patterns don't match vitest.config include/exclude globs Constraint: Test discovery is driven by Vitest's configuration; this skill does not modify vitest.config.ts. Solution: Verify test files exist with correct naming (*.test.ts, *.spec.ts, *.test.js, etc.) and match the patterns in vitest.config include/exclude. Show user the vitest.config.ts to help them debug the mismatch.
Cause: Missing jsdom or happy-dom dependency for DOM tests
Constraint: This skill does not install dependencies or modify configurations.
Solution: Check vitest.config.ts environment setting (likely environment: 'jsdom' or 'happy-dom'). Advise user to install the required devDependency: npm install -D jsdom or npm install -D happy-dom, or @testing-library/jest-dom for additional matchers.
Cause: Too many tests running in shared thread pool
Constraint: This skill runs all tests in the suite; it does not pre-filter by complexity.
Solution: When memory errors occur, advise user to split test execution: run tests in batches by directory (e.g., npx vitest run src/unit/), use --pool=forks for memory isolation, or use --shard=1/N to split the suite across N shards. The user controls which tests to run; this skill respects that choice.
Constraint: Do not auto-fix tests. This skill's role is to report test failures completely, not to fix them. The test may be correct and the implementation wrong—only the user knows. Changing test assertions to make them pass would hide real bugs and violate the skill's scope.
Constraint: Always use npx vitest run, not bare npx vitest. Watch mode is interactive and incompatible with non-interactive execution. The skill must use run mode to ensure tests execute once and exit with a status code.
Constraint: Show all failures completely. Reporting "3 tests failed" without showing which tests or why wastes user time. Stack traces, assertion details, and test names are essential for debugging. Never abbreviate failure output.
Constraint: Respect exit codes as source of truth. The process exit code (0 = pass, nonzero = fail) is the definitive signal. Do not rely on partial output or assumptions about test results.