원클릭으로
check
Run local quality checks (typecheck, lint, build, tests). Quick check during development.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Run local quality checks (typecheck, lint, build, tests). Quick check during development.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | check |
| description | Run local quality checks (typecheck, lint, build, tests). Quick check during development. |
Run all local quality checks. Use during development to verify the current state quickly.
Run these sequentially and report results:
vp check --fix — typecheck + lint + Prettier formatting, with auto-fix. Use this, not vp run lint:fix: the CI workflow runs vp check (which includes Prettier), and lint:fix does NOT touch Prettier formatting — so a lint:fix-only run passes locally but CI fails with Formatting issues found on the same branch. See memory rule feedback_vp_check_vs_lint_fix.md for the underlying gotcha and PR #363 for a concrete trap.vp run buildvp run testReport as a table:
| Check | Result |
|---|---|
typecheck + lint + format (vp check --fix) | pass/fail |
| build | pass/fail |
| tests (N files, M tests) | pass/fail |
If all pass, confirm "All checks passed." If any fail, show the error output and STOP — do not write the commit-gate marker.
After all four checks pass, record a marker so the PreToolUse check-gate hook (see .claude/hooks/check-gate.sh) allows the next git commit. The marker is managed by markgate and captures the current working tree state; any subsequent edits invalidate it and require re-running /check.
Run this from the repo root (cdkd pins markgate via mise, so use mise exec to avoid PATH issues when shims aren't active):
mise exec -- markgate set check
Skip this step if any check failed — a stale or missing marker correctly forces the user (or Claude) to re-run /check after fixing the failure.
Detect and delete leftover AWS resources from cdkd integration tests. Only targets resources matching known cdkd stack name patterns.
Proactively hunt for cdkd bugs by deploying real CDK apps that exercise common-but-untested AWS resources, configs, and CloudFormation notations against real AWS, then fix what breaks. Use for a periodic "find latent bugs" sweep, not for verifying a specific change.
Work through already-filed GitHub issues (typically the bug-hunt's output) end to end — triage safely, pick a few FILE-DISJOINT issues to fix in parallel, claim each on the issue before starting (collision-safe with other agents), verify against real AWS, then carry each through merge → pull → release → rebuild the linked binary → worktree cleanup. Use when asked to "handle/address filed issues", not to hunt for new bugs (that is /hunt-bugs).
Recommend which integration tests to run, based on the integ ledger (staleness / last result) plus the code areas touched by recent commits. Outputs a prioritized list of `/run-integ <name>` commands. Use before a release, after a batch of merges, or when unsure what integ coverage a change needs.
Scaffold a new integration test for cdkd. Creates a minimal CDK app with the specified AWS resources for deploy/destroy E2E testing.
Run integration tests (deploy + destroy) against real AWS. Use when you need to verify cdkd works end-to-end with actual AWS resources.