# Two agent skills that split revising a paper from answering its reviewers > This suite separates pre-submission diagnosis from rebuttal work, and the rebuttal skill writes down triage practice that usually passes as tacit knowledge. The README's review-score chart arrives with no methodology, and the repository has no licence. **M1n-n9/paper-lifecycle** — Codex skill for full academic paper lifecycle analysis and revision - Repository: https://github.com/M1n-n9/paper-lifecycle - Stars: 693 · Forks: 38 - Language: Unknown - License: not declared - Published: 2026-09-18 · Updated: 2026-09-18 · Language: en - Canonical page: https://hysenlabs.com/projects/m1n-n9-paper-lifecycle ## Two jobs that only look like one This repository packages two agent skills for academic authors. One diagnoses a manuscript before it is submitted. The other handles what arrives after review. The README is direct that the root directory is documentation and nothing else. The installable pieces are two sibling directories, each with its own skill description, its own reference document and its own agent definition file. Splitting them is the decision that shapes everything here, and it is correct. Revising a draft and answering reviewers are different activities with different constraints. Revision is unbounded: any part of the paper can change, and the only limit is time. A rebuttal is bounded in almost every direction, by a word limit, by a deadline measured in days, by the experiments that can realistically be run in that window, and by the fact that the audience has already written down an opinion and attached a number to it. A single skill covering both would have to hedge constantly about which situation applies. Two skills let each one assume its own context, which is why the prompts for them read so differently. The audience is researchers submitting to competitive venues, and the README's framing assumes conference reviewing with an area chair rather than a journal editor. ## The chain that review-revision walks The first skill performs what the README calls reviewer-style diagnosis and revision planning, and it is aimed at an existing manuscript, a draft, a rejected paper, or an idea with a concrete direction. What it checks is listed as a sequence, and the sequence is the substance. Whether the problem is real. Whether the insight is defensible. Whether the novelty holds. Whether the method serves the mechanism. Whether the experiments support the claims. Whether the writing guides reviewers through the argument. Read that list again in order and it becomes a dependency chain rather than a checklist. Each item is only worth evaluating if the one before it survived. A method that serves no mechanism cannot be fixed by better experiments; novelty that does not hold cannot be rescued by better writing. Papers are frequently revised in the opposite direction, starting with the prose because that is the part an author can improve on a given afternoon. The phrase about the method serving the mechanism is the sharpest one. It distinguishes a technique that follows from why the problem occurs from a technique that merely performs well, and that distinction is behind a large share of reviews complaining that a paper is engineering rather than research. Stated applications cover manuscripts as PDF, LaTeX, Word or Markdown, submission checklists for top-tier venues, journals and workshops, section-level revision for the introduction, related work, method and experiments, and audits of theory, statistics, reproducibility, figures and tables. ## Triage, and the part nobody writes down The second skill is the more unusual of the two. The README states plainly that it does not merely polish replies, and then describes what it does instead: turn reviews into a decision-ready evidence package for the area chair. The listed capabilities are worth reading as a whole. Which concerns can change the decision. Which reviewers are persuadable. What evidence to add. How to write a summary addressed to the area chair. How to draft per-reviewer responses. How to correct factual misunderstandings without sounding hostile. The first two items are triage criteria, and they are the ones that get passed around as tacit knowledge rather than written down. A rebuttal that answers every point equally is a rebuttal that has not been prioritised, and a reviewer who has decided will not be moved by a fourth paragraph on the same objection. Time spent there is time taken from the reviewer who wrote a specific, addressable concern. The summary addressed to the area chair is the other piece of practice the README treats as a first-class artefact rather than an afterthought. In a conference process the area chair is often the reader who resolves disagreement between reviewers, and writing something specifically for that reader is a different task from replying to each review in turn. The tone list is refreshingly concrete: remove excessive apology, defensiveness, vague promises and hostile wording. Those four failure modes cover most rebuttals that damage their own case, and naming them is more useful than advising a professional tone. Outputs include a rebuttal checklist and a camera-ready promise list, the second of which quietly records what the authors committed to doing if accepted. ## Installing by link rather than by copy Installation for the skill loader the project targets is a clone into an ordinary directory, then a link for each skill into the loader's skills directory: ```bash git clone https://github.com/M1n-n9/paper-lifecycle.git ~/.codex/research-skills/paper-lifecycle ln -s ~/.codex/research-skills/paper-lifecycle/review-revision ~/.codex/skills/review-revision ln -s ~/.codex/research-skills/paper-lifecycle/rebuttal-response ~/.codex/skills/rebuttal-response ``` Windows users get the same arrangement through directory junctions, with the equivalent commands given in the README. Linking rather than copying is a small choice with a real consequence. The clone remains a working repository, so pulling updates refreshes both skills at once, and the two skills stay registered independently while sharing a single source. Copying would have left two divergent snapshots and no clean way to update either. For agents that do not use that loader, the README gives an escape hatch and names the exact files: a skill description and a reference document for each of the two skills. Recommended prompts are supplied, instructing the agent to read both files and then run the workflow. That path is worth noting because it tells you what this repository actually is. Neither skill has code. Each is a skill description plus a longer reference document, one described as a revision guide and the other as a rebuttal playbook. Someone who reads those four files has the method whether or not any loader is involved. ## A results chart with nothing attached to it The README opens with a full-width image whose filename describes it as a three-conference review score improvement chart. Nothing in the README explains it. There is no accompanying text, no description of which conferences, no account of how many papers, no statement of what was compared against what, and no method for attributing a score change to the use of these skills. The image is presented and the document moves on to the skill descriptions. That gap is worth naming, because a chart of review score improvements is the single strongest claim a tool like this could make, and it is the one claim that would need the most careful support. Review outcomes vary between venues, between review cycles and between reviewer assignments. A paper revised with help from anything at all is also a paper that has been revised, and separating those two is genuinely difficult. None of this means the underlying work is not real. It means a reader cannot evaluate it from what is published here, and should treat the chart as an illustration rather than as evidence when deciding whether to adopt the skills. The more defensible reason to use these is the content of the reference documents, which a prospective user can read in full before installing anything and judge directly. That is the assessment available, and for a written method it is the appropriate one. ## Persuasion, and where the skill points it A tool for writing rebuttals is a tool for persuading people who hold power over a decision, and it is fair to ask what it optimises. The answer here is better than it might have been, because of where the checks sit. The revision skill asks whether the problem is real and whether the experiments support the claims, which are questions about substance and can only be answered by changing the paper. The rebuttal skill's own advice includes removing vague promises, which is the standard way of deferring an objection rather than answering it, and its output includes a promise list that records commitments rather than letting them evaporate. Two items do sit closer to advocacy than to substance. Ranking reviewers by persuadability is a judgement about people rather than about the work, and correcting factual errors without sounding hostile is a question of presentation. Both are real parts of the process and are usually learned by watching a supervisor do it, which is exactly the kind of knowledge that stays with people who already have access to it. Written down, that knowledge reaches authors without a well-connected group behind them, which is the better argument for a repository like this than any score chart. The counterweight is that a persuasive rebuttal for a weak paper is a worse outcome for everyone, and the only defence against that sits in the other skill, which is why using the revision one first is more than a matter of sequence. ## What is missing before you adopt it The repository has no licence file. No permission to use, modify or redistribute the documents has been granted, which for a suite explicitly meant to be cloned and linked into a tool directory is the most significant omission here. Anyone planning to adapt these documents for a research group, a course or an internal template has nothing to rely on. This is not legal advice. The README is fully bilingual in Chinese and English, with matched sections and a language switcher, which is more care than most projects take. The skill descriptions and reference documents themselves are not shown in the README, so their language is something to check after cloning. The repository reports 674 stars and 39 forks with no open issues, and the last push was on 2026-06-16. There are no releases, so there is no version to pin. Three steps before adopting it. Read the two reference documents first, because they are short, they are the actual product, and they are readable without installing anything. Decide whether the conference-oriented framing, with its area chair and its rebuttal window, matches the venues you submit to, since journal review works differently. Then ask the author about licensing before building anything on top of these files, because at present the terms are simply absent. ## Conclusion This suite fits a researcher submitting to competitive conferences who wants a structured second opinion on a draft and, later, a way to sort reviews by what can actually change the decision. The rebuttal skill is the stronger half, because triage by decision impact and a summary written for the area chair are practices usually learned by watching someone senior do it rather than from anything published. Read the two reference documents before installing, since they are the actual product and require no loader, treat the review-score chart as an illustration because the README attaches no methodology to it, and settle licensing with the author before adapting these files for a group or a course, as no terms are stated. ## FAQ ### What are the two skills? Review Revision performs reviewer-style diagnosis and revision planning on a manuscript, draft, rejected paper or concrete idea. Rebuttal Response triages reviews and plans replies, building what the README calls a decision-ready evidence package for the area chair. ### How is it installed? Clone the repository into an ordinary directory, then link each of the two skill directories into the agent's skills directory, using symbolic links on macOS and Linux or directory junctions on Windows. Linking rather than copying means a single pull updates both skills. ### Can it be used without that specific agent? Yes. The README names the exact files for each skill, a skill description and a reference document, and supplies prompts instructing any agent to read both and then run the workflow. Neither skill contains code, so the documents are the whole product. ### What does the rebuttal skill actually produce? Triaged and ranked concerns, a summary addressed to the area chair, per-reviewer responses covering novelty, baselines, experimental setup, method motivation, scope and factual errors, a tone pass removing apology and defensiveness, plus a rebuttal checklist and a camera-ready promise list. ### What licence does it use? None is published. The repository contains no licence file, so no permission to use, modify or redistribute the documents has been granted, which matters for a suite intended to be cloned and adapted. This is not legal advice. ## Sources - [Issues](https://github.com/M1n-n9/paper-lifecycle/issues) - [M1n-n9/paper-lifecycle on GitHub](https://github.com/M1n-n9/paper-lifecycle) - [README](https://github.com/M1n-n9/paper-lifecycle/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/m1n-n9-paper-lifecycle