ワンクリックで
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 職業分類に基づく
Proactively hunt for cdkrd bugs by deploying real CDK stacks that exercise common-but-untested AWS resources, configs, and CloudFormation notations against real AWS, then catch false positives + missed detection and fix what breaks. Use for a periodic "find latent bugs" sweep, not for verifying a specific change.
Discover and delete leftover cdkrd TEST AWS resources (ephemeral stacks + stack-external orphans like IAM roles, log groups, RETAIN resources), then release the bughunt-clean gate. Use as the cleanup phase of /work-issues live-tests and /hunt-bugs, or standalone to sweep test debris. NEVER touches non-cdkrd or production resources.
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, then carry each through merge → pull → release → global install → worktree cleanup. Use when asked to "handle/address filed issues", not to hunt for new bugs (that is /hunt-bugs).
Comprehensive pre-release verification. Run quality checks, docs consistency, a live-test of changed behavior, and a short retrospective before tagging a release.
Check if documentation (README.md, DESIGN.md, docs/) is up to date with recent code changes. Use when code has been modified and docs may be stale.
| 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.
cdk-real-drift (cdkrd) is a solo, local-only repo: there is no GitHub remote, no
PR workflow, and no real-AWS deploy/destroy in this gate. This skill mirrors the
CI workflow (.github/workflows/ci.yml), which runs typecheck / lint+format /
build / unit tests on every push.
Run these sequentially and report results:
vp run typecheck — tsgo --project tsconfig.json --noEmit.vp check --fix — lint + Prettier formatting, with auto-fix. Use this, not
vp run lint:fix: CI runs vp check (which includes formatting), and
lint:fix does NOT touch formatting — so a lint:fix-only run can pass
locally while CI fails with formatting issues on the same branch.vp pack (tsdown ESM bundle to dist/). Invoke vp pack DIRECTLY, not
vp run build: the run-task wrapper caches and can REPLAY a stale dist/
that does not reflect the current src/ — a fresh vp pack always rebuilds.
A stale dist/ has caused a false-negative live-test (a cdkrd check ran an
old binary that lacked the change under test).vp test run (Vitest unit tests; tests/integration/** is excluded by
vite.config.ts). Invoke vp test run DIRECTLY, not vp run test — same
cache-replay foot-gun: vp run test can replay a stale pass.When piping any of the above to tail / head / grep, check the actual
output content for Error / Command failed markers — $? after a pipeline
reflects the LAST stage (usually 0), NOT the build tool's exit. When in doubt,
capture without piping: vp <cmd> > /tmp/out 2>&1; rc=$?; tail -3 /tmp/out; echo "[rc=$rc]".
Report as a table:
| Check | Result |
|---|---|
typecheck (vp run typecheck) | pass/fail |
lint + format (vp check --fix) | pass/fail |
build (vp pack) | 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.
Before treating a failure in a file you did NOT touch as a real (or peer-introduced)
main regression, rule out a stale worktree cache. A long-lived worktree's
tsgo/oxc cache can REPLAY phantom errors from an earlier dependency/lockfile state
(the inverse of the cache MASKING real ones). If CI on main is green and the
failure is in code outside your diff, REPRODUCE it in a throwaway fresh worktree
(git worktree add … main → pnpm install → vp check) before reporting "main is
red" or opening a fix lane — a clean fresh worktree means the error was a local cache
artifact, not a regression.
After all four checks pass, record the check marker so the markgate check
gate is satisfied. The marker captures the current working-tree state of the
gate's scope (src/**, tests/**, package.json, pnpm-lock.yaml,
tsconfig*.json, vite.config.ts — see .markgate.yml); any subsequent edit
in that scope invalidates it and requires re-running /check.
Run from the repo root (cdkrd 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
re-running /check after fixing the failure.