| name | ppt-tests |
| description | Pick the smallest correct test command for the change at hand — backend, frontend, integration, or mobile. |
| when_to_use | You have a diff staged and need to verify it without re-running everything; or you need to satisfy IG3 (failing-on-main test) before a PR. |
| mode | both |
| capabilities | ["C6"] |
| tags | ["workflow"] |
PPT Tests
Map of change → test command. The implementer prompt requires that you
quote just check and just test outputs in the PR body — but during the
loop you usually want a narrower command. This skill is that map.
When to invoke
You touched code and want to know "what's the fastest signal here?".
What it gives you
- Stack → command lookup
- Filter syntax per runner
- IG3 two-commit TDD pattern (failing-on-main proof; no
git stash)
Inputs
- Knowledge of which area you touched (
backend/, frontend/, mobile-native/)
- (optional) a test name or path glob
Steps
Backend (Rust)
just test-backend
cd backend && cargo test -p <crate> -- <filter>
cd backend && cargo test --workspace -- <pattern>
just test-integration
Workspace members: common, api-core, admin-core, db, integrations,
tenant-ops, api-server, reality-server, deploy-server.
Frontend (pnpm workspace — Vite for ppt-web, Next.js for reality-web)
just test-frontend
cd frontend && pnpm -F @ppt/web test
cd frontend && pnpm -F @ppt/api-client test
Apps under frontend/apps/: ppt-web, reality-web, mobile (RN/Expo).
Integration
just test-integration
Requires a populated database — bring postgres up via ppt-dev-stack
first; this repo has no just seed recipe so seed via the in-crate
helpers (backend/crates/db/src/seed/) or per-test factories.
Mobile-native (Kotlin / Gradle)
cd mobile-native && ./gradlew test
cd mobile-native && ./gradlew :shared:test
cd mobile-native && ./gradlew test --tests "*<filter>*"
ADB-driven UI checks are C5, local-only — see ppt-mobile-native.
IG3 — failing-on-main test (two-commit pattern)
For vector bug or test-gap, or any plan sourced from a revert-… /
risky-churn-… signal (see routine-prompt.md Phase 1 signal table; the
vector for such plans is typically bug). Do not use git stash —
it only isolates uncommitted work, so once the fix is committed (required
to be in the PR) stash can't separate it from the test. See
implementer-prompt.md
for the canonical rule.
The pattern:
git add <test-path> && git commit -m "test: add regression for <issue>"
TEST_SHA="$(git rev-parse HEAD)"
cargo test -p <crate> -- <test_name>
git add <fix-paths> && git commit -m "fix: <issue>"
cargo test -p <crate> -- <test_name>
Quote both runs in the PR body under ## IG3 — failing test on main,
along with the two commit SHAs so reviewers can git checkout either side.
Deterministic verification
just --list >/dev/null && echo OK
just --list | grep -E 'test-backend|test-frontend|test-integration' | wc -l
cargo --version >/dev/null && echo OK
pnpm --version >/dev/null && echo OK
Smoke check (single command)
just --list | grep -qE '^\s+(test-backend|test-frontend|test-integration)\b'
After-task verification
just check && just test
Cross-references