القائمة
Summarise the unit and e2e tests a branch/PR adds, run only those, and produce a paste-ready report (e.g. for a Linear card). Use when asked to 'summarise added tests', 'run the new tests', 'what tests did this PR add', or to prove a card's test coverage.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Maintain a support docs pack — dedup, length budgets, and no splintering — and land changes as a reviewed pull request. Use when a support thread, or a hand-off from Support assist, surfaces a new resolution, a correction to an existing one, or a deployment quirk worth recording. Not for ordinary code changes.
Run a support investigation as a suggest-and-interpret loop, never executing anything yourself — orient to the product's support pack and follow the signal with judgment. Use when someone asks for help triaging, investigating, or resolving an operational or support issue on a deployment. Not for feature-development cards (see investigate-and-fix and implement-this).
Run the Tamanu release-branch CUTOFF checks when preparing to cut a new release/X.YY branch: confirm the previous release's hotfixes are merged to main, reconcile the commits since the previous release against the "Merged to main" card list from Linear, and scan for data/reporting/schema changes. Use when the user is cutting a Tamanu release and wants to verify the codebase is ready, wants to check main against the previous release branch, or wants to reconcile commits with a Linear "Merged to main" column (they should paste the card list). Handles Tamanu's train-release model (release/X.YY branches vs vX.YY.Z patch tags) and the cherry-pick model where the same logical fix has different SHAs on different branches. Purely git-based — no live database or Canopy access needed. Not for verifying an existing release branch's hotfix integrity (see pre-release-checks) or for deciding which tests to run (see scope-tamanu-release-tests).
Check upgrade safety for a Tamanu upgrade that spans many versions: verify that every intermediate hotfix is included in the target version, and surface the new configuration/settings, data migrations, and FHIR rematerialisation impact the upgrade brings. Use when the user wants to check an upgrade from one Tamanu version to another (e.g. "check hotfixes from v2.31 to v2.47"), confirm no intermediate hotfix was dropped, or understand what config, migrations, and FHIR rework a multi-version jump requires. Handles Tamanu's train-release model (release/X.YY branches vs vX.YY.Z patch tags) and the cherry-pick model where the same logical fix has different SHAs on different branches. Purely git-based — no live database or Canopy access needed. Not for cutting a release (see release-cutoff-checks) or deciding which tests to run (see scope-tamanu-release-tests).
Run Tamanu pre-release verification checks: verify that hotfixes on the current release branch are merged forward to main, and that hotfixes from prior release branches are included in the current release. Use when the user wants to run "pre-release checks", verify hotfix integrity before cutting or shipping a Tamanu release, confirm a release/X.YY branch is safe to release, or check that no hotfix has been orphaned (left on neither main nor the current release). Handles Tamanu's train-release model (release/X.YY branches vs vX.YY.Z patch tags) and the cherry-pick model where the same logical fix has different SHAs on different branches. Purely git-based — no live database or Canopy access needed. Not for deciding which tests to run (see scope-tamanu-release-tests).
Draft or refine the project's PRD from the description and conversation
| name | added-test-summary |
| description | Summarise the unit and e2e tests a branch/PR adds, run only those, and produce a paste-ready report (e.g. for a Linear card). Use when asked to 'summarise added tests', 'run the new tests', 'what tests did this PR add', or to prove a card's test coverage. |
| model | inherit |
Report the tests a branch adds (vs its base), run only those, and format a paste-ready summary. Count only genuinely-new tests — new test files, plus new cases inside modified files; never pre-existing ones.
The branch's PR base, else main:
BASE=origin/$(gh pr view --json baseRefName -q .baseRefName 2>/dev/null || echo main)
git fetch "${BASE#origin/}"
# new test files — every case in these is new (.test.* = unit, .spec.* = e2e)
git diff --name-status --diff-filter=A "$BASE"...HEAD | grep -iE '\.(test|spec)\.(js|ts|jsx|tsx)$'
# modified test files — only some cases may be new
git diff --name-status --diff-filter=M "$BASE"...HEAD | grep -iE '\.(test|spec)\.(js|ts|jsx|tsx)$'
# new cases within a modified file
git diff "$BASE"...HEAD -- <file> | grep -E '^\+\s*(it|test)(\.(only|skip|each))?\('
Count only it/test. A describe/test.describe is a suite wrapper, not a test — count the cases inside it, not the wrapper.
Pick the runner from the package's own test script (check it; don't assume). Run under the repo's Node (.node-version) against local Postgres:
@tamanu/database, @tamanu/web: npx vitest run <file> [-t "<substring>"]@tamanu/shared, @tamanu/central-server, @tamanu/facility-server: NODE_ENV=test npx jest <file> [-t "<substring>"] --verbose@tamanu/e2e-tests (*.spec.ts): npx playwright test <file> [-g "<title>"]Always pass the specific file — never a bare workspace script (npm test, npm run e2e-test), which runs the whole suite. Run a new file whole; use -t/-g to scope a modified file to its new cases.
When a runner can't run locally, cite the branch's CI run (gh run list --branch <branch> → gh run view --log) instead of reporting a false failure:
node_modules (e.g. an es-toolkit/compat / defaultsDeep error) → jest won't run;packages/e2e-tests/.env (FACILITY_FRONTEND_URL, TEST_EMAIL, TEST_PASSWORD). Without it, list the added specs/cases from the diff and pull pass/fail from CI.Head with the branch + commit SHA. Group by runner → file, one line per added case (✓, or the CI status when cited). Don't collapse to per-file counts — show each test name. End with per-runner and grand totals of added tests; keep pre-existing/skipped cases out of the totals (mention them only to explain a -t/-g filter), and mark any runner cited from CI.