왜 세 가지인가요. 모델이 클수록 긴 지시를 잘 따릅니다.
전체는 유료 모델에서 가장 좋은 결과가 나오고, 짧은 버전은 무료·소형 모델용,
초미니는 QR에 들어갈 만큼 줄인 것입니다. 결과가 자꾸 끊기면 아래 등급으로 내리십시오.
안전하게 쓰시려면
환자 정보가 든 PDF는 넣지 마십시오. 지침·논문·강의자료처럼 공개된 문서에 쓰십시오.
이 글은 그냥 텍스트입니다. 실행되지 않고, 감염시킬 수 없습니다. 다만 지시문은 읽어보고 쓰십시오 —
출처를 모르는 지시문은 결과물에 원치 않는 코드를 넣게 시킬 수도 있습니다. 이 지시문은 정반대로,
외부 연결을 전부 금지합니다.
결과물 확인법. 만들어진 HTML을 텍스트 편집기로 열고 http, localStorage,
fetch 를 찾아보십시오. 하나도 없어야 정상입니다.
숫자는 대조하십시오. 모델이 PDF를 잘못 읽을 수 있습니다. 특히 스캔본과 표에서요.
# PocketBrief Spec v1.1
**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 one HTML file back. Open it on your phone.
Optionally edit the `SETTINGS` block below before sending. Everything else can stay as-is.
---
## 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.
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 that matters, 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.
## 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.
- **Self-check quiz** — 3 to 8 multiple-choice questions drawn strictly from the source. Instant feedback,
a one-line explanation per answer, and a score. Every explanation cites its page.
- **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.
## 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.
## 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
- ✗ 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
## 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
[ ] Dark and light both legible
[ ] At least two interactive components, each with something real to do
[ ] Collapsed page is still readable — every section shows its one-line summary
[ ] 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.
### 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 one of these — the first that
your app understands:
- **"이걸 다운로드할 수 있는 .html 파일로 저장해줘."** / *"Save this as a downloadable .html file."* ← works almost everywhere
- *"Put this in an artifact."* / "이걸 아티팩트로 만들어줘."
- *"Open this in canvas."* / "이걸 캔버스로 열어줘."
- *"Render it so I can see it."* / "렌더링해서 보여줘."
**Reading it right away.** Once it renders, the preview pane is usually enough on a phone — tap through
it there.
**Keeping it.** Ask: *"give me this as 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** — put it in Google Drive or Dropbox and open the link on the phone. It renders in the browser.
**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.0 — 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.
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** — the figures that matter.
3. Five to ten **collapsible sections**. Each shows a one-line summary while collapsed, so the page reads
without tapping anything. First one open, rest closed.
4. A **search box** that hides sections not matching what is typed, and opens the ones that match.
5. `A−` and `A+` buttons that change the text size of the whole page.
**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 one of these — the first one that your app understands:
- **"이걸 다운로드할 수 있는 .html 파일로 저장해줘."** ← works almost everywhere
- "이걸 아티팩트로 만들어줘." / "Put this in an artifact."
- "이걸 캔버스로 열어줘." / "Open this in canvas."
- "이 코드를 렌더링해서 보여줘."
You are given a PDF. Build ONE self-contained HTML page that lets someone read it 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.
CONTENT: Use only facts from the PDF. Invent nothing. Copy every number exactly. Put "p.N" on each section. Say what you could not read. Remove personal identifiers. Write the page in Korean.
PAGE: title + source filename; 3-5 number cards of the figures that matter; 5-10 collapsible sections, each showing a one-line summary while closed, first one open; a search box that hides non-matching sections; A- / A+ text-size buttons.
TECHNICAL: one file, CSS in one <style>, JS in one <script>. NO internet - no CDN, no web fonts, no images, no fetch. No libraries. No localStorage. Include viewport meta. Must work at 360px wide with no horizontal scrolling. Body text >=16px, tap targets >=44px. Dark mode via prefers-color-scheme. For Korean use word-break:keep-all.