メニュー
Pull the current Workhorse release's skills, reference docs, and AGENTS.md framework section onto this card, smart-merging against local edits
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | pull-workhorse-updates |
| description | Pull the current Workhorse release's skills, reference docs, and AGENTS.md framework section onto this card, smart-merging against local edits |
| label | Pull Workhorse updates |
| pill-order | {"not-started":9,"specifying":14,"implementing":8,"reviewing":8,"complete":5} |
| jockey-hint | Low-traffic maintenance action — surface as an available pill, not a top suggestion. Only promote when the user explicitly asks to pull or update Workhorse's skills, docs, or framework files. |
| workhorse-version | 0.1.0 |
Bring this workspace's Workhorse framework files up to the current release, smart-merging the new bundle against any local edits. The managed files are the skills under .agents/skills/, the reference docs under .agents/docs/, and the framework section at the top of AGENTS.md. The design library under .workhorse/design/ is workspace-owned and out of scope — never touch it here.
Workhorse has materialised the current release's bundle into .workhorse/.pull-bundle/ in this worktree so you can read it directly. That folder is the source of the new versions ("theirs"); the files already in the workspace are "ours". The folder carries its own .gitignore so nothing under it is committed — do not merge it into the repo, and leave the folder for Workhorse to manage.
.workhorse/.pull-bundle/manifest.json — the authoritative list of managed files. Each entry has the target path (relative to the repo root) and the current bundle version. Read this first.workhorse/.pull-bundle/skills/{folder}/SKILL.md — the current version of each shipped skill.workhorse/.pull-bundle/docs/{name}.md — the current version of each shipped reference doc.workhorse/.pull-bundle/AGENTS.section.md — the current framework section, wrapped in its <!-- BEGIN:workhorse <version> --> / <!-- END:workhorse --> markersSKILL.md or a reference doc is Workhorse-shipped only if it carries a workhorse-version frontmatter field. A file without that field is a purely local file — never touch itAGENTS.md framework section is the region between the <!-- BEGIN:workhorse ... --> and <!-- END:workhorse --> markers. Everything else in AGENTS.md is user-owned — never touch itWork through every entry in the manifest, then check for removals:
workhorse-version frontmatterworkhorse-version. Replace it with the bundle version (this just bumps the version)workhorse-version. Smart-merge: take the bundle version as the new baseline and re-apply the user's local intent on top, so the release's improvements land while the user's deliberate edits survive. Set workhorse-version to the bundle's version. Read both files fully and reason about intent — do not do a naive line unionworkhorse-version but has no manifest entry (its path is no longer shipped). Delete it with rm <path>. The user reviews the deletion in the PR and can revert it there to keep it as a local forkAGENTS.md has no Workhorse markers yet, insert the bundle section at the very top of the file. If AGENTS.md doesn't exist, create it containing just the section.claude/skills/ symlink — confirm it exists and points at ../.agents/skills/. If it's missing or points elsewhere, recreate it. If a real file or directory sits at that path instead of a symlink, leave it alone and note itYour changes are committed to this card's branch by the normal auto-commit, and the user reviews them through this card's PR.
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