@hiai-gg/hiai-opencode 0.2.1 → 0.2.2

package/skills/design-templates/clinical-case-report/references/case-formats.md

@@ -0,0 +1,94 @@
+# Case Presentation Formats
+
+Use this reference to choose the correct format for the user's context.
+Read the brief carefully — the format should match the clinical setting.
+
+---
+
+## Format 1: SOAP (Default)
+
+Use for: emergency presentations, ward documentation, clinic letters.
+
+**S — Subjective**
+Chief complaint, HPI (chronological narrative), past medical history,
+medications, allergies, family history, social history.
+
+**O — Objective**
+Vital signs (table), physical examination (by system), investigations
+(labs table, imaging findings, ECG).
+
+**A — Assessment**
+Primary diagnosis with reasoning, differential diagnosis list (3–5 items)
+each with one sentence of supporting or excluding evidence, risk score.
+
+**P — Plan**
+Management steps organised by problem number. Each problem gets:
+investigations ordered, treatments started, consults requested,
+monitoring parameters, and disposition.
+
+---
+
+## Format 2: Conference / Grand Rounds
+
+Use for: teaching cases, grand rounds, case conferences, interesting
+or rare presentations.
+
+Structure:
+
+1. **Opening statement**
+   "We present a [age]-year-old [sex] with [chief complaint]."
+
+2. **Clinical summary**
+   Condensed narrative HPI, 2–4 sentences.
+
+3. **Key findings**
+   Bulleted list of critical exam and investigation abnormalities.
+
+4. **Diagnostic challenge**
+   One paragraph explaining what made this case educationally valuable
+   (unusual presentation, diagnostic difficulty, rare diagnosis, etc.)
+
+5. **Differential discussion**
+   Walk through 3–5 diagnoses in order of likelihood with reasoning.
+
+6. **Final diagnosis**
+   State the confirmed diagnosis with supporting evidence.
+
+7. **Management**
+   Summary of what was done, in chronological order.
+
+8. **Outcome**
+   Patient's course and disposition.
+
+9. **Learning points**
+   2–3 bullet points summarising what clinicians should take from this case.
+
+---
+
+## Format 3: Brief Ward Rounds
+
+Use for: daily ward rounds, post-call handover, ICU reviews.
+This format is short. One screen, fast to read.
+
+Structure:
+
+- **ID line**: [Age][sex] | Day [N] of admission | Admitted for [diagnosis]
+- **Overnight/interval events**: Bulleted. New results, procedures, changes.
+- **Current vitals**: Trend arrow (↑ ↓ →). Flag abnormals.
+- **Active problem list**: Numbered.
+- **Plan by problem**: One line per problem.
+
+Do not include full HPI or examination in this format.
+The reader knows the patient. They need the delta.
+
+---
+
+## Format Selection Guide
+
+| User says | Use format |
+|---|---|
+| "case presentation", "formal rounds", "clinic" | SOAP |
+| "conference", "grand rounds", "teaching case", "interesting case", "rare case" | Conference |
+| "daily review", "ward round", "ward rounds", "handover", "ICU", "post-call" | Brief Rounds |
+| "discharge summary", "clinic letter" | SOAP (narrative variant) |
+| No format specified | SOAP |

package/skills/design-templates/clinical-case-report/references/checklist.md

@@ -0,0 +1,41 @@
+# Clinical Case Report — Quality Checklist
+
+## P0 — Must Pass Before Emitting Artifact
+
+- [ ] Chief complaint or ID line is clearly stated in the opening line
+- [ ] **SOAP / Conference format only:** HPI is written as a chronological prose narrative with at least one timeline marker (e.g. "2 hours prior to presentation"); skip for Brief Rounds
+- [ ] **Brief Rounds format only:** ID line present; interval events / current status documented; active problems listed; plan-by-problem present; full HPI and examination sections are not required
+- [ ] Vital signs are present and physiologically plausible
+- [ ] Vital signs are internally consistent with the diagnosis (allowing for clinical variability — bradycardic shock, medication-blunted tachycardia, afebrile pneumonia, early STEMI with normal troponin, etc.)
+- [ ] Assessment contains a clearly stated primary diagnosis
+- [ ] Plan is present and directly addresses the primary diagnosis
+- [ ] If the plan includes medications: a prescribing-safety block is present before drug recommendations, confirming known inputs (allergies, renal/hepatic function, anticoagulants) and calling out unknowns (weight, bleeding risk, pregnancy); doses defer to "per local formulary/protocol" when key variables are missing
+- [ ] Medication plan is labelled as educational/simulated — not a substitute for clinician judgment
+- [ ] No real patient identifiers (direct or indirect): no names, MRNs, exact dates, locations, images, rare condition combos, occupation details, or verbatim stories from real cases
+- [ ] All data is synthetic, de-identified, or clearly fictional
+- [ ] If based on a real case, apply formal de-identification before use
+- [ ] HTML renders without errors in a browser
+- [ ] All major sections tagged with `data-od-id`
+
+## P1 — Should Pass
+
+- [ ] Past medical history includes conditions relevant to the presentation
+- [ ] Medications list is present
+- [ ] Physical examination findings are organised by system
+- [ ] Differential diagnosis contains 3 to 5 items
+- [ ] Each differential item includes one sentence of supporting or refuting evidence
+- [ ] Lab values use correct units and are within realistic ranges for the diagnosis
+- [ ] Plan is specific — drug names, doses, routes, and frequencies are written out where safety inputs are known; unknown variables defer to "per local formulary/protocol"
+- [ ] Plan is organised by problem using numbered headers
+- [ ] Critical findings are visually highlighted (red callout box)
+- [ ] Document is print-friendly (white background, `@media print` rules present)
+- [ ] A validated risk score is included where applicable (TIMI, GRACE, Killip class + Shock Index for STEMI/cardiogenic shock, CURB-65, qSOFA, Wells)
+
+## P2 — Nice to Have
+
+- [ ] Pertinent negatives documented in HPI and Review of Systems
+- [ ] Imaging findings described in investigations section
+- [ ] Specialist consult noted where clinically indicated
+- [ ] Disposition or follow-up plan included
+- [ ] Monitoring parameters specified (e.g. repeat troponin at 3h and 6h)
+- [ ] Secondary prevention addressed for chronic disease presentations

package/skills/design-templates/critique/SKILL.md

@@ -0,0 +1,258 @@
+---
+name: critique
+description: |
+  Run a 5-dimension expert design review on any HTML artifact in the
+  project — Philosophy / Visual hierarchy / Detail / Functionality /
+  Innovation, each scored 0–10. Outputs a single self-contained HTML
+  report with a radar chart, evidence-backed scores, and three lists:
+  Keep / Fix / Quick-wins. Use when the brief asks for a "design
+  review", "design critique", "5 维度评审", "design audit", or "what's
+  wrong with my design".
+triggers:
+  - "critique"
+  - "design review"
+  - "design audit"
+  - "5 维度评审"
+  - "5-dim review"
+  - "audit my design"
+  - "review my deck"
+  - "review my landing page"
+  - "评审"
+  - "复盘"
+od:
+  mode: prototype
+  platform: desktop
+  scenario: design
+  upstream: "https://github.com/alchaincyf/huashu-design"
+  preview:
+    type: html
+    entry: index.html
+  design_system:
+    requires: false
+  example_prompt: "Run a 5-dimension critique on the magazine-web-ppt deck I just generated — score philosophy / hierarchy / detail / function / innovation, give me Keep / Fix / Quick-wins."
+---
+
+# Critique Skill · 5 维度专家评审
+
+Produce a single-file HTML "design review report" that scores any
+artifact across 5 dimensions and proposes actionable fixes. Inspired by
+the *huashu-design* expert-critique flow.
+
+## When to use
+
+- After the agent (or user) generates an artifact (deck / prototype /
+  landing page) and the user asks "what's wrong with this?" or
+  "review this"
+- As a self-check loop the agent can run on its own output **before**
+  emitting it
+- For comparing two variants of the same design
+
+## What you produce
+
+A single self-contained `<artifact type="text/html">` review report
+including:
+
+1. **Header** — what artifact was reviewed, date, reviewer ("OD ·
+   Critique skill"), 1-line verdict
+2. **Radar chart** (inline SVG, no library) showing the 5 scores
+3. **Five dimension cards**, each with:
+   - Score 0–10 (with band: 0–4 *Broken* · 5–6 *Functional* · 7–8 *Strong*
+     · 9–10 *Exceptional*)
+   - 1-paragraph evidence (cite specific elements / files / lines)
+   - One Keep / Fix / Quick-win bullet
+4. **Combined action lists** at the bottom:
+   - **Keep** — what's working, don't touch
+   - **Fix** — P0 / P1 issues that are visually expensive
+   - **Quick wins** — 5–15 minute tweaks with disproportionate impact
+
+## The 5 dimensions
+
+> Each dimension is independent — a deck can be 9/10 on Innovation but
+> 4/10 on Hierarchy and the report should say so plainly. Don't average
+> away interesting failures.
+
+### 1. Philosophy consistency · 哲学一致性
+
+> Does the artifact pick a clear *direction* and stick to it through
+> every micro-decision (chrome / kicker / spacing / accent)?
+
+**Evidence to look for:**
+- Is there one declared design direction (e.g. Monocle / WIRED /
+  Kinfolk) or is it three styles in a trench coat?
+- Does the chrome / kicker vocabulary stay in one register, or does
+  page 3 say "Vol.04 · Spring" and page 7 say "BUT WAIT 🔥"?
+- Are accent / serif / mono used by the same rule throughout?
+
+**0–4** Three styles fighting each other. **5–6** One direction but
+half the elements drift. **7–8** Coherent, occasional drift on edge
+pages. **9–10** Every element argues for the same thesis.
+
+### 2. Visual hierarchy · 视觉层级
+
+> Can a stranger figure out what to read first, second, third — without
+> being told?
+
+**Evidence to look for:**
+- Is the largest type clearly the most important thing on each page?
+- Do mono / serif / sans roles match the information's *role* (meta /
+  body / display)?
+- Lots of "loud" elements competing? Or a clear primary + secondary +
+  tertiary tier?
+
+**0–4** Everything shouts. **5–6** Hierarchy works on hero pages but
+breaks on body. **7–8** Clear tiers, occasional collision. **9–10** Eye
+moves with zero friction.
+
+### 3. Detail execution · 细节执行
+
+> The 90/10 stuff — alignment, leading, kerning at large sizes, image
+> framing, foot/chrome polish, edge-case spacing.
+
+**Evidence to look for:**
+- Big-stat pages: does the number sit on a baseline, or float?
+- Left/right column tops aligned in `grid-2-7-5`?
+- `frame-img` + caption proportions consistent across pages?
+- Mono labels: same letter-spacing? same uppercase rule?
+- Any orphaned `<br>` causing 1-character lines?
+
+**0–4** Visible tape and string. **5–6** Most pages clean, 1–2
+ragged. **7–8** Polished, expert eye finds 2–3 misses. **9–10**
+Magazine-grade — the kind of detail that makes printed-by-hand
+typographers nod.
+
+### 4. Functionality · 功能性
+
+> Does the artifact *work* for its intended use? Click targets, nav,
+> readability at presentation distance, copy-paste-ability for code
+> blocks, mobile fallback if relevant.
+
+**Evidence to look for:**
+- Deck: keyboard / wheel / touch nav all working? Iframe scroll
+  fallback?
+- Landing: CTA above the fold? Phone number tappable on mobile?
+- Runbook: code blocks copyable, mono font, no smart quotes?
+- Critical info readable from 4m away (large screen presentation)?
+
+**0–4** Visually fine but doesn't accomplish its job. **5–6** Core
+flow works, edge cases broken. **7–8** Robust through normal use.
+**9–10** Defensively engineered — handles iframe / fullscreen / paste
+/ print without flinching.
+
+### 5. Innovation · 创新性
+
+> Does this push past the median? Is there one element that makes
+> people lean in?
+
+**Evidence to look for:**
+- One *unexpected* layout / motion / typographic move that wasn't
+  required?
+- Or 100% safe — could be any deck/landing from any agency?
+- Is the innovation *earned* (matches direction) or grafted on
+  (random WebGL on a Kinfolk slow-living deck)?
+
+**0–4** Generic AI-slop median. **5–6** Competent and unmemorable.
+**7–8** One memorable moment, the rest solid. **9–10** Multiple
+moves you'd steal — but each one obviously serves the thesis.
+
+## Scoring discipline (read before you score)
+
+- **Always cite evidence** — "scored 4 because hero page mixes
+  Playfair display with Inter sans on the same line" beats "feels
+  inconsistent". Numbers without evidence get rejected.
+- **Don't average up** — if Hierarchy is 5 because page 3 is broken,
+  don't bump to 7 because pages 1 and 2 are fine. The score is the
+  *worst sustained band*.
+- **Don't grade-inflate** — a 7 means *strong*, not *acceptable*. If
+  every score is 7+, you're not reviewing critically.
+- **Innovation is allowed to be low** — 5/10 is fine for production
+  deliverables. Don't punish *appropriate* conservatism.
+
+## Workflow
+
+### Step 1 — Acquire the artifact
+
+Three modes:
+
+1. **Project file** — user said "review the index.html I just made":
+   open it from the project folder.
+2. **Pasted HTML** — user pasted code in the chat: read it from the
+   message.
+3. **Generated by you in this turn** — you just emitted an artifact
+   above and want to self-critique: re-read your own `<artifact>`.
+
+If multiple HTML files exist, ask which one (don't review all).
+
+### Step 2 — Read enough to score
+
+Skim the entire `<style>`, then read 6–8 representative content
+blocks. **Do not score from frontmatter alone.** The score depends on
+*executed* design, not declared intent.
+
+### Step 3 — Score with evidence
+
+For each of the 5 dimensions, write the score and a 30–80 word
+evidence paragraph that names specific elements. Use line numbers,
+class names, page numbers.
+
+Example:
+```
+Dimension: Detail execution
+Score: 6 / 10
+Evidence: Stat-cards on page 3 align cleanly (grid-6, 3×2), but on
+page 8 the right column foot sits 2vh higher than the left because
+.callout has 3vh top margin while the figure doesn't. Image captions
+use mono on page 5 but sans on page 7 — pick one.
+```
+
+### Step 4 — Build the action lists
+
+Aggregate the 5 evidence paragraphs into:
+
+- **Keep** (3–5 bullets) — concrete things working that the user must
+  not break in the next iteration. Cite by class / page / element.
+- **Fix** (3–6 bullets) — must-do, ordered by *visual cost saved per
+  minute spent*. Each bullet ≤ 1 sentence.
+- **Quick wins** (3–5 bullets) — 5–15 minutes each, high
+  signal-to-noise (e.g. "swap `display:flex` for `grid` on page 4 to
+  fix the column drift").
+
+### Step 5 — Emit the report HTML
+
+Build a single file:
+
+- Header: artifact name + reviewer credit + date
+- Big radar chart (SVG)
+- 5 dimension cards in a 1-column or 2-column grid
+- Three action lists at the bottom with checkbox affordance
+
+Use the active DESIGN.md tokens if one exists; otherwise default to a
+neutral light theme (off-white background, near-black text, one accent
+for radar fill).
+
+## Output contract
+
+```
+<artifact identifier="critique-<artifact-slug>" type="text/html" title="Critique · <Artifact Title>">
+<!doctype html>
+<html>...</html>
+</artifact>
+```
+
+One sentence before the artifact ("Reviewed X across 5 dimensions, see
+report below.") and **stop after `</artifact>`** — do not paraphrase
+the report in chat; the user will read the artifact.
+
+## Hard rules
+
+- **5 scores, every time** — partial reports (e.g. only 3 dimensions)
+  are not allowed.
+- **Evidence per score** — no "feels off" / "needs work". If you
+  can't cite an element, the score is not justified.
+- **Don't grade-inflate** — overall mean above 8 is suspicious; check
+  yourself.
+- **Don't review your own artifact in the same turn** — the user
+  needs to see it first. Self-critique only on explicit request
+  ("now critique what you just made").
+- **Single-file HTML only** — no external CSS/JS. Inline everything.
+- **Radar chart is mandatory** — gives the report a recognizable
+  silhouette and lets the user spot weak axes at a glance.