journal-adapt produces an editable rules file, and its priority table only partly orders itself
Learn any journal's writing conventions from its published papers, then revise your manuscript to match — section by section.
At a glance
- What is it?
- A static plus dynamic academic writing skill that reads a journal's own published papers and writes a reviewable revision framework for one manuscript. The corpus tiers are well specified; the priority ordering above them is not.
- Who is it for?
- This is a sensible division of labour for anyone revising a manuscript against a specific journal's house style, and the honest part is the scope it claims. It does not write the paper.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 143 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on October 5, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The output is one editable Markdown file, and the project says it is not a paper
The stated deliverable is a visible, editable `dynamic_writing_skill.md`. That single choice carries most of the design. The project is explicit that the skill does not auto-write a paper, and what it produces instead is an auditable revision framework for section-by-step academic rewriting, which is then handed to a human, then to section revision, then to a revision log.
The flow drawn on the front page follows that order. Optional static skills feed into the dynamic writing skill, but so does a corpus style profile built from three inputs: target-journal papers as the primary corpus, field-top or topic-similar papers as an optional secondary corpus, and user or lab exemplars as an optional third input. Only the first of those three is required.
The framing in the description is worth keeping in view: learn any journal's writing conventions from its published papers, then revise the manuscript to match. The unit of adaptation is the journal, not the field, and the unit of output is a rules document, not prose.
P1 wins outright, P2 only usually wins, and P3 through P5 are left unordered
The priority system has five tiers and orders two of the relationships between them explicitly.
P1 is hard constraints: facts, citations, equations, notation, numerical results, labels and author-defined terminology must be preserved. P2 is the target-journal corpus, meaning reviewed target-journal patterns. P3 is the secondary corpus and exemplars, to be used when target-journal evidence is absent or weak. P4 is the static base skill, applied when corpus signals do not decide. P5 is cleanup, meaning removing AI-taste phrases, hollow transitions, generic contributions and unsupported overclaims.
The stated rules are that P1 always wins and P2 usually beats P3 and P4. That is where the specification stops. Nothing says whether P3 or P4 takes precedence when the target journal is silent, nothing places P5 relative to anything, and the word usually leaves room for P2 to lose. What the project does provide is the escape valve: any conflict that changes revision behavior should be recorded in the revision log, so the resolution is expected to be visible rather than automatic.
Five external repositories stand in for the static layer, and you can skip it entirely
The static layer is optional by design, and the page names five specific repositories as ready-made options, each aimed at a different field.
Economics writing and referee-style guidance comes from `hanlulong/econ-writing-skill`. ML, CV and NLP paper writing comes from `Master-cai/Research-Paper-Writing-Skills`. A CS systems and networking pipeline comes from `SNL-UCSB/paper-writing-skill`. Philosophy and interdisciplinary planning comes from `lishix520/academic-paper-skills`. Generic AI-writing cleanup comes from `blader/humanizer`. Longer notes sit in `docs/STATIC_SKILL_RECOMMENDATIONS.md`.
Four custom shapes are offered instead, and the fourth is the one that matters most for understanding the architecture: no static skill at all, for when the dynamic corpus should drive the workflow on its own. The other three are your own `SKILL.md`, a lab or advisor writing guide for stable style preferences, and a journal or field checklist for a lightweight rule sheet rather than a full skill. The static tier is therefore genuinely a floor you may decline to set.
The corpus is three tiers, and only the first is required
The primary corpus is target-journal papers, marked required, and it is credited with the journal's local writing culture: structure, contribution framing, method and result exposition, and discussion scope. That is a fuller claim than style matching, since it says the corpus is used to infer how a journal frames a contribution, not just how it hyphenates.
The secondary corpus is field-top or topic-similar papers, optional, for when the target-journal corpus is small or the topic needs more reference points. The third tier is user or lab exemplars, optional, carrying author, advisor or lab preferences that should be preserved where they do not conflict with the target journal.
The precedence rule is stated with an escape clause. The target journal has the highest priority, and the optional tiers enrich the dynamic skill but do not override reviewed target-journal patterns unless the user explicitly asks for that behavior. So the default is journal-first, and overriding it is a deliberate act rather than an accident of corpus weighting.
Recommended sizes are small: 5 to 8 primary papers, 2 to 5 secondary papers, and 1 to 3 exemplar documents.
Incomplete PDF conversion has four remedies, one of which is throwing the paper away
There is a gate before Phase 1: every corpus file has to be fully readable Markdown or text. The stated remedies for a PDF that does not convert cleanly are to retry the conversion, use another converter, supply clean Markdown or text directly, or replace the paper.
That last option is the one worth pausing on, because it means a corpus entry can be dropped rather than degraded. Nothing on the page says what happens to the style profile when a paper is replaced after the profile has been generated, so the safe reading is that replacement belongs before the profile is built.
The converter situation is honest about its own weight. PDF input needs a PDF-to-Markdown converter, MinerU is supported, and Markdown input is the recommended path precisely when MinerU is hard to install. The two directory layouts reflect that preference: a `corpus/` folder of `.md` files alongside `manuscript.md`, or a `corpus_pdfs/` folder of PDFs alongside `manuscript.pdf`. The Markdown route is the documented default and the PDF route is the one with a dependency you may not be able to satisfy.
Installation is a copy into a skills folder, and Codex gets two different routes
For Claude Code the install is two commands:
mkdir -p ~/.claude/skills/journal-adapt
cp -R skill/* ~/.claude/skills/journal-adapt/Note what is copied: the contents of `skill/`, not the repository. The repository root holds `.gitignore`, `LICENSE`, `README.md`, `docs/`, `examples/` and `skill/`, so the documentation and the worked example stay behind and only the skill travels. Longer instructions, including the PDF conversion setup, live in `docs/INSTALLATION.md`.
Codex is handled with two options and a caveat. You can copy or symlink the `skill/` folder into the Codex skills directory if the local setup supports custom skills, or you can keep the repository open and point Codex at `skill/SKILL.md` directly. The conditional is doing real work: whether the directory route works at all depends on the local Codex configuration, which the project does not specify.
Invocation is a slash command:
/journal-adaptOr a plain request in natural language, naming the target-journal papers and the base writing skill.
The intake list breaks off before its third item
After invocation the skill asks for a short set of things. The first is the target journal or writing destination. The second is the primary corpus folder. The third begins with the letters `Optio` and the front page stops there.
That is one unfinished line rather than a missing section, but it lands in the most operational place on the page. A reader cannot tell from it whether the remaining intake covers the secondary corpus, the exemplars, the static skill choice, or the output path. The natural language route on the page implies those things can be supplied in the request itself, so the skill is likely to ask for them in context rather than through a fixed form, but that is inference from the surrounding text rather than something stated.
The workflow also does not say how many phases there are in total. Phase 1 is named as the gate that corpus files must pass before it, which implies a later numbered phase, and the revision log is named as the last artifact in the diagram.
One release, one example directory, and no recorded primary language
The repository has exactly one release, v1.0, published on 2026-05-13, and the last push is dated 2026-05-15. There has been no tagged work since.
The worked example surface is a single directory, `examples/jeem/`. The front page never says which journal that name refers to, so a reader cannot tell from the repository whether it is a target-journal profile, a corpus sample, or a complete before-and-after revision. If you want to see what the output looks like on a real journal, that directory is the only place to look.
The repository also records no primary language, which fits a project whose deliverable is Markdown and prose rather than code: the root entries are a license, a readme, documentation, examples and the skill folder, with no source directory and no build. The whole artifact you install is a folder of instructions for an agent, which is why the copy-two-commands install is the entire setup story.
For a writing tool, that thinness is the design. It also means there is no test suite to read and no changelog beyond a single version.
Editorial conclusion
This is a sensible division of labour for anyone revising a manuscript against a specific journal's house style, and the honest part is the scope it claims. It does not write the paper. It produces a visible Markdown file of rules and priorities that a person or an agent applies section by section, which is the difference between a tool you can argue with and a tool you have to accept. Use it when you have a real corpus, because that is the only required input and the whole design rests on it. The recommended starting point of five to eight target-journal papers is small enough to assemble and large enough to show a pattern, and it is worth gathering them in Markdown rather than PDF so the first phase has a clean gate to pass. Three things to check before you rely on it. First, the priority ordering is partial: the hard-constraint tier is absolute, the target-journal tier usually beats the others, and the relationship between the secondary corpus, the static base and the cleanup rules is not stated at all. Second, the static layer is a menu of five external repositories plus your own options, so you are choosing someone else's rules as your floor. Third, there is exactly one release and one worked example directory in this repository, so the proof surface is a single journal and a single version, and the intake list on the front page breaks off before its third item. None of that makes it unusable. It does mean the framework is auditable in a way most writing tools are not, and you should budget for being the one who resolves the conflicts it records.
Frequently asked questions
Does journal-adapt write my paper for me?
No. It produces a visible, editable dynamic_writing_skill.md that acts as an auditable revision framework for section-by-section rewriting. The described flow runs from a corpus style profile to human review, then section revision, then a revision log.
What does journal-adapt need as input?
A target journal or writing destination and a primary corpus folder are the first two things it asks for. The corpus must be fully readable Markdown or text before Phase 1; a PDF that converts incompletely has to be reconverted, replaced by another converter, supplied as clean text, or swapped for another paper.
How many papers should I put in the journal-adapt corpus?
The recommended starting point is 5 to 8 target-journal papers for the primary corpus, 2 to 5 field-top or topic-similar papers for the secondary corpus, and 1 to 3 user or lab exemplar documents. Only the primary tier is required.
Which static writing skill should I pair with journal-adapt?
Five are named as options, from economics writing and referee-style guidance through ML, CV and NLP paper writing, a CS systems pipeline, philosophy and interdisciplinary planning, and a generic AI-writing cleanup skill. You can also supply your own SKILL.md, a lab guide, a checklist, or no static skill at all.
How does journal-adapt decide between conflicting rules?
Five tiers are defined. Hard constraints such as facts, citations, equations, notation and numerical results always win. Reviewed target-journal patterns usually beat the secondary corpus and the static base skill. Any conflict that changes revision behavior is supposed to be recorded in the revision log.
How do I install journal-adapt for Codex?
Copy or symlink the skill folder into the Codex skills directory if your local setup supports custom skills, or keep the repository open and point Codex at skill/SKILL.md directly. For Claude Code the documented route is to create ~/.claude/skills/journal-adapt and copy the contents of skill/ into it.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/wantongc-journal-adapt-writing-skill)