Menu
Workshop how to break this card into smaller spawned cards and capture entries in the card plan
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional 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 | plan-cards |
| description | Workshop how to break this card into smaller spawned cards and capture entries in the card plan |
| label | Plan cards |
| pill-order | {"not-started":8,"specifying":13,"implementing":7,"reviewing":7} |
| jockey-hint | Always available but low-traffic — surface as an available pill, not a top suggestion. Most cards are implemented as one PR; only suggest prominently when the conversation has already revealed the card is too large to ship in one piece. |
| workhorse-version | 0.1.0 |
If you don't already have this card's context (title, identifier, description) — for instance when running outside Workhorse — establish it first by following .agents/docs/card-context.md.
Workshop how to slice this card into smaller spawned cards and capture the breakdown in the card plan at .workhorse/plans/{card-id}/card-plan.md.
The card plan is not the implementation plan. Do not edit .workhorse/plans/{card-id}/plan.md — that is a separate, free-form working document for tech-design notes and build steps. The card plan has a strict shape:
## heading entries, one per spawned card<!-- mockups: ... --> comment) — no checklists, no sub-headings, no nested H3s, no build-step bulletsOnce the user is ready, a bulk Create cards action turns each uncreated entry into a real spawned card based on this one. The parent stays as the umbrella while the children carry the implementation work.
specs/, the card description, and any existing card-plan file at .workhorse/plans/{card-id}/card-plan.md. Ignore plan.md in the same folder — it is a different artifact and not what you are editing herecard-plan.md as ## headings with a short description paragraph beneath. Edit in place as the conversation refines them — adding, splitting, merging, reordering entries is normalcard-plan.md does not yet exist, create it at the path above with an H1 title and the entries underneath. Do not create or edit any other file## heading: <!-- mockups: slug-one, slug-two --> (one comment per entry, comma-separated slugs from .workhorse/design/mockups/{card-id}/). Pick only the mockups that fit each entry — the user can adjust later## heading is the spawned card's title — concise, action-oriented, no trailing punctuation, no code suffix (the editor stamps · CODE automatically once the card is created)See specs/card/card-plan.md for the canonical shape.