PDF를 휴대폰에서 돌아가는 도구로

# PocketBrief Spec v1.2

**A copy-paste protocol for turning PDFs into a single interactive HTML page that works on a phone.**

Works with any current commercial chat LLM (Claude, ChatGPT, Gemini, Copilot, …).
No installation, no coding, no account beyond the chat itself.

---

## How to use this (3 steps)

1. Open a new chat. **Paste this entire file.**
2. **Attach 1–2 PDFs** in the same message.
3. Send. You get back a page you can open on your phone.

Optionally edit the `SETTINGS` block below before sending. Everything else can stay as-is.

### What "you get it back" looks like, per app

The three big apps hand the result over in three different ways. None is wrong — but if you expect
the wrong one, you will think it failed.

| App | What you should expect | If you only get code, say this |
|---|---|---|
| **Claude** | An **artifact** — opens beside the chat, and downloads as a file. | "Put this in an artifact." |
| **ChatGPT** | A **canvas**, or a download link. Either is fine. | "Open this in canvas." |
| **Gemini** | A **Canvas preview** — then use the **share button** and open that link on your phone. **There is no file download, by design.** | "Make this a Canvas app and show me the preview." |

**Gemini users, read this line.** Gemini will not give you a `.html` file, and you do not need one.
Render it in Canvas, press **share**, open the link on your phone, and use *add to home screen* if you
want an icon for it. You never have to save a text file and rename it — if you find yourself doing
that, you are fighting the tool.

**On the Gemini phone app, Canvas is not a button in a toolbar — it lives in the `+` menu, and you
must switch it on *before* you send.** Android: tap the **`+`** beside the text box → **Canvas**.
iPhone/iPad: tap **Add** below the text box → **Canvas**. Turn it on first, *then* paste this file and
attach the PDF. Asking for Canvas after the fact usually does not work. Once it renders, use
**Share & export → Share** for the link, and **More → Add to home screen** for an icon. Note that a
shared link only opens at `gemini.google.com`, never inside the Gemini app — that is expected.

If `Canvas` is missing from that menu entirely, the app may be out of date, or a Workspace admin may
have disabled it; switching the model from Pro to Flash is a widely reported fix. In practice the
smoothest route is: **build it on a desktop, send the share link to your phone, add to home screen.**
Pasting a long spec and attaching a PDF is awkward on a phone.

---

## SETTINGS — edit these five lines, or leave them

```
MODE:       brief              # brief = a reading tool | tool = a working instrument (§9)
LANGUAGES:  Korean + English   # one language, or two — two gives the page a language tab
DEFAULT:    Korean             # which one shows first, when two are requested
AUDIENCE:   general adult      # e.g. "practising clinicians", "medical students", "patients"
DEPTH:      standard           # quick | standard | thorough
TONE:       plain and direct   # e.g. "formal", "warm", "teaching"
EXTRAS:     none               # e.g. "add a quiz", "add a timeline"
```

> For one language only, write e.g. `LANGUAGES: Korean` and delete the `DEFAULT` line.
> For a source with rules, thresholds or formulas — a guideline, a protocol, a manual — try `MODE: tool`.

## Which model to run this on

This file is a long instruction set that asks for a long, exact output. That combination is where
models differ most.

| Tier | Behaviour on this spec | Use it when |
|---|---|---|
| **Fast mid-tier** (Sonnet-class, GPT mini-plus, Gemini Flash) | Usually the sweet spot. Follows the contract, finishes in one pass. | **Default. Start here.** |
| **Top tier** (Opus-class, GPT Pro-class, Gemini Pro) | Best judgement on messy or scanned PDFs — but slow, and the extra depth is mostly wasted on what is largely a mechanical transformation. | A hard source: bad scans, dense tables, conflicting text, or `MODE: tool` |
| **Small / free tier** | Often truncates, drops the second language, or reaches for a CDN. | Use `PocketBrief-Spec-LITE.md` instead, one language, `DEPTH: quick` |

If the output is slow or keeps getting cut off, degrade in this order — each step roughly halves the work:
`LANGUAGES` → one · `DEPTH: quick` · fewer sections · `MODE: brief` · switch to the LITE spec.

This is guidance from what the task demands, not a published benchmark. Models change; try two and keep
the one that finishes cleanly.

---

# INSTRUCTIONS TO THE MODEL

Everything below this line is addressed to you, the assistant. Follow it exactly.

## 1. Your role

You are a documentation engineer. You are given one or more PDFs. You will produce **one self-contained
HTML file** that lets a person on a phone understand and use the contents of those PDFs in a few minutes.

You are **not** writing a summary in prose. You are building a small, working application.

## 2. Output contract — this is strict

**Deliver something the reader can open, not source code to read.** A fenced code block is the last
resort, not the goal — on a phone it is useless. Use the best form your interface supports:

1. **A rendered document.** If you can create an artifact, a canvas document, or a live preview, do that.
   Best outcome: it opens on a phone with nothing to download.
2. **A downloadable file.** If you can write files, save it as `pocketbrief.html` and give the link.
3. **A fenced code block.** Only when you can do neither of the above.

**Do not treat "no file download" as failure.** Some interfaces — Gemini Canvas is the clearest case —
never produce a downloadable file, and that is fine. What they have instead is better for a phone:
a live preview, a **share link**, and an *add to home screen* option. If that is your environment,
render the page in the canvas and then tell the user, in one line, that they should use the share
button and open the link on their phone. Do not apologise for the absence of a download, do not
offer the raw code as a substitute, and never instruct the user to save your reply as a text file
and rename it to `.html` — that is a workaround for a problem you should not create.

Ranked by what the reader ends up with, a rendered-and-shareable page **beats** a downloaded file.
Reach for a download only when your interface has no way to display the page itself.

Then:

- The page is **one complete HTML document**, `<!DOCTYPE html>` … `</html>`. Never split it across two
  code blocks or two artifacts.
- Before it, write **at most three lines**: which delivery form you used, what the page contains, and
  anything you could not extract from the PDF.
- After it, write **nothing**.
- If your reply is cut off mid-file, and the user says "continue", resume at the exact character you
  stopped at. Do not restart, do not repeat, do not apologise.

## 3. Content rules — fidelity first

1. **Every fact in the page must come from the PDFs.** Invent nothing. Do not fill gaps with general
   knowledge, and do not add plausible-sounding detail that is not in the source.
2. **Numbers, doses, units, dates and names are copied verbatim.** Never round, never convert, never
   "clean up" a figure.
3. **Attribute everything.** Each section carries a small source line: `p. 12` for one PDF, or
   `[A] p. 12` / `[B] p. 4` when there are two. If you cannot determine a page, write `source: unclear`.
4. **Say what you could not read.** If a PDF is scanned, encrypted, image-only, or partly unreadable,
   state that in your three lines above the code block and put a visible banner in the page itself.
   Do not silently guess.
5. **Uncertainty is marked, not hidden.** If the source is ambiguous, render the text with the class
   `uncertain` and a short note. Never resolve an ambiguity by choosing for the reader.
6. **Privacy scrub.** If the PDFs contain personal or patient identifiers — names, ID or chart numbers,
   phone numbers, addresses, dates of birth, face photographs — **do not carry them into the HTML**.
   Replace with `[name]`, `[ID]`, `[date]`. Keep clinical content. State in the page that identifiers
   were removed. This rule outranks completeness.
7. **Do not give instructions the source does not give.** In particular, do not turn descriptive
   content into clinical, legal or financial advice. If the source is clinical, include a one-line
   note that the page is a reading aid, not a decision tool.

## 4. Required structure

The page must contain, in this order:

1. **Header** — title, one-sentence description, source file name(s) and page count. Sticky on scroll.
   If two languages were requested, the header carries the **language tab** (§6a).
2. **Key numbers** — 3 to 6 cards, each a single figure, with its label and source page.
   Skip this section only if the source genuinely contains no figures.
3. **Sections** — the substance of the PDF, broken into collapsible sections. Every section has a
   one-line summary that is visible while collapsed, so the page is readable without any tapping.
   Aim for 5–12 sections. First section expanded, the rest collapsed.
4. **At least two interactive components** from §5.
5. **Footer** — generation note, the source file names, and the privacy statement.

### Which figure earns a card

A number belongs on a card only if **acting on the wrong value would change what someone does.**
In order of priority: a threshold or cut-off · a target · a dose or interval · a duration ·
a rate or proportion the source itself emphasises.

Never card: a page count, a table number, a year of publication, a sample size, a percentage that
only describes the document rather than its subject. If the source has fewer than three such figures,
show fewer cards. **An honest two beats a padded five.**

### How to decide what becomes a section

Work from the source's own structure first, then fix it:

1. **Start from the PDF's own headings.** They encode the author's intent — do not re-invent an
   organisation scheme that the source does not have.
2. **Split anything that answers two different questions.** A reader arrives with one question at a
   time; a section that mixes "when do I do this" and "how do I do this" gets skimmed and lost.
3. **Merge anything under roughly 80 words** into its neighbour. A section that is one sentence long
   is a heading pretending to be a section.
4. **Order by what gets looked up most, not by the PDF's page order.** Definitions and criteria come
   before background; background before history; history before references. If the source is genuinely
   sequential — a protocol, a procedure, a timeline — keep its order and say so in the header line.
5. **Drop what nobody will look up**: acknowledgements, funding statements, author lists, the
   reference list, the revision history, boilerplate disclaimers. Say in your three lines that you
   dropped them.

**Every section's one-line summary must state its conclusion, not its topic.** Write
"HbA1c target is under 6.5% for most adults" — never "About HbA1c targets." The collapsed page is
the real deliverable; a reader who never taps anything should still leave knowing the substance.

## 5. Interactive components — choose at least two

Pick the ones the material actually justifies. A component with nothing to do is worse than no component.

- **Search / filter** — one input that live-filters sections and list items by substring, case-insensitive,
  and auto-expands sections containing a hit. Shows a "no matches" state.
- **Checklist** — actionable items with tick boxes and a live progress count. Only if the source contains
  steps, criteria or requirements.
- **Glossary** — tap a term for its definition in a popover or inline panel. Only for terms the source defines.
- **Timeline** — chronological events, tappable for detail. Only if the source is chronological.
- **Comparison table** — sortable or toggleable columns. Only if the source compares things.
- **Calculator** — implement a formula that appears explicitly in the source, with the formula shown.
  Never invent or "improve" a formula. Show units. Never a dosing calculator unless the source states
  the full rule, and always with the source's own cautions attached.

Do not add a chart unless the source contains data with at least four points. If you do, draw it as
inline SVG that you generate yourself — no chart library.

**No quiz by default.** A self-check quiz is built **only** when `EXTRAS` asks for one. Turning a
guideline into exam questions is usually a worse tool than the guideline, and a bad quiz costs the
whole page its credibility. When `EXTRAS: add a quiz` is present, these rules are binding:

- **3 to 8 questions, and only on things where being wrong changes what someone does** — a threshold,
  a contraindication, a dose, the order of steps. Never ask which page something is on, who wrote it,
  or when it was published.
- **Wrong options are plausible common misconceptions**, drawn from adjacent values in the source
  itself — a neighbouring threshold, the other arm of a criterion. Never an obviously silly option, and
  never options of visibly different length, which give the answer away.
- Instant feedback, a **one-line explanation citing its page** on every option, and a score at the end.
- If the source does not contain enough decision-changing content to make three such questions,
  **build fewer, or none, and say so** — do not manufacture filler.

## 6. Technical constraints — hard limits

**Self-contained**
- One file. All CSS in one `<style>`, all JS in one `<script>`.
- **Zero network requests.** No CDN, no Google Fonts, no external images, no `fetch`, no `import`.
  The page must work with the phone in airplane mode.
- No React, Vue, Tailwind, jQuery, Chart.js or any other library. Plain HTML, CSS and JavaScript.
- Images only as inline SVG or `data:` URIs, and only if genuinely needed. Prefer SVG you draw yourself.
- **No `localStorage`, `sessionStorage`, `indexedDB` or cookies.** Some chat preview panes block them and
  the page will crash. Keep all state in JavaScript variables.
- Target under 250 KB total.

**Mobile**
- `<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">`
- Must lay out correctly at **360 px wide**. No horizontal scrolling anywhere, ever.
- Body text **≥ 16px** — smaller triggers zoom-on-focus in iOS Safari.
- Every tappable target **≥ 44 × 44 px**, with visible spacing between adjacent targets.
- **No hover-dependent behaviour.** Anything reachable by hover must also work on tap.
- Respect the notch: `padding: env(safe-area-inset-*)` on fixed elements.
- Tables wider than the screen go in a `overflow-x:auto` wrapper with a visible scroll hint.
- Support `prefers-color-scheme: dark` and `light`. Both must be legible.

**Accessibility — assume some readers are over sixty**
- Include **A− / A+ text size buttons** in the header that scale the whole page. Start at 17px.
- Contrast ratio ≥ 4.5:1 for body text in both colour schemes.
- Semantic HTML: `<header> <main> <section> <button> <details>`. Use `<button>`, never a clickable `<div>`.
- `aria-expanded` on every collapsible control; visible `:focus-visible` outline.
- Respect `prefers-reduced-motion`: no animation when it is set.

**Language**
- Write the page in the language(s) given in `SETTINGS: LANGUAGES`, regardless of the PDF's own language.
- For Korean, Japanese or Chinese, add `word-break: keep-all; overflow-wrap: break-word` to body text so
  lines do not break mid-word.
- Keep technical terms and drug names in their original form, with a translation on first use.

## 6a. Two languages — the language tab

When `SETTINGS: LANGUAGES` names two languages, the page must contain **both, in full**, with a tab in the
header that switches between them instantly. Not a link to a second page — one file, one tap.

**Use exactly this pattern.** It is the one that survives being written by a language model.

```html
<body class="lang-ko">        <!-- SETTINGS: DEFAULT decides ko or en here -->
```
```css
.lang-ko [data-l="en"]{display:none}
.lang-en [data-l="ko"]{display:none}
```
```html
<!-- inline -->
<h2><span data-l="ko">항생제 경과</span><span data-l="en">Antibiotic course</span></h2>
<!-- block -->
<div data-l="ko"><p>…</p><ul>…</ul></div>
<div data-l="en"><p>…</p><ul>…</ul></div>
```
```html
<div class="langtab" role="group" aria-label="language">
  <button type="button" data-set="ko" aria-pressed="true">한국어</button>
  <button type="button" data-set="en" aria-pressed="false">EN</button>
</div>
```
```js
document.querySelectorAll('.langtab button').forEach(function(b){
  b.onclick = function(){
    document.body.className = 'lang-' + b.dataset.set;
    document.documentElement.lang = b.dataset.set;
    document.querySelectorAll('.langtab button').forEach(function(o){
      o.setAttribute('aria-pressed', String(o === b));
    });
  };
});
```

Rules that go with it:

- **Both versions carry the same facts.** The second language is a translation of the content, not a
  shorter or livelier variant. Numbers, page references and source lines are identical on both sides.
- **Never nest** a `data-l` element inside another `data-l` element.
- **Everything switches** — headings, summaries, body, quiz questions, quiz answers, quiz explanations,
  button labels, checklist items, the footer, the `<title>`. A half-translated page is a bug.
- Proper nouns, drug names, gene names, abbreviations and the source file name stay as they are on both
  sides. Do not translate `HbA1c`, `MRSA`, `PTA`, `HELIOS`.
- The two tab buttons are ≥ 44 px tall, and the active one is visibly distinct — not colour alone; use
  weight or a filled background too.
- Anything JavaScript generates (quiz items, filter messages, counters, empty states) must also exist in
  both languages. Keep the strings in one object, e.g. `var T = {ko:{…}, en:{…}}`, and read the current
  language from `document.body.className`.
- Search filters only what is currently visible: match against the active language's text.

**Length warning.** Two languages roughly doubles the file. If you are at risk of running out of room,
do not silently drop the second language and do not shorten one side — instead cover fewer sections,
keep both languages complete for the sections you do cover, and say in your three lines above the code
block which sections you left out.

## 6b. Visual design — this is specified, not left to you

Do not invent a look. The values below are fixed. They were checked with a contrast calculator, not
by eye: every ink and accent below clears **WCAG 4.5:1** against both its page background and its card
background, in all three themes.

### Three themes, and the reader chooses

Ship all three in every page. Put the switcher in the header, beside `A−` / `A+`.

| Theme | For | Page | Card | Body ink |
|---|---|---|---|---|
| **Paper** | default in light | `#FBFAF7` | `#F4F1EA` | `#1A1D23` |
| **Night** | default in dark | `#14161A` | `#1D2027` | `#EDF0F5` |
| **High contrast** | older eyes, sunlight, printing | `#FFFFFF` | `#FFFFFF` | `#000000` |

On load, pick Paper or Night from `prefers-color-scheme`. A tap on the switcher overrides it for the
session. Because you may not use `localStorage` (§6), the choice does not survive a reload — that is
expected; do not try to work around it.

Paste this block as-is and write everything else against the variables:

```css
:root{
  --bg:#FBFAF7; --card:#F4F1EA; --ink:#1A1D23; --ink2:#55606E;
  --accent:#8A5D10; --ok:#0F6B4A; --warn:#A8143C; --line:#E3DFD4;
  --base:17px;
}
body.t-night{
  --bg:#14161A; --card:#1D2027; --ink:#EDF0F5; --ink2:#A2AAB8;
  --accent:#E8B44F; --ok:#4FD6A0; --warn:#FF7A70; --line:#2B303A;
}
body.t-hc{
  --bg:#FFFFFF; --card:#FFFFFF; --ink:#000000; --ink2:#2B2B2B;
  --accent:#6B3A00; --ok:#00513A; --warn:#8C0F2E; --line:#000000;
}
@media (prefers-color-scheme:dark){
  body:not(.t-paper):not(.t-hc){
    --bg:#14161A; --card:#1D2027; --ink:#EDF0F5; --ink2:#A2AAB8;
    --accent:#E8B44F; --ok:#4FD6A0; --warn:#FF7A70; --line:#2B303A;
  }
}
body.t-hc .card{border-width:2px}
```

### What each colour is allowed to do

- `--accent` — section rules, the active tab, links, the small label above a number. **One accent, used
  sparingly.** It is not a fourth status colour and never fills a large area.
- `--ok` and `--warn` — state only. **A status colour never appears without a word or an icon beside
  it.** On a light page a dark gold and a dark red are necessarily close in hue — they are legible as
  text but they are *not* reliably distinguishable at a glance, so the word carries the meaning and the
  colour only reinforces it. This also happens to be the right call for a reader over sixty.
- `--ink2` — source lines, captions, collapsed summaries. Never body text of a whole section.
- `--line` — hairlines and card borders only. Never text.

### Type and space

- One family: `-apple-system, BlinkMacSystemFont, "Apple SD Gothic Neo", "Noto Sans KR", system-ui, sans-serif`.
  **No web fonts, no serif, no display face.** Numbers use the same family.
- Scale from `--base` (17px): body `1em` · collapsed summary `.95em` · source line `.95em` ·
  section heading `1.1em/600` · page title `1.55em/700`.
- Two size floors, both hard, and **`em` compounds** — a `.9em` element inside a `.9em` parent is
  `.81em`, so measure the rendered pixels, not the declared value:
  - **Section body text, table cells, list items: ≥ 16px.** No exceptions. A verbatim value in a
    table is the most important text on the page and must never be the smallest.
  - **Supporting text — source lines, captions, chips, button labels: ≥ 14px.** Never below.
  - `A−` / `A+` scale everything, so both floors hold at the default size.
- Line height 1.65 for body, 1.25 for headings. Korean also needs `word-break:keep-all; overflow-wrap:break-word`.
- Spacing on a 4px grid. Card padding 14–16px, gap between cards 10px, gap between sections 22px.
- Radius 10px on cards, 12px on buttons. **One radius per element type** — do not mix.
- Borders are 1px `--line`. **No drop shadows.** No gradients anywhere.

### Key-number cards

- Label on top in `--ink2`, sentence case, no trailing colon.
- The figure below at **1.9em, weight 600, in `--ink`** — not in the accent. Copy the source's own
  formatting (`7.0%`, `<100 mg/dL`); never re-round, never add a unit the source did not use.
- Source page under it in `--ink2` at `.9em`.
- Cards are equal width in a wrapping grid, minimum 150px. Three to six of them; if there are only two
  worth showing, show two — do not pad the row with filler.
- Do **not** put a coloured background behind a number card. Card face is `--card`, border 1px `--line`.

### Banned outright

- Purple/blue gradients, glassmorphism, neon, shadows, emoji as section icons
- Coloured section headers, full-width coloured bands, coloured card faces
- Anything that moves on load; any animation when `prefers-reduced-motion` is set
- A second accent colour "for variety"

## 7. Anti-patterns — do not do these

- ✗ Loading anything from a URL
- ✗ Lorem ipsum, `TODO`, placeholder rows, or "example data" mixed in with real content
- ✗ A summary so compressed that the numbers are gone
- ✗ A wall of text with a single "expand all" — that is a PDF with extra steps
- ✗ Interactivity that does nothing (a search box over three items, a quiz with obvious answers)
- ✗ Font sizes below 16px for body text, or grey-on-grey
- ✗ Inventing a palette, a gradient, a shadow, or a second accent colour — §6b is fixed
- ✗ A one-line summary that names a topic instead of stating the conclusion
- ✗ A quiz nobody asked for
- ✗ Silently dropping content you found hard to parse
- ✗ A language tab where one side is thinner than the other, or where the quiz stays in one language
- ✗ Telling the user to copy your code into a text editor and rename it to `.html`. If you cannot
  produce a file, render it and point at the share button instead (§2)
- ✗ Apologising for not offering a download when your interface has a preview and a share link — that
  path is better, not worse

## 8. Self-check before you answer

Verify each of these. If any fails, fix it before replying — do not mention the checklist in your answer.

```
[ ] Delivered as a rendered document or a file where the interface allows it — code block only as a fallback
[ ] One complete document, <!DOCTYPE html> … </html>, not split in two
[ ] Zero external requests — search your own output for "http", "//cdn", "@import", "fetch("
[ ] No localStorage / sessionStorage / cookies
[ ] Every number in the page appears in the PDF, unchanged
[ ] Every section has a source page reference
[ ] No personal identifiers survived
[ ] Renders at 360px with no horizontal scroll
[ ] Body text ≥ 16px, tap targets ≥ 44px, A−/A+ present
[ ] All three themes present and switchable; the §6b variables used verbatim, no invented colours
[ ] No gradient, no shadow, no coloured card face, no emoji icons
[ ] Rendered pixel sizes checked, not declared em: body/table/list ≥16px, captions ≥14px
[ ] Every ok/warn colour is accompanied by a word or an icon — never colour alone
[ ] Number cards: figure in --ink at 1.9em, source page under it, none of them padding
[ ] At least two interactive components, each with something real to do
[ ] No quiz unless EXTRAS asked for one
[ ] Collapsed page is still readable — every one-line summary states a conclusion, not a topic
[ ] Anything unreadable in the PDF is declared, in the reply and in the page
[ ] If two languages: tab present, both sides complete, no data-l nested inside data-l,
    JS-generated strings translated, same numbers and page refs on both sides
```

## 9. `MODE: tool` — building a working instrument

In `brief` mode you produce a reading tool. In `tool` mode you find the parts of the source that can be
**operated** and turn them into something the reader drives.

Look for these, in this order of preference:

| What is in the source | What you build |
|---|---|
| Thresholds and cut-offs | A **classifier** — the reader enters values, the page states which band the source puts them in |
| Branching rules ("if X, then Y") | A **decision path** — answer a few questions, arrive at the applicable recommendation |
| Eligibility criteria | A **checklist that decides** — tick what applies, get the source's conclusion |
| An explicit formula | A **calculator** — with the formula and its units printed on screen |
| A large table | A **filterable table** — filter and sort, nothing computed |
| Staged or timed protocols | A **stepper** — one step at a time, with the source's timings |

### The rules that make this safe

1. **You implement, you do not infer.** Every threshold, branch and formula must be written in the source.
   If a branch is missing, the page says "출처에 없음 / not in the source" and stops there. Never complete
   a rule with your own knowledge, and never smooth over a gap to make the flow feel finished.
2. **Show the source text with every result.** A result is the verbatim sentence from the document plus
   its page reference — not your paraphrase of it. The reader must be able to check it without leaving
   the page.
3. **Verbatim stays in its original language.** Even when two languages are requested, quoted rules,
   recommendations and criteria are **not translated** — a translation is no longer verbatim. Translate the
   interface around them. If a translation of a quote genuinely helps, mark it clearly as unofficial and
   keep the original next to it.
4. **State, do not direct.** The page reports what the source says applies. It does not tell the reader
   what to do. Write "지침은 …라고 권고합니다 (p. N)", not "…하십시오".
5. **Carry the cautions.** If the source attaches conditions, exceptions, contraindications or an evidence
   grade to a rule, they travel with it. Never show a conclusion stripped of its qualifiers.
6. **Internal contradictions are surfaced, not resolved.** If two parts of the document disagree, show
   both with both page numbers and say they differ. Do not pick one.
7. **No dosing calculator** unless the source states the complete rule including limits, and the source's
   own warnings are displayed with the result.
8. **Same three themes, same variables (§6b).** A tool does not get its own look. The one addition is a
   result panel: face `--card`, a 4px left border in `--accent`, and — when the result is a state — a
   word such as 「정상 / 주의」 next to the `--ok` or `--warn` colour, never the colour alone.

### The banner — required, and always visible

Every `MODE: tool` page carries a warning that **cannot be dismissed and does not scroll away**. Build it
in two parts — a second sticky element under a sticky header gets hidden behind it on a phone, so do not
try that:

- **A one-line strip inside the sticky header itself**, in a caution colour. It is part of the header, so
  it is on screen at every scroll position. Keep it to one line: *"⚠ 불완전할 수 있습니다 — 판단 전 원문 확인 필수"*.
- **The full statement immediately below the header**, static, not sticky.

Repeat a short version next to every computed result.

> **이 도구는 원문을 옮긴 것이며 불완전할 수 있습니다. 판단 전에 반드시 원문을 확인하십시오.**
> This tool is a transcription of the source and may be incomplete. Check the original before acting on it.

Alongside it, state plainly: the source file name and edition, the date the page was generated, and — in
one line — what the tool does **not** cover. A reader must never be able to mistake it for the document.

If the source is clinical, legal or financial, add that the page is a reference aid and that the
responsibility for any decision stays with the reader.

---

# FOR THE PERSON — after you get the file

**If you only got a wall of code.** Some apps just print the source. Say the line for your app:

| Your app | Say this |
|---|---|
| **Claude** | *"Put this in an artifact."* / "이걸 아티팩트로 만들어줘." |
| **ChatGPT** | *"Open this in canvas."* / "이걸 캔버스로 열어줘." |
| **Gemini** | *"Make this a Canvas app and show me the preview."* / "이걸 Canvas 앱으로 만들어서 미리보기 보여줘." |
| **Anything else** | *"Save this as a downloadable .html file."* / "다운로드할 수 있는 .html 파일로 저장해줘." |

**Reading it right away.** Once it renders, the preview pane is usually enough on a phone — tap through
it there.

**Keeping it — and this differs by app.**

- **Gemini** — press **share**, open that link on your phone, then *add to home screen* for an icon.
  **Do not go looking for a download; Gemini does not have one.** You never need to save the code as a
  text file and rename it to `.html`. If you are doing that, you have taken the wrong path.
- **Claude / ChatGPT** — ask for *"a downloadable .html file"*, then:
  - **Android** — download it, open Chrome, `⋮ → Downloads`, tap the file.
  - **iPhone** — download it to Files, tap it to preview. To open it properly, long-press → Share → Safari.
- **Either way** — putting the file in Google Drive or Dropbox and opening the link on the phone also
  works, and is the easiest thing to send to someone else.

**Changing it.** Reply in the same chat with one sentence. Some that work well:

| Say this | You get |
|---|---|
| "Too long. Cut it to what a busy reader needs in 3 minutes." | A tighter version |
| "Add a self-check quiz, 5 questions." | A quiz |
| "The text is too small for me." | Larger base size |
| "Section 3 is wrong — the PDF says X." | A correction |
| "Make it work offline on a plane." | Verified zero-network |
| "Add a second PDF" + attach it | A merged page with `[A]`/`[B]` sources |
| "Add an English version with a language tab." | Both languages, one tap apart |

**If the reply gets cut off.** Say exactly: *"continue from where you stopped, no repetition"*.

**One caution.** The model can misread a PDF, especially scanned ones and tables. Spot-check the numbers
against the original before you rely on the page for anything that matters, and before you share it.

---

## Is this file safe to hand around?

**This file cannot execute.** Markdown is plain text — no macros, no scripts. Opening it is as safe as
opening a `.txt`. The extension carries no meaning; rename it to `.txt` if that travels better. An AI
reads either one identically.

**The real question is what a spec file instructs.** A prompt file from an unknown source could tell the
model to embed a tracking pixel, or to send the attached PDF's contents to some address. No antivirus
catches that, because nothing malicious is in the file — the instruction *is* the payload. The defence is
that a spec is a few pages of readable English: **read it before you paste it.** Note that this one
forbids every outbound connection, which is exactly what exfiltration would require.

**Give recipients a way to check the output.** Anyone can open the generated `.html` in a text editor and
search it:

- `http` — there should be **none**
- `localStorage`, `fetch` — there should be **none**

If those are absent, the page can only draw what is already inside it.

Two practical notes: many organisations strip `.html` email attachments, so share a link instead; and some
browsers warn on downloaded `.html` regardless of content, because the format *can* carry scripts. Neither
is a sign that anything is wrong.

---

*PocketBrief Spec v1.2 — free to copy, adapt and share.*

# PocketBrief LITE

Paste this, attach 1 PDF, send. Use this short version on small or free-tier models — the full spec
(`PocketBrief-Spec-v1.md`) asks for more than they reliably finish.

```
LANGUAGE: Korean          # the language of the finished page
AUDIENCE: general adult
```

---

**Task.** Read the attached PDF and build **one self-contained HTML page** that lets someone on a phone
understand it in a few minutes.

**How to deliver it.** I need something I can open on a phone, not source code to read. Give me the
finished page in the **best form your interface supports**, in this order:

1. A **rendered document** — if you can create an artifact, a canvas document, or a live preview, do that.
   This is the best outcome: it opens on a phone with no download.
2. A **downloadable `.html` file** — if you can write files, save it as `pocketbrief.html` and give me the link.
3. A **fenced code block** — only if you can do neither of the above.

If your interface has a canvas or preview but **no file download** — this is normal, Gemini Canvas
works this way — that is not a failure. Render the page there and tell me in one line to use the
**share button** and open the link on my phone. Never tell me to save your reply as a text file and
rename it to `.html`.

Whichever you choose, the page must be one complete document from `<!DOCTYPE html>` to `</html>`.
Say in one line which form you used. If you run out of room, stop mid-file — I will say "continue" and
you resume at the exact character you stopped at, with no repetition.

**Content.**
- Every fact comes from the PDF. Invent nothing.
- Copy numbers, units and dates exactly. Never round.
- Put the page number next to each section, like `p. 12`.
- If part of the PDF is unreadable, say so in the page instead of guessing.
- Remove any personal identifiers — names, ID numbers, dates of birth. Replace with `[name]`, `[ID]`.

**The page must have.**
1. A title, and the source file name.
2. Three to five **number cards** — a figure earns a card only if using the wrong value would change
   what someone does: a threshold, a target, a dose, a duration. Never a page count or a year.
   Two honest cards beat five padded ones.
3. Five to ten **collapsible sections**. Each shows a one-line summary while collapsed, so the page reads
   without tapping anything. **The summary states the conclusion, not the topic** — write
   "HbA1c target is under 6.5%", never "About HbA1c targets." First one open, rest closed.
   Start from the PDF's own headings. Drop acknowledgements, funding, author lists and references.
4. A **search box** that hides sections not matching what is typed, and opens the ones that match.
5. A **theme switcher** and `A−` / `A+` buttons, together in the header.

**No quiz** unless I explicitly asked for one.

**If the source is clinical** — a guideline, a protocol, a drug label — put one line at the top of
the page saying it is a reading aid transcribed from the source, that it may be wrong or incomplete,
and that the original must be checked before any decision. Write findings as "the guideline states…",
never as an instruction to the reader.

**Colours — use these exactly. Do not invent a palette.**

```css
:root{ --bg:#FBFAF7; --card:#F4F1EA; --ink:#1A1D23; --ink2:#55606E;
       --accent:#8A5D10; --ok:#0F6B4A; --warn:#A8143C; --line:#E3DFD4; --base:17px; }
body.t-night{ --bg:#14161A; --card:#1D2027; --ink:#EDF0F5; --ink2:#A2AAB8;
       --accent:#E8B44F; --ok:#4FD6A0; --warn:#FF7A70; --line:#2B303A; }
body.t-hc{ --bg:#FFFFFF; --card:#FFFFFF; --ink:#000000; --ink2:#2B2B2B;
       --accent:#6B3A00; --ok:#00513A; --warn:#8C0F2E; --line:#000000; }
```

Three themes, the reader switches between them; start from `prefers-color-scheme`.
System sans only, no web fonts. **No gradients, no shadows, no coloured card faces, no emoji icons,
no second accent colour.** Borders 1px `--line`, radius 10px. The number itself is `--ink` at 1.9em —
not the accent. `--ok` and `--warn` never appear without a word beside them.

**Technical — these are hard rules.**
- One file. CSS in one `<style>`, JS in one `<script>`.
- **No links to anything on the internet.** No CDN, no web fonts, no `fetch`. It must work in airplane mode.
- No React, Tailwind, jQuery or any library. Plain HTML, CSS, JavaScript.
- **No `localStorage` or cookies** — they are blocked in chat preview panes and will break the page.
- `<meta name="viewport" content="width=device-width, initial-scale=1">`
- Works at 360px wide with **no horizontal scrolling**.
- Body text at least 16px. Buttons at least 44px tall.
- Support dark mode with `@media (prefers-color-scheme: dark)`.
- For Korean, Japanese or Chinese text add `word-break: keep-all` so lines do not break mid-word.

**Before you answer, check:** delivered as a rendered document or a file if possible ·
no `http` anywhere in your output · no `localStorage` · every number matches the PDF ·
readable at 360px · dark mode legible.

---

### If you only got code

Some apps just print the source. Reply with the line for your app:

- **Claude** — "이걸 아티팩트로 만들어줘." / *"Put this in an artifact."*
- **ChatGPT** — "이걸 캔버스로 열어줘." / *"Open this in canvas."*
- **Gemini** — "이걸 Canvas 앱으로 만들어서 미리보기 보여줘." / *"Make this a Canvas app and show me the preview."*
- **Anything else** — "다운로드할 수 있는 .html 파일로 저장해줘."

**Gemini gives you no file download, and does not need to.** Once it renders in Canvas, press
**share**, open that link on your phone, and use *add to home screen* if you want an icon.
Saving the code as a text file and renaming it is never necessary.

**On the Gemini phone app, Canvas is inside the `+` menu (iPhone: "Add"), and you have to switch it
on before you send** — not after. Turn it on first, then paste this and attach the PDF. If it is not
in that menu at all, try switching the model from Pro to Flash, or use `gemini.google.com` in a
browser instead.

Build ONE self-contained HTML page from the attached PDF, readable on a phone in minutes.

Deliver it as a rendered artifact/canvas, or a downloadable .html file; a code block only as a last resort. If your canvas has no file download (Gemini Canvas), that is fine - render it and tell me to use the share button. Never tell me to rename a text file to .html.

CONTENT: only facts from the PDF. Invent nothing. Copy numbers exactly. Put "p.N" on each section. Say what you could not read. Remove personal identifiers. Write it in Korean.

PAGE: title + source filename; 3-5 number cards, only figures where the wrong value changes what someone does - threshold, target, dose, duration - never a page count or year; 5-10 collapsible sections, each showing a one-line summary while closed that states the conclusion, not the topic; first open; a search box; A-/A+ buttons. No quiz unless I ask. If the source is clinical, put one line at the top: this is a reading aid transcribed from the source, it may be wrong or incomplete, check the original before deciding. Write "the guideline states...", never an instruction.

COLOURS - use exactly these, invent nothing. bg #FBFAF7, card #F4F1EA, ink #1A1D23, muted #55606E, accent #8A5D10, ok #0F6B4A, warn #A8143C, line #E3DFD4, base 17px. Dark mode: bg #14161A, card #1D2027, ink #EDF0F5, muted #A2AAB8, accent #E8B44F, ok #4FD6A0, warn #FF7A70, line #2B303A. System sans only. No gradients, shadows, coloured card faces, emoji, or a second accent. Borders 1px, radius 10px. The number is ink at 1.9em, not accent. ok/warn always carry a word beside the colour.

TECHNICAL: one file, one <style>, one <script>. NO internet - no CDN, web fonts, images or fetch. No libraries. No localStorage. Viewport meta. Works at 360px with no horizontal scroll. Text >=16px, tap targets >=44px. Dark mode via prefers-color-scheme. Korean: word-break:keep-all.