tamanu

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

Fresh-eyes review of the project's PRD for gaps, contradictions, vague phrasing, and unresolved decisions

Split a working doc into the card's specs, plan, and test cases once its shape is clear

Start a working doc — a drafting space where spec-level and implementation thinking co-exist before splitting into specs, plan, and test cases

Produce or refine a project-level mockup illustrating a section of the PRD

Workshop the shape of this project — audience, components, ambiguities — before drafting the PRD

Generate a context-rich briefing prompt for an external agent (Claude Code, Cursor, etc.)

Update npm/yarn/pnpm dependencies using manifest-first, lockfile-aware workflows. Prefer declared version bumps over resolution overrides. Use when updating, upgrading, or patching dependencies; fixing transitive dependency versions; addressing npm audit or CVE findings; or removing stale overrides.

Run a quick UX/UI workshop using ASCII-art sketches

Write automated tests for unticked scenarios in this card's test cases

Draft edits to existing specs (or a new spec if no existing one fits) from the card description

Draft or refine the test-cases checklist for this card

Implement this card

Interview me about this card to develop the acceptance criteria

Diagnose and fix the bug described on this card

Produce an HTML mockup for the UI being discussed

Workshop how to break this card into smaller spawned cards and capture entries in the card plan

Draft or refine the implementation checklist from specs and current code

Pull the current Workhorse release's skills, reference docs, and AGENTS.md framework section onto this card, smart-merging against local edits

Review this card's specs with fresh eyes for gaps, contradictions, and cross-spec impact

Workshop the technical approach and capture notes in the plan

Workshop this idea with me

Check whether this card's code meets the acceptance criteria

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.

Review code changes on this card for likely bugs, regressions, and missed edges

Cherry-pick post-merge commits onto a new follow-up branch

Audit this card's mockups or implementation against the design library

Pull remote changes and reconcile with local work, checking for soft conflicts

Rebase onto latest upstream, checking for soft conflicts

Produce a release test-impact analysis for a Tamanu version upgrade: compare two Tamanu releases and classify every functional area as Full Test, Smoke Test, or Skip, each with a short reason and the Linear card or PR reference. Use when the user wants a test plan, QA scope, regression scope, or "what to test" for a Tamanu release or upgrade, wants to compare or diff two Tamanu versions (e.g. v2.57 to v2.59), or asks which areas changed between two releases. Handles Tamanu's train-release model (release/X.Y branches vs vX.Y.Z tags) and maps changed files and PRs to Tamanu functional sections (Patient Management, Encounters/Charting, Surveys & Programs, Medications, Labs, Imaging, Appointments, Vaccinations, Sync, Settings, Reports, Admin/Permissions, Mobile, etc.). Optionally maps against a regression-testing spreadsheet's sections when one is provided.

Review implementation for common security vulnerabilities