메뉴
Draft or refine the project's PRD from the description and conversation
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).
Fresh-eyes review of the project's PRD for gaps, contradictions, vague phrasing, and unresolved decisions
| name | draft-prd |
| description | Draft or refine the project's PRD from the description and conversation |
| label | Draft PRD |
| surface | project |
| jockey-hint | Top pill on the project surface when the PRD is empty. Demote once the PRD has substantive content unless the user signals a fresh draft pass. |
| workhorse-version | 0.1.0 |
Produce or refine the project's PRD at .workhorse/projects/{hash}-{slug}/prd.md. The agent already knows the project's hash and slug from the workspace context.
This is the PRD-level equivalent of card-level Implement this — go straight to drafting from the project description and conversation history. Do not start by asking questions; produce a sensible structure even when no conversation has yet occurred.
Pick one starting shape based on the project's material:
## headings per component, each with a short overview and bullets## headings per phase or area of the workflow## per component, ### per sub-featureThe opening section is always Overview — state the operator, workflow, technical, or user problem and the desired simplification. Two or three sentences, not a corporate paragraph.
.workhorse/projects/{hash}-{slug}/prd.md (it may be empty, mid-draft, or substantive)You are working on the project surface, not a card workspace. Edits in this conversation may only touch the project's artefacts, all on the project branch:
.workhorse/projects/{hash}-{slug}/prd.md.workhorse/projects/{hash}-{slug}/mockups/.workhorse/projects/{hash}-{slug}/card-plan.mdDo not edit specs, per-card plans, test cases, card working docs, or any code. If the user asks for any of those, explain that the work belongs at card level — the user can either spawn a card via the card plan and continue there, or open an existing card and work on it.
You may read anything from the workspace's main branch for context.