PaperForge: a paper-reading skill that attacks the assumptions, not just the abstract

What PaperForge actually is, and what it is not

PaperForge is not a program. The repository has four top-level entries: README.md, SKILL_CHN.md, SKILL_EN.md and System_Prompt.txt. There is no package manifest, no source directory and no build step. What you get is a written procedure, in two languages, that you hand to a language model so that it reads a paper in a fixed order.

The problem it addresses is specific. Most paper summaries collapse into a restatement of the abstract plus the contribution list. That format hides the parts a researcher actually needs: why the authors went the way they did, which claim the whole result rests on, and what experiment would break it. PaperForge's twelve stages put those questions at the end, after the method has been explained, so the model has enough context to answer them.

The intended reader is someone who already uses an LLM as a reading assistant and wants a repeatable structure instead of ad hoc prompting. The README frames the whole thing as a workflow component, and it says PaperForge can serve as a starting point for your own paper-reading workflow rather than replacing it.

The twelve-stage reading flow and where it changes the analysis

The System_Prompt.txt file lays out the stages in order. Stages 1 and 2 establish the research question, why it matters, and why earlier work fell short. Stage 3 is the one the README singles out: reconstruct the author's likely thinking path using only background, failure modes, prior observations and related work that existed before the paper, explicitly not using the paper's own stated contribution as a premise. That constraint is the interesting design choice. It stops the model from writing a retrospective story in which the answer was always obvious.

Stage 4 asks for the intuition behind the method in concise form. Stage 5 requires a worked example covering input, processing and output as a pipeline, broken into points. Stage 6 asks for the mathematical derivation step by step, and the prompt tells the model to supply theory background if the reader's maths is weak, or to say so and skip when the paper has no derivation. Stage 7 formats the experimental validation as question, designed experiment, answer, deliberately without heavy data detail. Stage 8 collects takeaways.

The second half is the part that distinguishes PaperForge from a summary prompt. Stage 9 asks for the paper's most fragile assumption. Stage 10 asks what minimum reproduction could be done in one week. Stage 11 asks how you would design a counterexample if you disagreed. Stage 12 asks for a follow-up idea that is novel rather than incremental, derived from limitations and needs. The prompt also instructs the model to separate four kinds of information: what the paper explicitly claims, what related literature already concluded, what is a reasonable inference from evidence, and what remains uncertain guesswork. That separation is the most useful instruction in the file, because it is the one that most often gets ignored by default.

Installing PaperForge as a Claude or Codex Skill

There is nothing to compile. Option A in the README is to install SKILL_CHN.md or SKILL_EN.md as a Skill in the Claude or Codex Skill system. Once installed, you send a paper link or title in the conversation and the README states the agent triggers the full twelve-section analysis automatically. The repository does not document the Skill installation commands themselves, so follow the host system's own Skill installation procedure and treat the PaperForge markdown file as the payload.

Option B is the route the README's author says they prefer. Paste the contents of System_Prompt.txt into a Project's Custom Instructions, or directly into a chat. The README describes two variants: creating a Project so the prompt persists across conversations, or pasting it into a single chat and then supplying a PDF, link or title. The author notes that pasting directly into the chat seemed to produce higher-quality summaries in their own experience, and says they are not sure whether the difference comes from the position of the system prompt versus the user prompt. That is an anecdote, not a measurement.

A one-click copy block is included in the README. Its opening line is the task statement, and the first stage reads:

你的任务是：清晰、易懂、深入、详细的总结这篇论文（读取PDF、搜索arxiv等各种信息源获取论文）。

你的总结需要条理清晰的包含下面环节：
1. 论文提出并解决的研究问题是什么（适当搜索调研和补充背景）？为什么这个问题是重要的？解决这个问题能带来哪些价值？

The prompt is written in Chinese, so a reader working in English should use SKILL_EN.md or translate the System_Prompt.txt content before pasting it. After pasting, send a paper and expect a structured response that follows the twelve numbered stages rather than a free-form summary.

Option C and Option D: using PaperForge as a base rather than a finished tool

The README treats the repository as raw material in two further ways. Option C, labelled self-evolution, suggests asking an agent or model to review the repo against your existing prompt and merge the two: compare your prompt with PaperForge, keep the parts of your own workflow that suit you, and produce a combined version. The README points at four stages as the ones worth preserving in that merge: stage 3, reconstructing the author's thinking path; stage 9, the weakest assumption; stage 10, the minimum reproduction experiment; and stage 11, the strongest counterexample design.

Option D targets a different audience. The README states the current version focuses mainly on science and engineering papers that are experiment- and methodology-heavy, and offers a copy-paste instruction for adapting it to humanities and social science. That instruction asks a model with web search and reasoning enabled to research the differences between reading humanities or social science papers and reading science papers, then modify the skills in the repo while keeping the core elements: reverse-engineering the author's thinking, breaking down the argument structure, identifying key assumptions, and finding extendable questions. The README lists suggested directions to substitute in: history, sociology, political science, philosophy, anthropology, education, communication, economics, law and literary studies.

This is honest about scope. A prompt tuned for ablation studies and mathematical derivations does not transfer cleanly to a paper whose evidence is archival or ethnographic, and the README says as much instead of claiming universal coverage.

Where PaperForge is the wrong tool

The repository does not contain a PDF parser, a retrieval layer or any code. Everything depends on the host model's ability to read the paper you supply, either from an uploaded file or from sources it can search. If the model cannot access the paper, PaperForge has nothing to work with, and the twelve stages will be filled in from whatever the model already remembers, which is exactly the failure mode the four-way information separation in the prompt is meant to prevent.

Stage 6 is conditional by design. The prompt tells the model to add theoretical background when the paper has derivations, and to state that there are none and skip the stage otherwise. That means the output structure varies between papers, and a reader comparing two analyses should not expect the same section count.

The README also carries no licence file and no licence statement. For a text artifact that people are explicitly encouraged to copy, merge and adapt, that silence matters more than it would for a library with a package manifest, because the default position under most copyright regimes is that no permission has been granted. Anyone planning to redistribute a modified version should resolve that question before doing so rather than after.

Finally, the repository is a prompt collection with no test suite and no evaluation harness. The claim that pasting into the chat yields better summaries than using Custom Instructions is presented as the author's personal experience, and there is no way from the repository alone to check it.

How PaperForge differs from a plain summarisation prompt

The obvious alternative is the summary prompt most people already have: paste a paper, ask for the problem, method, results and limitations. That approach is shorter and works on any model without installation. The difference in approach is ordering and constraint. A generic prompt asks for limitations at the end of a summary, where the model tends to produce generic caveats such as small dataset or limited generalisation. PaperForge asks for the weakest assumption only after the method has been explained mechanistically through a worked pipeline example, and it asks for a specific counterexample design and a one-week reproduction experiment alongside it. Those three stages force a level of concreteness that a single limitations bullet does not.

The other alternative is a dedicated paper-reading product with its own PDF handling and annotation interface. Those tools own the ingestion problem, which PaperForge does not touch at all. The trade-off is the reverse of the usual one: PaperForge gives you a procedure you can read, edit and merge into your own workflow, and gives you nothing for getting the paper into the model in the first place.

A third path is simply writing your own prompt. The README anticipates this with Option C, and the four stages it flags as worth keeping are a reasonable shortlist for anyone building a personal version.

Maintenance, adaptation cost and the licence question

The last push to the repository was on 2026-08-03. There are no releases. The repository is not archived, but the maintenance model here is unusual: because the deliverable is a prompt, you do not need upstream changes to keep using it, and a stale prompt does not break the way a stale dependency does. What ages is the fit between the prompt and the model you run it on. Prompt behaviour shifts as models are updated, and the README's own uncertainty about system-prompt versus user-prompt placement is a reminder that the output is sensitive to how the text is delivered.

Upgrade cost is therefore manual. If you install SKILL_EN.md as a Skill, refreshing means replacing the file with the current version from the repository. If you pasted System_Prompt.txt into Custom Instructions, refreshing means editing that text by hand, and any local edits you made are lost unless you kept a copy. The README's Option C merge workflow implies you will be maintaining a fork of the prompt rather than tracking upstream, which is a reasonable choice given the size of the artifact.

The licence is not stated anywhere in the repository. The README encourages copying, pasting, merging and adapting, but encouragement in a README is not a licence grant. If you intend to publish a derived version, or use it inside an organisation with licence review, that is the first thing to settle.

Editorial conclusion

Adopt PaperForge if you already read papers inside ChatGPT, Claude or Codex and you want a fixed structure that forces you past summarisation into assumption testing and follow-up idea generation. Do not adopt it if you need a tool that parses a PDF on its own, or if you work mainly in humanities and social science, because the README says the current version targets experiment-heavy science and methodology papers. Before relying on it, open SKILL_EN.md and System_Prompt.txt and check which of the twelve stages survive in the version you paste, and confirm the licence, which the repository does not state.

Frequently asked questions

Official sources

1. FeijiangHan/PaperForge on GitHub
2. Issues
3. README