بنقرة واحدة
ppt-tests
Pick the smallest correct test command for the change at hand — backend, frontend, integration, or mobile.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Pick the smallest correct test command for the change at hand — backend, frontend, integration, or mobile.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Implement one task end-to-end for the PPT project — pick the right per-stack specialist, code, verify per-stack, push a draft PR against `dev`.
Project-management & delivery analysis for the PPT research routine (Phase 1.6). Runs an always-on Scrum Master synthesis plus role-based deep analysis (rotating one role/day by default; all 8 on `full`; a specific role on `pm:<role>`). Reads sprint-status + repo activity + research backlog, spawns role subagents, and writes delivery artifacts under .research/management/. Use from routine Phase 1.6, or standalone for a delivery snapshot.
Post-merge code review with issue creation. Reviews merged PRs in a time window, spots better approaches / missed edge cases / security holes / perf issues / test gaps, and opens GitHub issues with concrete improvement proposals.
Deterministic goal/convergence checks for the PPT dispatcher — coverage referential integrity, coverage-progress monotonicity, and buffer bounds. Run in dispatcher Phase 6 and CI. Use when adding/auditing the dispatcher's goal-verification layer.
Open a PR in this project's style — title, body template, IG3 evidence, CI surface, draft handling.
Land a green, approved PR. Verify preconditions (CI green, approved, no unresolved threads, not draft), auto-resolve mechanical merge conflicts against the base branch (sqlx offline data, Cargo.lock, generated openapi/api-client, lockfiles), then `gh pr merge --squash --auto`. Stops and surfaces if real code conflicts or stale CI.
| 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"] |
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.
You touched code and want to know "what's the fastest signal here?".
git stash)backend/, frontend/, mobile-native/)just test-backend # full workspace
cd backend && cargo test -p <crate> -- <filter> # narrow to one crate / filter
cd backend && cargo test --workspace -- <pattern> # filter across workspace
just test-integration # ignored/integration tests (needs DB)
Workspace members: common, api-core, admin-core, db, integrations,
tenant-ops, api-server, reality-server, deploy-server.
ppt-web, Next.js for reality-web)just test-frontend # all apps + packages
cd frontend && pnpm -F @ppt/web test # single app (package name from its package.json, NOT dir name)
cd frontend && pnpm -F @ppt/api-client test # single package
Apps under frontend/apps/: ppt-web, reality-web, mobile (RN/Expo).
just test-integration # cargo test --workspace --test '*' -- --ignored
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.
cd mobile-native && ./gradlew test # all tests
cd mobile-native && ./gradlew :shared:test # one module
cd mobile-native && ./gradlew test --tests "*<filter>*" # filter
ADB-driven UI checks are C5, local-only — see ppt-mobile-native.
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:
# 1. Commit the failing test on its own
git add <test-path> && git commit -m "test: add regression for <issue>"
TEST_SHA="$(git rev-parse HEAD)"
# 2. Run the test at this point — confirm it FAILS (proves the bug exists)
cargo test -p <crate> -- <test_name> # expected: FAIL
# 3. Commit the fix
git add <fix-paths> && git commit -m "fix: <issue>"
# 4. Run the test at HEAD — confirm it PASSES
cargo test -p <crate> -- <test_name> # expected: PASS
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.
# 1. just is on PATH and the recipes resolve
just --list >/dev/null && echo OK
# expected: OK
# 2. the test recipes referenced above exist
just --list | grep -E 'test-backend|test-frontend|test-integration' | wc -l
# expected: 3
# 3. cargo is on PATH (backend)
cargo --version >/dev/null && echo OK
# expected: OK
# 4. pnpm is on PATH (frontend)
pnpm --version >/dev/null && echo OK
# expected: OK
just --list | grep -qE '^\s+(test-backend|test-frontend|test-integration)\b'
just check && just test # quote tail of each in PR body (IG7)
.research/implementer-prompt.md
§ Verification before opening the PR and IG3, IG7ppt-rust-backend, ppt-frontend,
ppt-mobile-native — per-stack detail