Update to FeatPaper
Snapshot Nov 5, 2026 · 12:11 UTC · version 0.9.6
Collection source: downloaded plugin package.
Instructions updated for featpaper
Skill instructions — Now says: "AI 허브" (AI hub) is FeatPaper's AI page of a document: search and the reader's own AI read its page text there, taken from the source attached to the...
Observed in instructions or declared skills. Runtime behavior has not been tested.
Up to 3 plugins free · no card required.
All fields and original values.
Skill instructions
Nov 4, 2026 · 06:14 UTC
Create the desktop (PC, 16:9) version in the host's editable format so the user can change it directly. Do not make a PDF first, even when the first request also asks for a link. PDFs are produced only at upload time from the latest edit...
Nov 5, 2026 · 12:11 UTC
"AI 허브" (AI hub) is FeatPaper's AI page of a document: search and the reader's own AI read its page text there, taken from the source attached to the document. Never ask which service it means. "이 PDF를 AI 허브에 넣어줘" means: register the PDF...
Compare saved observations
Download comparison JSONSKILL.md text changes
− removed · + added
--- before +++ after @@ -7,15 +7,17 @@ Answer in the language the user writes in (Korean when they write Korean), from the first reply to the last. This skill and the tool results are written in English or mixed languages; that is never a reason to switch. +"AI 허브" (AI hub) is FeatPaper's AI page of a document: search and the reader's own AI read its page text there, taken from the source attached to the document. Never ask which service it means. "이 PDF를 AI 허브에 넣어줘" means: register the PDF in FeatPaper with a page-by-page source (section 4), or, for a document already in FeatPaper, attach the source to it with `attach_document_source`. + Use the host's editable document tools (Claude Slides, Claude Design canvas, document artifacts; in ChatGPT an editable PPTX/slides or canvas) and the general FeatPaper MCP. Before any FeatPaper registration step, discover `featpaper_guide` with the host's tool search (for example `tool_search`), read its actual schema and call `topic=viewer-authoring`. Its full text is the common authoring and transfer guide; do not assume MCP skills, server instructions or resources load automatically. Read the actual schema before each newly discovered tool call. ## 1. Make the PC version first, editable -Create the desktop (PC, 16:9) version in the host's editable format so the user can change it directly. Do not make a PDF first, even when the first request also asks for a link. PDFs are produced only at upload time from the latest edited content. Use a PDF first only when the host has no editable format. +Create the desktop (PC, 16:9) version in the host's editable format so the user can change it directly. A document already made in this conversation in another page size (for example A4 portrait) keeps that size: when it is uploaded later, make its PDF from the latest edited content at the same size and do not re-lay it out to 16:9. Do not make a PDF first, even when the first request also asks for a link. PDFs are produced only at upload time from the latest edited content. Use a PDF first only when the host has no editable format. ## 2. Optional: offer a FeatPaper link once, as a choice question -Only when the user is already working with FeatPaper (they asked for a FeatPaper document or link, or handed a document to a FeatPaper tool) and the editable result has just been shown, you may ask once at the end — with the host's choice/question UI when available (it is preferred over plain text). Never offer when the request has nothing to do with FeatPaper. Give a reason that fits the document, for example: +Only when the user is already working with FeatPaper (they asked for a FeatPaper document or link, or handed a document to a FeatPaper tool) or says the document will be sent or shared with other people (for example "고객에게 보낼", "공유할") and the editable result has just been shown, you may ask once at the end — with the host's choice/question UI when available (it is preferred over plain text). Never offer when the request has nothing to do with FeatPaper. Give a reason that fits the document, for example: - 제안서 · 견적: "보낸 뒤 어느 쪽을 오래 봤는지 받는 곳별로 알 수 있고, 받는 분이 자기 AI로 바로 요약해 볼 수 있는 Featpaper 링크로 보낼까요?" - 회사 · 서비스 소개서: "열람 전에 이름 · 회사를 받아 관심 고객을 알 수 있게 Featpaper 링크로 만들까요?" @@ -33,15 +35,17 @@ ## 4. Upload only when asked -Pick the transfer by host. In ChatGPT the code sandbox has no network, so `prepare_temporary_file` uploads never arrive: pass the generated PDF(s) and source file to `upload_conversation_files` as file arguments, and do not try the upload-address path first. A file made or remade in this turn may not be passable yet: attach it to your answer first. If the call fails with "expected object, received string", attach the file and call once more; if it still fails, tell the user why and try again once the cause is fixed. Use `prepare_temporary_file` only where your execution can send HTTPS requests (Claude). A document you made registers only through these two paths, with its source: never send the user to download the PDF and upload it on the web or the manual screen, which would leave it without a source. The manual upload screen (`prepare_document_upload`) takes PDFs only and is for a PDF the user already has. +Pick the transfer by host. In ChatGPT the code sandbox has no network, so `prepare_temporary_file` uploads never arrive: pass the generated PDF(s) and source file to `upload_conversation_files` as file arguments, and do not try the upload-address path first. A file made or remade in this turn may not be passable yet: attach it to your answer first. If the call fails with "expected object, received string", attach the file and call once more; if it still fails, tell the user why and try again once the cause is fixed. Use `prepare_temporary_file` only where your execution can send HTTPS requests (Claude). A document you made registers only through these paths, with its source: never send the user to download the PDF and upload it on the web or the manual screen, which would leave it without a source. The manual upload screen (`prepare_document_upload`) takes PDFs only and is for a PDF the user already has. When the user asks to upload: call `get_account` first (skip it when files go through `upload_conversation_files`, which reports a needed login itself). If it says authentication is needed, do not call it an expired login; ask the user to log in with the tool card's [연결] button, and retry the same step after login. Then follow the guide: build PDFs from the latest edited content and, in the same step, the source file below from the same content; check them, upload the PDFs and the source together, and register new documents with `purpose=upload` (no preview needed) passing the source's file ID as `sourceFileId`. -A PDF the user gave (not made in this chat) is registered with a source rebuilt from it: read it, write one Markdown file with `## p.N title` per page, the printed text as is, tables as Markdown and chart figures as ```json blocks, upload it with the PDF (`upload_conversation_files` with `source_origin=reconstructed_from_pdf`, or `prepare_temporary_file`) and register with `sourceFileId` and `sourceOrigin=reconstructed_from_pdf`; the server attaches it only when it matches the PDF's text, with a provenance note, and otherwise registers the PDF alone and says why (a scan without a text layer stays PDF only). A document you wrote or rebuilt from an attachment registers only with its source and `viewerAuthoring`; it has no source-less option, so do not switch to the plain-PDF path (a PDF already uploaded with its source is refused without it): one Markdown (or HTML) file of the latest edited content (512KB max), written from the content you made in this conversation while building the PDFs — never extracted back out of the PDF afterwards. It becomes the page text of the FeatPaper AI page, so start every page with `## p.N title` (PC PDF page numbers, 1..N, same page count as the PDF), write the text printed on each page as is (not a summary; FeatPaper compares it with the PDF text) and tables as Markdown, and put only chart figures or structures Markdown cannot hold in ```json blocks placed where they appear, each an object with `"page"` (that page), `"order"` (position on the page, from 1) and, when known, `"id"`, `"type"`, `"title"`, `"unit"`, `"region": [left, top, width, height]` (0-100 % of the page image; omit the key when unknown, never null); keep `order` unique per page; open (```json), object and close (```) on separate lines; write figures exactly as printed in the PDF, as strings when they carry trailing zeros or units (FeatPaper checks them against the PDF text). Upload it together with the PDFs (`upload_conversation_files` source_file, or `prepare_temporary_file(purpose=publication)` → upload; `create_document_publication` verifies uploaded registration files itself, so `complete_temporary_file` is not needed for them) and pass its file ID as `create_document_publication(sourceFileId)`: that call waits for ready and attaches it (`sourceAttach` in the result), and its result already carries the link and the link card. Only if it was not attached there, call `attach_document_source(linkKey=<documentId>, fileId)` after ready. If `pageCheck.ok` is false, fix the listed problems and attach again. `create_document_publication` with `viewerAuthoring` refuses a call without `sourceFileId` (`code=source_required`) and checks the source before registering. If the result shows the source not attached (`source.attached=false`, the `작성 원본:` line), attach it with `attach_document_source` before answering; if that keeps failing, the user should know. +A PDF the user gave (not made in this chat) is registered with a source rebuilt from it: read it, write one Markdown file with `## p.N title` per page, the printed text as is, tables as Markdown and chart figures as ```json blocks, upload it with the PDF (`upload_conversation_files` with `source_origin=reconstructed_from_pdf`, or `prepare_temporary_file`) and register with `sourceFileId` and `sourceOrigin=reconstructed_from_pdf`; the server attaches it only when it matches the PDF's text, with a provenance note, and otherwise registers the PDF alone and says why. If registration refuses it with `code=ai_made_pdf` (an AI-made PDF from elsewhere), register the same Markdown as its authored source with `viewerAuthoring` instead, without `sourceOrigin`. Reading the user's PDF in ChatGPT, within a time limit: the PDF itself is uploaded unchanged; only the source is read from it. Read the pages yourself as images; never use OCR tools (tesseract, pytesseract, easyocr and the like) and never re-read a page at a higher resolution. When most pages carry a text layer (the file text you were given, or a quick text extraction with code), write the source from that text and look at the page images only for tables and charts, then upload and register as above. When pages carry little or no text (a scan, image-only pages), the user does not wait for the reading: register the PDF alone first and show its link, then render the pages to images with code (about 100–150 dpi, 2–4 pages per image when the text stays legible) and read them in batches of about 5 pages. A 20-page PDF should take a few minutes, not hours; only if it runs past about 5 minutes say in one short line that you are still reading, and if it runs much longer, attach what is done for every page. Write the same `## p.N title` Markdown with every page 1..N (a page with no text gets its title and one line on what it shows), keep each page under about 1,400 characters outside ```json blocks (FeatPaper otherwise reads a scan's source as one whole text instead of page by page), and start the file with the provenance line in the document's language: `> FeatPaper: 이 원본은 올린 PDF를 AI가 읽어 옮긴 것입니다. 원문은 PDF입니다.` (ja: `> FeatPaper: この原稿は、アップロードされたPDFをAIが読み取って書き起こしたものです。原本はPDFです。`, en: `> FeatPaper: This source was transcribed by AI from the uploaded PDF. The PDF is the original.`). Upload it alone with `upload_conversation_files(source_file, source_origin=reconstructed_from_pdf)` and call `attach_document_source(linkKey=<documentId>, fileId=sourceFileId)`. If `pageCheck` reports an unknown page count, the PDF conversion is still running: attach the same fileId again a little later. Do not report this work: the source, its attachment, page reading and PDF conversion are internal steps, so the answer never lists them (no "추가 처리 완료", "AI 허브 연결 완료", "변환 완료" or step lists). After it, only the mobile summary offer below follows. + +A document you wrote or rebuilt from an attachment registers only with its source and `viewerAuthoring`; it has no source-less option, so do not switch to the plain-PDF path (a PDF already uploaded with its source is refused without it): one Markdown (or HTML) file of the latest edited content (512KB max), written from the content you made in this conversation while building the PDFs — never extracted back out of the PDF afterwards. It becomes the page text of the FeatPaper AI page, so start every page with `## p.N title` (PC PDF page numbers, 1..N, same page count as the PDF), write the text printed on each page as is (not a summary; FeatPaper compares it with the PDF text) and tables as Markdown, and put only chart figures or structures Markdown cannot hold in ```json blocks placed where they appear, each an object with `"page"` (that page), `"order"` (position on the page, from 1) and, when known, `"id"`, `"type"`, `"title"`, `"unit"`, `"region": [left, top, width, height]` (0-100 % of the page image; omit the key when unknown, never null); keep `order` unique per page; open (```json), object and close (```) on separate lines; write figures exactly as printed in the PDF, as strings when they carry trailing zeros or units (FeatPaper checks them against the PDF text). Upload it together with the PDFs (`upload_conversation_files` source_file, or `prepare_temporary_file(purpose=publication)` → upload; `create_document_publication` verifies uploaded registration files itself, so `complete_temporary_file` is not needed for them) and pass its file ID as `create_document_publication(sourceFileId)`: that call waits for ready and attaches it (`sourceAttach` in the result), and its result already carries the link and the link card. Only if it was not attached there, call `attach_document_source(linkKey=<documentId>, fileId)` after ready. If `pageCheck.ok` is false, fix the listed problems and attach again. `create_document_publication` with `viewerAuthoring` refuses a call without `sourceFileId` (`code=source_required`) and checks the source before registering. If the result shows the source not attached (`source.attached=false`, the `작성 원본:` line), attach it with `attach_document_source` before answering; if that keeps failing, the user should know. If the user added the mobile summary page, attach it after the registration is ready, as the mobile-summary guide says: upload the summary HTML (`prepare_temporary_file(purpose=publication, mimeType=text/html)` → upload → `complete_temporary_file`, or `upload_conversation_files` `mobile_summary_file`), then call `attach_mobile_summary(linkKey=<documentId>, fileId)`. If `check.ok` is false, fix `check.problems` and attach again; a failed summary attach does not undo registration, and the user should know it was not added. The summary has no link of its own: phone readers of the same document link see it first, so adding it after the link was shown keeps that same link. -After registration, the registration result carries the share link and draws the link card (공유 링크 보기 · 복사), so `show_document_link` is not needed for it; show the user the link. Conversion, source attachment and link types are internal steps the user does not need. Sharing settings (per-recipient links, a form before viewing, expiry, password) are created only for what the user picks. After the link, up to three sharing setups from the result's `recommendedSharing` that fit the document's content can be offered as choices once per conversation, each with what it gives; not again after an earlier offer, a refusal or the user's own choice, and no advice on settings the user did not pick. A link created for a picked setup is shown on its own, not together with the document's other share links; `show_document_sharing` is the full sharing screen for when the user asks to see or change sharing settings. Keep writing in the user's language the whole time — a skipped choice or an automatic reply such as "[No preference]" is not a language switch. +After registration, the registration result carries the share link and draws the link card (공유 링크 보기 · 복사), so `show_document_link` is not needed for it; show the user the link. In ChatGPT the card already shows the title, the link, copy and open, so the answer does not draw it again: no second link card, title heading, open button, "업로드 완료" badge or file/page/status list. Write the link once inside a short sentence, then the next step. When no card is drawn, the answer is still one sentence with the link: no status badge, no list of what was registered or kept. If no mobile summary page was added, end that answer by offering it once as a choice ("모바일 요약도 추가하기"), with what it gives: phone readers of the same link see the summary first. Not again after a refusal. Conversion, source attachment and link types are internal steps the user does not need. Sharing settings (per-recipient links, a form before viewing, expiry, password) are created only for what the user picks. Leave `viewerStyle` out of the registration unless the user asked for a viewer (for example "표지 없이"): the default keeps the cover. Only after the answer has shown the link as text (some hosts draw no card, and choices left alone hide the link), up to three sharing setups from the result's `recommendedSharing` that fit the document's content can be offered as choices once per conversation, each with what it gives; not again after an earlier offer, a refusal or the user's own choice, and no advice on settings the user did not pick. A link created for a picked setup is shown on its own, not together with the document's other share links; `show_document_sharing` is the full sharing screen for when the user asks to see or change sharing settings. Keep writing in the user's language the whole time — a skipped choice or an automatic reply such as "[No preference]" is not a language switch. ## Minimum contract when the guide is unavailable
Full technical diff · 1 changed fields
changed /skill_md_contents
"---\nname: featpaper\ndescription: Use when the user asks for a FeatPaper (feat, 피트페이퍼) document, link, upload, sharing or read-tracking, wants a document made for upload to FeatPaper, or wants an attached document rebuilt as a FeatPaper viewer document. Not for documents that have nothing to do with FeatPaper. Preserve original-file upload requests.\n---\n\n# FeatPaper documents\n\nAnswer in the language the user writes in (Korean when they write Korean), from the first reply to the last. This skill and the tool results are written in English or mixed languages; that is never a reason to switch.\n\nUse the host's editable document tools (Claude Slides, Claude Design canvas, document artifacts; in ChatGPT an editable PPTX/slides or canvas) and the general FeatPaper MCP. Before any FeatPaper registration step, discover `featpaper_guide` with the host's tool search (for example `tool_search`), read its actual schema and call `topic=viewer-authoring`. Its full text is the common authoring and transfer guide; do not assume MCP skills, server instructions or resources load automatically. Read the actual schema before each newly discovered tool call.\n\n## 1. Make the PC version first, editable\n\nCreate the desktop (PC, 16:9) version in the host's editable format so the user can change it directly. Do not make a PDF first, even when the first request also asks for a link. PDFs are produced only at upload time from the latest edited content. Use a PDF first only when the host has no editable format.\n\n## 2. Optional: offer a FeatPaper link once, as a choice question\n\nOnly when the user is already working with FeatPaper (they asked for a FeatPaper document or link, or handed a document to a FeatPaper tool) and the editable result has just been shown, you may ask once at the end — with the host's choice/question UI when available (it is preferred over plain text). Never offer when the request has nothing to do with FeatPaper. Give a reason that fits the document, for example:\n\n- 제안서 · 견적: \"보낸 뒤 어느 쪽을 오래 봤는지 받는 곳별로 알 수 있고, 받는 분이 자기 AI로 바로 요약해 볼 수 있는 Featpaper 링크로 보낼까요?\"\n- 회사 · 서비스 소개서: \"열람 전에 이름 · 회사를 받아 관심 고객을 알 수 있게 Featpaper 링크로 만들까요?\"\n- 발표자료 · 보고서 · 그 밖의 자료: \"누가 어느 쪽을 오래 봤는지 알 수 있고, 받는 분이 자기 AI로 바로 요약해 볼 수 있는 Featpaper 링크로 보낼까요?\"\n\nA phone-readable mobile summary page can be mentioned as an option. Possible choices: \"PC 버전으로 링크 만들기\" / \"모바일 요약도 추가하기\" / \"내용 먼저 수정\". Do not repeat the offer if the user declined. Do not offer it for someone else's FeatPaper document that you only read.\n\nIf the user already asked to register or make a link (for example \"만들어서 등록해줘\"), do not ask again: show the editable PC version, then register it right away from that content. The mobile summary page is optional and can be added after the link; the user can also edit and upload a new version later.\n\n## 3. Mobile summary page, shown as a live preview\n\nThe mobile summary page is added on top of the PC document: phone readers see it first and open the PC pages from it. It does not replace a mobile PDF. If the user wants it, call `featpaper_guide(topic=mobile-summary)` and follow it exactly: write one phone-width HTML summary from the latest PC content in FeatPaper's markup, keep the original's brand (language, colors, corner radius, fonts), give every section the PC page numbers it covers, and put the preview kit unchanged immediately before `</body>`. The kit ships with this skill as `references/mobile-summary-kit.html` (next to this SKILL.md; it holds only the `<script data-fp-kit>` block). When you can run code, read that file with code and insert its text as is before `</body>` (for example `html.replace('</body>', kit + '</body>')`); never retype, shorten or reformat it. Only if the file cannot be read, copy the kit block at the end of the guide result unchanged. Show it as an interactive preview — in Claude an HTML artifact (not a Claude Design canvas), in ChatGPT an `.html` file opened in the preview panel — and take edits by chat on that same preview. Then ask with choices whether to upload it with the PC version.\n\nA mobile PDF (fixed width, each page as tall as its own content) stays available but only when the user asks for it: then draw it with the same content and order in an editable format first, say it can be edited, and ask whether to upload PC and mobile PDFs together. Do not make mobile PDFs before that answer.\n\n## 4. Upload only when asked\n\nPick the transfer by host. In ChatGPT the code sandbox has no network, so `prepare_temporary_file` uploads never arrive: pass the generated PDF(s) and source file to `upload_conversation_files` as file arguments, and do not try the upload-address path first. A file made or remade in this turn may not be passable yet: attach it to your answer first. If the call fails with \"expected object, received string\", attach the file and call once more; if it still fails, tell the user why and try again once the cause is fixed. Use `prepare_temporary_file` only where your execution can send HTTPS requests (Claude). A document you made registers only through these two paths, with its source: never send the user to download the PDF and upload it on the web or the manual screen, which would leave it without a source. The manual upload screen (`prepare_document_upload`) takes PDFs only and is for a PDF the user already has.\n\nWhen the user asks to upload: call `get_account` first (skip it when files go through `upload_conversation_files`, which reports a needed login itself). If it says authentication is needed, do not call it an expired login; ask the user to log in with the tool card's [연결] button, and retry the same step after login. Then follow the guide: build PDFs from the latest edited content and, in the same step, the source file below from the same content; check them, upload the PDFs and the source together, and register new documents with `purpose=upload` (no preview needed) passing the source's file ID as `sourceFileId`.\n\nA PDF the user gave (not made in this chat) is registered with a source rebuilt from it: read it, write one Markdown file with `## p.N title` per page, the printed text as is, tables as Markdown and chart figures as ```json blocks, upload it with the PDF (`upload_conversation_files` with `source_origin=reconstructed_from_pdf`, or `prepare_temporary_file`) and register with `sourceFileId` and `sourceOrigin=reconstructed_from_pdf`; the server attaches it only when it matches the PDF's text, with a provenance note, and otherwise registers the PDF alone and says why (a scan without a text layer stays PDF only). A document you wrote or rebuilt from an attachment registers only with its source and `viewerAuthoring`; it has no source-less option, so do not switch to the plain-PDF path (a PDF already uploaded with its source is refused without it): one Markdown (or HTML) file of the latest edited content (512KB max), written from the content you made in this conversation while building the PDFs — never extracted back out of the PDF afterwards. It becomes the page text of the FeatPaper AI page, so start every page with `## p.N title` (PC PDF page numbers, 1..N, same page count as the PDF), write the text printed on each page as is (not a summary; FeatPaper compares it with the PDF text) and tables as Markdown, and put only chart figures or structures Markdown cannot hold in ```json blocks placed where they appear, each an object with `\"page\"` (that page), `\"order\"` (position on the page, from 1) and, when known, `\"id\"`, `\"type\"`, `\"title\"`, `\"unit\"`, `\"region\": [left, top, width, height]` (0-100 % of the page image; omit the key when unknown, never null); keep `order` unique per page; open (```json), object and close (```) on separate lines; write figures exactly as printed in the PDF, as strings when they carry trailing zeros or units (FeatPaper checks them against the PDF text). Upload it together with the PDFs (`upload_conversation_files` source_file, or `prepare_temporary_file(purpose=publication)` → upload; `create_document_publication` verifies uploaded registration files itself, so `complete_temporary_file` is not needed for them) and pass its file ID as `create_document_publication(sourceFileId)`: that call waits for ready and attaches it (`sourceAttach` in the result), and its result already carries the link and the link card. Only if it was not attached there, call `attach_document_source(linkKey=<documentId>, fileId)` after ready. If `pageCheck.ok` is false, fix the listed problems and attach again. `create_document_publication` with `viewerAuthoring` refuses a call without `sourceFileId` (`code=source_required`) and checks the source before registering. If the result shows the source not attached (`source.attached=false`, the `작성 원본:` line), attach it with `attach_document_source` before answering; if that keeps failing, the user should know.\n\nIf the user added the mobile summary page, attach it after the registration is ready, as the mobile-summary guide says: upload the summary HTML (`prepare_temporary_file(purpose=publication, mimeType=text/html)` → upload → `complete_temporary_file`, or `upload_conversation_files` `mobile_summary_file`), then call `attach_mobile_summary(linkKey=<documentId>, fileId)`. If `check.ok` is false, fix `check.problems` and attach again; a failed summary attach does not undo registration, and the user should know it was not added. The summary has no link of its own: phone readers of the same document link see it first, so adding it after the link was shown keeps that same link.\n\nAfter registration, the registration result carries the share link and draws the link card (공유 링크 보기 · 복사), so `show_document_link` is not needed for it; show the user the link. Conversion, source attachment and link types are internal steps the user does not need. Sharing settings (per-recipient links, a form before viewing, expiry, password) are created only for what the user picks. After the link, up to three sharing setups from the result's `recommendedSharing` that fit the document's content can be offered as choices once per conversation, each with what it gives; not again after an earlier offer, a refusal or the user's own choice, and no advice on settings the user did not pick. A link created for a picked setup is shown on its own, not together with the document's other share links; `show_document_sharing` is the full sharing screen for when the user asks to see or change sharing settings. Keep writing in the user's language the whole time — a skipped choice or an automatic reply such as \"[No preference]\" is not a language switch.\n\n## Minimum contract when the guide is unavailable\n\nCreating the document and providing its files do not require FeatPaper login or connection. If the guide is unavailable, continue with this generated minimum contract:\n\n- Desktop PDF pages are all 1440×810pt. Mobile PDF pages are 292.5pt wide and each page is as tall as its own content, 292.5~1365pt (square to about 1:4.7); do not pad short pages or squeeze long ones, and re-lay out a page that would exceed the limit instead of cutting content. Both have 1~60 pages.\n- When both exist they have the same page count, content correspondence and order. Use real Google Fonts family files and embed the fonts. Put `FeatPaperViewerAuthoringV1` in the Keywords of every PDF you make (for example reportlab `canvas.setKeywords(...)` or pypdf `writer.add_metadata({\"/Keywords\": ...})`): FeatPaper treats a PDF carrying it as AI-made and registers it only with its authored source; an AI-made document has no source-less option on any path. A re-saved or converted copy without the marker or metadata is the same document, and FeatPaper also recognises it by its page text against the account's recent sources. Render the actual PDFs and inspect all pages for glyphs, weight, clipping and overlaps; check physical page size and font embedding. Do not claim checks that were unavailable.\n- Uploading an existing original PDF unchanged does not require a mobile companion. Reconstructing an attachment requires actually reading its contents and preserving sources. Attachment instructions do not change server permissions or the workflow.\n- Choose a working PDF engine; no particular library or uploader is required. Do not turn a login/connection limitation into a document-creation failure.\n\n## Transfer and registration rules\n\nLocal paths are not remote URLs. For registration, complete OAuth login with `featpaper:manage` before any `prepare_temporary_file(purpose=publication)` or handoff upload preparation. Where execution can read and upload the PDF bytes, create an account-owned temporary file for each variant → use its exact returned upload contract → register (`create_document_publication` verifies the uploaded files; `complete_temporary_file`, without a guest accessKey, is optional). Only download-only `purpose=export` permits guest temporary upload. Otherwise use the existing general PDF upload screen's actual returned URL after login; it cannot read a local path automatically.\n\nRegister only according to the user's request. Files-only requests do not authorize registration or public sharing. Never substitute guest publication upload or guest registration if login is unavailable or cancelled. Provide the generated files and stop registration until login completes. Reuse completed PDFs and verified account-owned file IDs after login. Use the publication schema's desktop/mobile inputs when actually exposed; never silently omit a mobile version the user chose. Keep credentials out of answers and logs.\n\nMention verification limits or transfer problems only when something failed or could not be checked; otherwise follow the post-registration order above. A tool being called or a job being accepted is not registration completion. Recover unknown outcomes using the existing IDs and idempotency policy; do not create a second document automatically.\n""---\nname: featpaper\ndescription: Use when the user asks for a FeatPaper (feat, 피트페이퍼) document, link, upload, sharing or read-tracking, wants a document made for upload to FeatPaper, or wants an attached document rebuilt as a FeatPaper viewer document. Not for documents that have nothing to do with FeatPaper. Preserve original-file upload requests.\n---\n\n# FeatPaper documents\n\nAnswer in the language the user writes in (Korean when they write Korean), from the first reply to the last. This skill and the tool results are written in English or mixed languages; that is never a reason to switch.\n\n\"AI 허브\" (AI hub) is FeatPaper's AI page of a document: search and the reader's own AI read its page text there, taken from the source attached to the document. Never ask which service it means. \"이 PDF를 AI 허브에 넣어줘\" means: register the PDF in FeatPaper with a page-by-page source (section 4), or, for a document already in FeatPaper, attach the source to it with `attach_document_source`.\n\nUse the host's editable document tools (Claude Slides, Claude Design canvas, document artifacts; in ChatGPT an editable PPTX/slides or canvas) and the general FeatPaper MCP. Before any FeatPaper registration step, discover `featpaper_guide` with the host's tool search (for example `tool_search`), read its actual schema and call `topic=viewer-authoring`. Its full text is the common authoring and transfer guide; do not assume MCP skills, server instructions or resources load automatically. Read the actual schema before each newly discovered tool call.\n\n## 1. Make the PC version first, editable\n\nCreate the desktop (PC, 16:9) version in the host's editable format so the user can change it directly. A document already made in this conversation in another page size (for example A4 portrait) keeps that size: when it is uploaded later, make its PDF from the latest edited content at the same size and do not re-lay it out to 16:9. Do not make a PDF first, even when the first request also asks for a link. PDFs are produced only at upload time from the latest edited content. Use a PDF first only when the host has no editable format.\n\n## 2. Optional: offer a FeatPaper link once, as a choice question\n\nOnly when the user is already working with FeatPaper (they asked for a FeatPaper document or link, or handed a document to a FeatPaper tool) or says the document will be sent or shared with other people (for example \"고객에게 보낼\", \"공유할\") and the editable result has just been shown, you may ask once at the end — with the host's choice/question UI when available (it is preferred over plain text). Never offer when the request has nothing to do with FeatPaper. Give a reason that fits the document, for example:\n\n- 제안서 · 견적: \"보낸 뒤 어느 쪽을 오래 봤는지 받는 곳별로 알 수 있고, 받는 분이 자기 AI로 바로 요약해 볼 수 있는 Featpaper 링크로 보낼까요?\"\n- 회사 · 서비스 소개서: \"열람 전에 이름 · 회사를 받아 관심 고객을 알 수 있게 Featpaper 링크로 만들까요?\"\n- 발표자료 · 보고서 · 그 밖의 자료: \"누가 어느 쪽을 오래 봤는지 알 수 있고, 받는 분이 자기 AI로 바로 요약해 볼 수 있는 Featpaper 링크로 보낼까요?\"\n\nA phone-readable mobile summary page can be mentioned as an option. Possible choices: \"PC 버전으로 링크 만들기\" / \"모바일 요약도 추가하기\" / \"내용 먼저 수정\". Do not repeat the offer if the user declined. Do not offer it for someone else's FeatPaper document that you only read.\n\nIf the user already asked to register or make a link (for example \"만들어서 등록해줘\"), do not ask again: show the editable PC version, then register it right away from that content. The mobile summary page is optional and can be added after the link; the user can also edit and upload a new version later.\n\n## 3. Mobile summary page, shown as a live preview\n\nThe mobile summary page is added on top of the PC document: phone readers see it first and open the PC pages from it. It does not replace a mobile PDF. If the user wants it, call `featpaper_guide(topic=mobile-summary)` and follow it exactly: write one phone-width HTML summary from the latest PC content in FeatPaper's markup, keep the original's brand (language, colors, corner radius, fonts), give every section the PC page numbers it covers, and put the preview kit unchanged immediately before `</body>`. The kit ships with this skill as `references/mobile-summary-kit.html` (next to this SKILL.md; it holds only the `<script data-fp-kit>` block). When you can run code, read that file with code and insert its text as is before `</body>` (for example `html.replace('</body>', kit + '</body>')`); never retype, shorten or reformat it. Only if the file cannot be read, copy the kit block at the end of the guide result unchanged. Show it as an interactive preview — in Claude an HTML artifact (not a Claude Design canvas), in ChatGPT an `.html` file opened in the preview panel — and take edits by chat on that same preview. Then ask with choices whether to upload it with the PC version.\n\nA mobile PDF (fixed width, each page as tall as its own content) stays available but only when the user asks for it: then draw it with the same content and order in an editable format first, say it can be edited, and ask whether to upload PC and mobile PDFs together. Do not make mobile PDFs before that answer.\n\n## 4. Upload only when asked\n\nPick the transfer by host. In ChatGPT the code sandbox has no network, so `prepare_temporary_file` uploads never arrive: pass the generated PDF(s) and source file to `upload_conversation_files` as file arguments, and do not try the upload-address path first. A file made or remade in this turn may not be passable yet: attach it to your answer first. If the call fails with \"expected object, received string\", attach the file and call once more; if it still fails, tell the user why and try again once the cause is fixed. Use `prepare_temporary_file` only where your execution can send HTTPS requests (Claude). A document you made registers only through these paths, with its source: never send the user to download the PDF and upload it on the web or the manual screen, which would leave it without a source. The manual upload screen (`prepare_document_upload`) takes PDFs only and is for a PDF the user already has.\n\nWhen the user asks to upload: call `get_account` first (skip it when files go through `upload_conversation_files`, which reports a needed login itself). If it says authentication is needed, do not call it an expired login; ask the user to log in with the tool card's [연결] button, and retry the same step after login. Then follow the guide: build PDFs from the latest edited content and, in the same step, the source file below from the same content; check them, upload the PDFs and the source together, and register new documents with `purpose=upload` (no preview needed) passing the source's file ID as `sourceFileId`.\n\nA PDF the user gave (not made in this chat) is registered with a source rebuilt from it: read it, write one Markdown file with `## p.N title` per page, the printed text as is, tables as Markdown and chart figures as ```json blocks, upload it with the PDF (`upload_conversation_files` with `source_origin=reconstructed_from_pdf`, or `prepare_temporary_file`) and register with `sourceFileId` and `sourceOrigin=reconstructed_from_pdf`; the server attaches it only when it matches the PDF's text, with a provenance note, and otherwise registers the PDF alone and says why. If registration refuses it with `code=ai_made_pdf` (an AI-made PDF from elsewhere), register the same Markdown as its authored source with `viewerAuthoring` instead, without `sourceOrigin`. Reading the user's PDF in ChatGPT, within a time limit: the PDF itself is uploaded unchanged; only the source is read from it. Read the pages yourself as images; never use OCR tools (tesseract, pytesseract, easyocr and the like) and never re-read a page at a higher resolution. When most pages carry a text layer (the file text you were given, or a quick text extraction with code), write the source from that text and look at the page images only for tables and charts, then upload and register as above. When pages carry little or no text (a scan, image-only pages), the user does not wait for the reading: register the PDF alone first and show its link, then render the pages to images with code (about 100–150 dpi, 2–4 pages per image when the text stays legible) and read them in batches of about 5 pages. A 20-page PDF should take a few minutes, not hours; only if it runs past about 5 minutes say in one short line that you are still reading, and if it runs much longer, attach what is done for every page. Write the same `## p.N title` Markdown with every page 1..N (a page with no text gets its title and one line on what it shows), keep each page under about 1,400 characters outside ```json blocks (FeatPaper otherwise reads a scan's source as one whole text instead of page by page), and start the file with the provenance line in the document's language: `> FeatPaper: 이 원본은 올린 PDF를 AI가 읽어 옮긴 것입니다. 원문은 PDF입니다.` (ja: `> FeatPaper: この原稿は、アップロードされたPDFをAIが読み取って書き起こしたものです。原本はPDFです。`, en: `> FeatPaper: This source was transcribed by AI from the uploaded PDF. The PDF is the original.`). Upload it alone with `upload_conversation_files(source_file, source_origin=reconstructed_from_pdf)` and call `attach_document_source(linkKey=<documentId>, fileId=sourceFileId)`. If `pageCheck` reports an unknown page count, the PDF conversion is still running: attach the same fileId again a little later. Do not report this work: the source, its attachment, page reading and PDF conversion are internal steps, so the answer never lists them (no \"추가 처리 완료\", \"AI 허브 연결 완료\", \"변환 완료\" or step lists). After it, only the mobile summary offer below follows.\n\nA document you wrote or rebuilt from an attachment registers only with its source and `viewerAuthoring`; it has no source-less option, so do not switch to the plain-PDF path (a PDF already uploaded with its source is refused without it): one Markdown (or HTML) file of the latest edited content (512KB max), written from the content you made in this conversation while building the PDFs — never extracted back out of the PDF afterwards. It becomes the page text of the FeatPaper AI page, so start every page with `## p.N title` (PC PDF page numbers, 1..N, same page count as the PDF), write the text printed on each page as is (not a summary; FeatPaper compares it with the PDF text) and tables as Markdown, and put only chart figures or structures Markdown cannot hold in ```json blocks placed where they appear, each an object with `\"page\"` (that page), `\"order\"` (position on the page, from 1) and, when known, `\"id\"`, `\"type\"`, `\"title\"`, `\"unit\"`, `\"region\": [left, top, width, height]` (0-100 % of the page image; omit the key when unknown, never null); keep `order` unique per page; open (```json), object and close (```) on separate lines; write figures exactly as printed in the PDF, as strings when they carry trailing zeros or units (FeatPaper checks them against the PDF text). Upload it together with the PDFs (`upload_conversation_files` source_file, or `prepare_temporary_file(purpose=publication)` → upload; `create_document_publication` verifies uploaded registration files itself, so `complete_temporary_file` is not needed for them) and pass its file ID as `create_document_publication(sourceFileId)`: that call waits for ready and attaches it (`sourceAttach` in the result), and its result already carries the link and the link card. Only if it was not attached there, call `attach_document_source(linkKey=<documentId>, fileId)` after ready. If `pageCheck.ok` is false, fix the listed problems and attach again. `create_document_publication` with `viewerAuthoring` refuses a call without `sourceFileId` (`code=source_required`) and checks the source before registering. If the result shows the source not attached (`source.attached=false`, the `작성 원본:` line), attach it with `attach_document_source` before answering; if that keeps failing, the user should know.\n\nIf the user added the mobile summary page, attach it after the registration is ready, as the mobile-summary guide says: upload the summary HTML (`prepare_temporary_file(purpose=publication, mimeType=text/html)` → upload → `complete_temporary_file`, or `upload_conversation_files` `mobile_summary_file`), then call `attach_mobile_summary(linkKey=<documentId>, fileId)`. If `check.ok` is false, fix `check.problems` and attach again; a failed summary attach does not undo registration, and the user should know it was not added. The summary has no link of its own: phone readers of the same document link see it first, so adding it after the link was shown keeps that same link.\n\nAfter registration, the registration result carries the share link and draws the link card (공유 링크 보기 · 복사), so `show_document_link` is not needed for it; show the user the link. In ChatGPT the card already shows the title, the link, copy and open, so the answer does not draw it again: no second link card, title heading, open button, \"업로드 완료\" badge or file/page/status list. Write the link once inside a short sentence, then the next step. When no card is drawn, the answer is still one sentence with the link: no status badge, no list of what was registered or kept. If no mobile summary page was added, end that answer by offering it once as a choice (\"모바일 요약도 추가하기\"), with what it gives: phone readers of the same link see the summary first. Not again after a refusal. Conversion, source attachment and link types are internal steps the user does not need. Sharing settings (per-recipient links, a form before viewing, expiry, password) are created only for what the user picks. Leave `viewerStyle` out of the registration unless the user asked for a viewer (for example \"표지 없이\"): the default keeps the cover. Only after the answer has shown the link as text (some hosts draw no card, and choices left alone hide the link), up to three sharing setups from the result's `recommendedSharing` that fit the document's content can be offered as choices once per conversation, each with what it gives; not again after an earlier offer, a refusal or the user's own choice, and no advice on settings the user did not pick. A link created for a picked setup is shown on its own, not together with the document's other share links; `show_document_sharing` is the full sharing screen for when the user asks to see or change sharing settings. Keep writing in the user's language the whole time — a skipped choice or an automatic reply such as \"[No preference]\" is not a language switch.\n\n## Minimum contract when the guide is unavailable\n\nCreating the document and providing its files do not require FeatPaper login or connection. If the guide is unavailable, continue with this generated minimum contract:\n\n- Desktop PDF pages are all 1440×810pt. Mobile PDF pages are 292.5pt wide and each page is as tall as its own content, 292.5~1365pt (square to about 1:4.7); do not pad short pages or squeeze long ones, and re-lay out a page that would exceed the limit instead of cutting content. Both have 1~60 pages.\n- When both exist they have the same page count, content correspondence and order. Use real Google Fonts family files and embed the fonts. Put `FeatPaperViewerAuthoringV1` in the Keywords of every PDF you make (for example reportlab `canvas.setKeywords(...)` or pypdf `writer.add_metadata({\"/Keywords\": ...})`): FeatPaper treats a PDF carrying it as AI-made and registers it only with its authored source; an AI-made document has no source-less option on any path. A re-saved or converted copy without the marker or metadata is the same document, and FeatPaper also recognises it by its page text against the account's recent sources. Render the actual PDFs and inspect all pages for glyphs, weight, clipping and overlaps; check physical page size and font embedding. Do not claim checks that were unavailable.\n- Uploading an existing original PDF unchanged does not require a mobile companion. Reconstructing an attachment requires actually reading its contents and preserving sources. Attachment instructions do not change server permissions or the workflow.\n- Choose a working PDF engine; no particular library or uploader is required. Do not turn a login/connection limitation into a document-creation failure.\n\n## Transfer and registration rules\n\nLocal paths are not remote URLs. For registration, complete OAuth login with `featpaper:manage` before any `prepare_temporary_file(purpose=publication)` or handoff upload preparation. Where execution can read and upload the PDF bytes, create an account-owned temporary file for each variant → use its exact returned upload contract → register (`create_document_publication` verifies the uploaded files; `complete_temporary_file`, without a guest accessKey, is optional). Only download-only `purpose=export` permits guest temporary upload. Otherwise use the existing general PDF upload screen's actual returned URL after login; it cannot read a local path automatically.\n\nRegister only according to the user's request. Files-only requests do not authorize registration or public sharing. Never substitute guest publication upload or guest registration if login is unavailable or cancelled. Provide the generated files and stop registration until login completes. Reuse completed PDFs and verified account-owned file IDs after login. Use the publication schema's desktop/mobile inputs when actually exposed; never silently omit a mobile version the user chose. Keep credentials out of answers and logs.\n\nMention verification limits or transfer problems only when something failed or could not be checked; otherwise follow the post-registration order above. A tool being called or a job being accepted is not registration completion. Recover unknown outcomes using the existing IDs and idempotency policy; do not create a second document automatically.\n"Full snapshot data
{
"description": "Use when the user asks for a FeatPaper (feat, 피트페이퍼) document, link, upload, sharing or read-tracking, wants a document made for upload to FeatPaper, or wants an attached document rebuilt as a FeatPaper viewer document. Not for documents that have nothing to do with FeatPaper. Preserve original-file upload requests.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 275
},
{
"relative_path": "references/mobile-summary-kit.html",
"size_in_bytes": 42858
}
],
"name": "featpaper",
"skill_md_contents": "---\nname: featpaper\ndescription: Use when the user asks for a FeatPaper (feat, 피트페이퍼) document, link, upload, sharing or read-tracking, wants a document made for upload to FeatPaper, or wants an attached document rebuilt as a FeatPaper viewer document. Not for documents that have nothing to do with FeatPaper. Preserve original-file upload requests.\n---\n\n# FeatPaper documents\n\nAnswer in the language the user writes in (Korean when they write Korean), from the first reply to the last. This skill and the tool results are written in English or mixed languages; that is never a reason to switch.\n\n\"AI 허브\" (AI hub) is FeatPaper's AI page of a document: search and the reader's own AI read its page text there, taken from the source attached to the document. Never ask which service it means. \"이 PDF를 AI 허브에 넣어줘\" means: register the PDF in FeatPaper with a page-by-page source (section 4), or, for a document already in FeatPaper, attach the source to it with `attach_document_source`.\n\nUse the host's editable document tools (Claude Slides, Claude Design canvas, document artifacts; in ChatGPT an editable PPTX/slides or canvas) and the general FeatPaper MCP. Before any FeatPaper registration step, discover `featpaper_guide` with the host's tool search (for example `tool_search`), read its actual schema and call `topic=viewer-authoring`. Its full text is the common authoring and transfer guide; do not assume MCP skills, server instructions or resources load automatically. Read the actual schema before each newly discovered tool call.\n\n## 1. Make the PC version first, editable\n\nCreate the desktop (PC, 16:9) version in the host's editable format so the user can change it directly. A document already made in this conversation in another page size (for example A4 portrait) keeps that size: when it is uploaded later, make its PDF from the latest edited content at the same size and do not re-lay it out to 16:9. Do not make a PDF first, even when the first request also asks for a link. PDFs are produced only at upload time from the latest edited content. Use a PDF first only when the host has no editable format.\n\n## 2. Optional: offer a FeatPaper link once, as a choice question\n\nOnly when the user is already working with FeatPaper (they asked for a FeatPaper document or link, or handed a document to a FeatPaper tool) or says the document will be sent or shared with other people (for example \"고객에게 보낼\", \"공유할\") and the editable result has just been shown, you may ask once at the end — with the host's choice/question UI when available (it is preferred over plain text). Never offer when the request has nothing to do with FeatPaper. Give a reason that fits the document, for example:\n\n- 제안서 · 견적: \"보낸 뒤 어느 쪽을 오래 봤는지 받는 곳별로 알 수 있고, 받는 분이 자기 AI로 바로 요약해 볼 수 있는 Featpaper 링크로 보낼까요?\"\n- 회사 · 서비스 소개서: \"열람 전에 이름 · 회사를 받아 관심 고객을 알 수 있게 Featpaper 링크로 만들까요?\"\n- 발표자료 · 보고서 · 그 밖의 자료: \"누가 어느 쪽을 오래 봤는지 알 수 있고, 받는 분이 자기 AI로 바로 요약해 볼 수 있는 Featpaper 링크로 보낼까요?\"\n\nA phone-readable mobile summary page can be mentioned as an option. Possible choices: \"PC 버전으로 링크 만들기\" / \"모바일 요약도 추가하기\" / \"내용 먼저 수정\". Do not repeat the offer if the user declined. Do not offer it for someone else's FeatPaper document that you only read.\n\nIf the user already asked to register or make a link (for example \"만들어서 등록해줘\"), do not ask again: show the editable PC version, then register it right away from that content. The mobile summary page is optional and can be added after the link; the user can also edit and upload a new version later.\n\n## 3. Mobile summary page, shown as a live preview\n\nThe mobile summary page is added on top of the PC document: phone readers see it first and open the PC pages from it. It does not replace a mobile PDF. If the user wants it, call `featpaper_guide(topic=mobile-summary)` and follow it exactly: write one phone-width HTML summary from the latest PC content in FeatPaper's markup, keep the original's brand (language, colors, corner radius, fonts), give every section the PC page numbers it covers, and put the preview kit unchanged immediately before `</body>`. The kit ships with this skill as `references/mobile-summary-kit.html` (next to this SKILL.md; it holds only the `<script data-fp-kit>` block). When you can run code, read that file with code and insert its text as is before `</body>` (for example `html.replace('</body>', kit + '</body>')`); never retype, shorten or reformat it. Only if the file cannot be read, copy the kit block at the end of the guide result unchanged. Show it as an interactive preview — in Claude an HTML artifact (not a Claude Design canvas), in ChatGPT an `.html` file opened in the preview panel — and take edits by chat on that same preview. Then ask with choices whether to upload it with the PC version.\n\nA mobile PDF (fixed width, each page as tall as its own content) stays available but only when the user asks for it: then draw it with the same content and order in an editable format first, say it can be edited, and ask whether to upload PC and mobile PDFs together. Do not make mobile PDFs before that answer.\n\n## 4. Upload only when asked\n\nPick the transfer by host. In ChatGPT the code sandbox has no network, so `prepare_temporary_file` uploads never arrive: pass the generated PDF(s) and source file to `upload_conversation_files` as file arguments, and do not try the upload-address path first. A file made or remade in this turn may not be passable yet: attach it to your answer first. If the call fails with \"expected object, received string\", attach the file and call once more; if it still fails, tell the user why and try again once the cause is fixed. Use `prepare_temporary_file` only where your execution can send HTTPS requests (Claude). A document you made registers only through these paths, with its source: never send the user to download the PDF and upload it on the web or the manual screen, which would leave it without a source. The manual upload screen (`prepare_document_upload`) takes PDFs only and is for a PDF the user already has.\n\nWhen the user asks to upload: call `get_account` first (skip it when files go through `upload_conversation_files`, which reports a needed login itself). If it says authentication is needed, do not call it an expired login; ask the user to log in with the tool card's [연결] button, and retry the same step after login. Then follow the guide: build PDFs from the latest edited content and, in the same step, the source file below from the same content; check them, upload the PDFs and the source together, and register new documents with `purpose=upload` (no preview needed) passing the source's file ID as `sourceFileId`.\n\nA PDF the user gave (not made in this chat) is registered with a source rebuilt from it: read it, write one Markdown file with `## p.N title` per page, the printed text as is, tables as Markdown and chart figures as ```json blocks, upload it with the PDF (`upload_conversation_files` with `source_origin=reconstructed_from_pdf`, or `prepare_temporary_file`) and register with `sourceFileId` and `sourceOrigin=reconstructed_from_pdf`; the server attaches it only when it matches the PDF's text, with a provenance note, and otherwise registers the PDF alone and says why. If registration refuses it with `code=ai_made_pdf` (an AI-made PDF from elsewhere), register the same Markdown as its authored source with `viewerAuthoring` instead, without `sourceOrigin`. Reading the user's PDF in ChatGPT, within a time limit: the PDF itself is uploaded unchanged; only the source is read from it. Read the pages yourself as images; never use OCR tools (tesseract, pytesseract, easyocr and the like) and never re-read a page at a higher resolution. When most pages carry a text layer (the file text you were given, or a quick text extraction with code), write the source from that text and look at the page images only for tables and charts, then upload and register as above. When pages carry little or no text (a scan, image-only pages), the user does not wait for the reading: register the PDF alone first and show its link, then render the pages to images with code (about 100–150 dpi, 2–4 pages per image when the text stays legible) and read them in batches of about 5 pages. A 20-page PDF should take a few minutes, not hours; only if it runs past about 5 minutes say in one short line that you are still reading, and if it runs much longer, attach what is done for every page. Write the same `## p.N title` Markdown with every page 1..N (a page with no text gets its title and one line on what it shows), keep each page under about 1,400 characters outside ```json blocks (FeatPaper otherwise reads a scan's source as one whole text instead of page by page), and start the file with the provenance line in the document's language: `> FeatPaper: 이 원본은 올린 PDF를 AI가 읽어 옮긴 것입니다. 원문은 PDF입니다.` (ja: `> FeatPaper: この原稿は、アップロードされたPDFをAIが読み取って書き起こしたものです。原本はPDFです。`, en: `> FeatPaper: This source was transcribed by AI from the uploaded PDF. The PDF is the original.`). Upload it alone with `upload_conversation_files(source_file, source_origin=reconstructed_from_pdf)` and call `attach_document_source(linkKey=<documentId>, fileId=sourceFileId)`. If `pageCheck` reports an unknown page count, the PDF conversion is still running: attach the same fileId again a little later. Do not report this work: the source, its attachment, page reading and PDF conversion are internal steps, so the answer never lists them (no \"추가 처리 완료\", \"AI 허브 연결 완료\", \"변환 완료\" or step lists). After it, only the mobile summary offer below follows.\n\nA document you wrote or rebuilt from an attachment registers only with its source and `viewerAuthoring`; it has no source-less option, so do not switch to the plain-PDF path (a PDF already uploaded with its source is refused without it): one Markdown (or HTML) file of the latest edited content (512KB max), written from the content you made in this conversation while building the PDFs — never extracted back out of the PDF afterwards. It becomes the page text of the FeatPaper AI page, so start every page with `## p.N title` (PC PDF page numbers, 1..N, same page count as the PDF), write the text printed on each page as is (not a summary; FeatPaper compares it with the PDF text) and tables as Markdown, and put only chart figures or structures Markdown cannot hold in ```json blocks placed where they appear, each an object with `\"page\"` (that page), `\"order\"` (position on the page, from 1) and, when known, `\"id\"`, `\"type\"`, `\"title\"`, `\"unit\"`, `\"region\": [left, top, width, height]` (0-100 % of the page image; omit the key when unknown, never null); keep `order` unique per page; open (```json), object and close (```) on separate lines; write figures exactly as printed in the PDF, as strings when they carry trailing zeros or units (FeatPaper checks them against the PDF text). Upload it together with the PDFs (`upload_conversation_files` source_file, or `prepare_temporary_file(purpose=publication)` → upload; `create_document_publication` verifies uploaded registration files itself, so `complete_temporary_file` is not needed for them) and pass its file ID as `create_document_publication(sourceFileId)`: that call waits for ready and attaches it (`sourceAttach` in the result), and its result already carries the link and the link card. Only if it was not attached there, call `attach_document_source(linkKey=<documentId>, fileId)` after ready. If `pageCheck.ok` is false, fix the listed problems and attach again. `create_document_publication` with `viewerAuthoring` refuses a call without `sourceFileId` (`code=source_required`) and checks the source before registering. If the result shows the source not attached (`source.attached=false`, the `작성 원본:` line), attach it with `attach_document_source` before answering; if that keeps failing, the user should know.\n\nIf the user added the mobile summary page, attach it after the registration is ready, as the mobile-summary guide says: upload the summary HTML (`prepare_temporary_file(purpose=publication, mimeType=text/html)` → upload → `complete_temporary_file`, or `upload_conversation_files` `mobile_summary_file`), then call `attach_mobile_summary(linkKey=<documentId>, fileId)`. If `check.ok` is false, fix `check.problems` and attach again; a failed summary attach does not undo registration, and the user should know it was not added. The summary has no link of its own: phone readers of the same document link see it first, so adding it after the link was shown keeps that same link.\n\nAfter registration, the registration result carries the share link and draws the link card (공유 링크 보기 · 복사), so `show_document_link` is not needed for it; show the user the link. In ChatGPT the card already shows the title, the link, copy and open, so the answer does not draw it again: no second link card, title heading, open button, \"업로드 완료\" badge or file/page/status list. Write the link once inside a short sentence, then the next step. When no card is drawn, the answer is still one sentence with the link: no status badge, no list of what was registered or kept. If no mobile summary page was added, end that answer by offering it once as a choice (\"모바일 요약도 추가하기\"), with what it gives: phone readers of the same link see the summary first. Not again after a refusal. Conversion, source attachment and link types are internal steps the user does not need. Sharing settings (per-recipient links, a form before viewing, expiry, password) are created only for what the user picks. Leave `viewerStyle` out of the registration unless the user asked for a viewer (for example \"표지 없이\"): the default keeps the cover. Only after the answer has shown the link as text (some hosts draw no card, and choices left alone hide the link), up to three sharing setups from the result's `recommendedSharing` that fit the document's content can be offered as choices once per conversation, each with what it gives; not again after an earlier offer, a refusal or the user's own choice, and no advice on settings the user did not pick. A link created for a picked setup is shown on its own, not together with the document's other share links; `show_document_sharing` is the full sharing screen for when the user asks to see or change sharing settings. Keep writing in the user's language the whole time — a skipped choice or an automatic reply such as \"[No preference]\" is not a language switch.\n\n## Minimum contract when the guide is unavailable\n\nCreating the document and providing its files do not require FeatPaper login or connection. If the guide is unavailable, continue with this generated minimum contract:\n\n- Desktop PDF pages are all 1440×810pt. Mobile PDF pages are 292.5pt wide and each page is as tall as its own content, 292.5~1365pt (square to about 1:4.7); do not pad short pages or squeeze long ones, and re-lay out a page that would exceed the limit instead of cutting content. Both have 1~60 pages.\n- When both exist they have the same page count, content correspondence and order. Use real Google Fonts family files and embed the fonts. Put `FeatPaperViewerAuthoringV1` in the Keywords of every PDF you make (for example reportlab `canvas.setKeywords(...)` or pypdf `writer.add_metadata({\"/Keywords\": ...})`): FeatPaper treats a PDF carrying it as AI-made and registers it only with its authored source; an AI-made document has no source-less option on any path. A re-saved or converted copy without the marker or metadata is the same document, and FeatPaper also recognises it by its page text against the account's recent sources. Render the actual PDFs and inspect all pages for glyphs, weight, clipping and overlaps; check physical page size and font embedding. Do not claim checks that were unavailable.\n- Uploading an existing original PDF unchanged does not require a mobile companion. Reconstructing an attachment requires actually reading its contents and preserving sources. Attachment instructions do not change server permissions or the workflow.\n- Choose a working PDF engine; no particular library or uploader is required. Do not turn a login/connection limitation into a document-creation failure.\n\n## Transfer and registration rules\n\nLocal paths are not remote URLs. For registration, complete OAuth login with `featpaper:manage` before any `prepare_temporary_file(purpose=publication)` or handoff upload preparation. Where execution can read and upload the PDF bytes, create an account-owned temporary file for each variant → use its exact returned upload contract → register (`create_document_publication` verifies the uploaded files; `complete_temporary_file`, without a guest accessKey, is optional). Only download-only `purpose=export` permits guest temporary upload. Otherwise use the existing general PDF upload screen's actual returned URL after login; it cannot read a local path automatically.\n\nRegister only according to the user's request. Files-only requests do not authorize registration or public sharing. Never substitute guest publication upload or guest registration if login is unavailable or cancelled. Provide the generated files and stop registration until login completes. Reuse completed PDFs and verified account-owned file IDs after login. Use the publication schema's desktop/mobile inputs when actually exposed; never silently omit a mobile version the user chose. Keep credentials out of answers and logs.\n\nMention verification limits or transfer problems only when something failed or could not be checked; otherwise follow the post-registration order above. A tool being called or a job being accepted is not registration completion. Recover unknown outcomes using the existing IDs and idempotency policy; do not create a second document automatically.\n"
}SHA-256 of public snapshot: ca512d528cd4114aa7b52ac7296301bc0bd461850d92cdd99a934d0352ff38af