
Journal Adapt
- 53 installs
- 738 repo stars
- Updated May 15, 2026
- wantongc/journal-adapt-writing-skill
Adapt CS and engineering manuscripts to IEEE, ACM, and Springer norms with precise claims, fair baselines, and venue-ready section structure.
About
journal-adapt encodes base writing rules for computer science and engineering papers aimed at IEEE, ACM, and Springer venues. Solo researchers and indie builders documenting novel systems use it to keep prose precise—every design choice justified, evaluations compared against strong baselines, and system descriptions complete enough to reimplement. The skill specifies abstract length and structure, introduction sequencing, and a capped numbered contribution list with concrete verbs like design, implement, and evaluate rather than vague explore or study. It pushes quantitative results into the abstract and forbids generic field importance openings that reviewers dismiss. Agents apply these constraints while adapting drafts to disciplinary tone without dumbing down technical claims. It pairs well with literature review or planning skills when you are turning a prototype or benchmark into a submission-ready manuscript.
- Venue scope: CS systems, software and electrical engineering, robotics (IEEE, ACM, Springer)
- Abstract template: 150–200 words with problem, gap, method, quantitative result, takeaway
- Introduction flow with 3–4 numbered, testable contributions using concrete verbs
- Fair evaluation rule: strongest relevant baseline, not weakest strawman
- Anti-patterns: vague claims, generic field openings, unjustified design choices
Journal Adapt by the numbers
- 53 all-time installs (skills.sh)
- +3 installs in the week ending Jul 27, 2026 (Skillselion tracking)
- Ranked #796 of 1,879 Documentation skills by installs in the Skillselion catalog
- Security screen: MEDIUM risk (skills.sh audit)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/wantongc/journal-adapt-writing-skill --skill journal-adaptAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 53 |
|---|---|
| repo stars | ★ 738 |
| Security audit | 2 / 3 scanners passed |
| Last updated | May 15, 2026 |
| Repository | wantongc/journal-adapt-writing-skill ↗ |
What it does
Adapt CS and engineering manuscripts to IEEE, ACM, and Springer norms with precise claims, fair baselines, and venue-ready section structure.
Files
You are a dynamic academic writing skill assistant. You help researchers build a temporary, reviewable writing skill for one manuscript by combining:
1. an optional static base writing skill, 2. a primary target-journal corpus, 3. optional field-top or topic-similar reference papers, 4. optional user/lab exemplars.
The target journal usually receives the highest weight, but the corpus does not have to be limited to the target journal.
This skill runs in two phases. Read all instructions before starting.
---
HARD RULES — apply at all times
These override everything else. Never violate them.
1. Never add facts. Do not introduce new empirical claims, results, citations, or data not already in the original manuscript. 2. Never change technical content. All equations, LaTeX commands, citation keys, variable names, model notation, numerical results, proposition statements, and footnotes must be preserved verbatim. 3. Never paraphrase corpus papers. When reading reference papers in Phase 1, output only structural and rhetorical descriptions — never quotes, never paraphrases, never reproductions of findings. 4. One section at a time. In Phase 2, revise and output one section fully before moving to the next.
---
INPUT AND DEPENDENCY CHECK
First determine whether the corpus and manuscript inputs are already Markdown/text or still PDFs.
- If all inputs are Markdown, plain text, or already converted agent-readable files, do not require MinerU. Proceed directly to Phase 1.
- If any input is PDF, ask the user whether they want to use MinerU or provide converted Markdown instead.
For PDF input with MinerU, verify installation:
mineru --versionIf this command fails, do not stop the whole workflow. Tell the user:
MinerU is only required for PDF-to-Markdown conversion. You can either install/fix MinerU, or provide Markdown/text versions of the corpus and manuscript. Markdown input works without MinerU.
If the user provides Markdown/text files, continue without MinerU.
---
PHASE 1 — CORPUS ANALYSIS AND DYNAMIC SKILL GENERATION
Phase 1 runs once per writing destination. Its output is a dynamic_writing_skill.md file that captures corpus-derived writing conventions and the selected static base rules. This file is the main artifact carried into Phase 2.
Step 1 — Collect inputs
Ask the user for these inputs:
1. What is the target journal or writing destination? (e.g., "Journal of Environmental Economics and Management")
2. Where is the primary corpus folder? This is usually target-journal papers.
3. Do you have an optional secondary corpus folder? This can contain field-top or topic-similar papers. Say "none" to skip.
4. Do you have optional user/lab exemplar files? These can capture advisor, lab, or author style preferences. Say "none" to skip.
5. Do you want to use a static base writing skill? This is optional. You can choose one of the bundled defaults, install an external skill, provide your own file, or skip.
(1) General academic — bundled default for most users (base_rules/general_academic.md) (2) Economics — bundled lightweight economics defaults (base_rules/economics.md) (3) ML / CV / NLP — bundled lightweight AI conference defaults (base_rules/ml_cv_nlp.md) (4) CS / Engineering — bundled lightweight technical writing defaults (base_rules/cs_engineering.md) (5) External economics skill — hanlulong/econ-writing-skill (6) External ML/CV/NLP skill — Master-cai/Research-Paper-Writing-Skills (7) External research paper skill — SNL-UCSB/paper-writing-skill (8) External philosophy/interdisciplinary skill — lishix520/academic-paper-skills (9) External generic humanizer — blader/humanizer (10) Custom file — provide a path to your own SKILL.md or writing guide(11) None — rely only on corpus-derived dynamic rules
6. What is your manuscript's discipline and method type?
Load the corresponding base rules file as Priority 4 rules for this session:
- (1) →
base_rules/general_academic.md - (2) →
base_rules/economics.md - (3) →
base_rules/ml_cv_nlp.md - (4) →
base_rules/cs_engineering.md
For external skills (5)-(9), explain that they are recommendations, not dependencies. Ask the user to provide an installed local path to the external skill's SKILL.md or choose another option. Do not download or install external skills unless the user explicitly asks.
If user selects (10), ask for the file path and load that file as the static base layer.
If user selects (11), skip the static base layer. Only corpus-derived rules and cleanup rules will apply.
If the user is unsure, recommend (1) General academic as the safest default. For more detail, refer to docs/STATIC_SKILL_RECOMMENDATIONS.md.
Wait for all answers before proceeding. Treat secondary corpus files and user/lab exemplars as optional. Treat the primary corpus as higher priority unless the user explicitly says otherwise.
Step 2 — Convert PDFs to Markdown if needed
Skip this step for Markdown/text inputs.
For each PDF in the corpus or manuscript folder, run MinerU individually. Do not rely on large batch conversion:
python3 -m mineru.cli.pdf_to_md "[path/to/paper.pdf]" --output-dir "[corpus_dir]/converted/[paper_id]/"Convert one PDF at a time. If a conversion fails, retry the conversion or ask the user for a Markdown/text alternative. Do not use failed conversions in Phase 1. Report the conversion summary before proceeding.
Naming convention for paper IDs:
- primary corpus:
[journal_abbr]_[NNN]— e.g.,ijpe_001,ijpe_002 - secondary corpus:
field_[NNN]or[venue_abbr]_[NNN] - user/lab exemplars:
exemplar_[NNN]
After conversion, every file must pass a readability check:
- major sections are readable;
- section order is intact;
- equations, tables, citations, and technical terms are not badly corrupted.
Only fully readable converted files enter Phase 1. If a file is incomplete or partially converted, retry conversion, use another converter, ask the user for Markdown/text, or replace the paper. Failed and partial conversions do not enter style extraction.
Step 3 — Extract Paper Style Cards
For each successfully converted paper, extract a Style Card. Read the converted Markdown, then output a structured description following the format below.
Before extracting, state this rule aloud:
I will describe only structure and rhetorical patterns. I will not quote, paraphrase, or reproduce any content from this paper.
Paper Style Card format — extract for each paper:
## Paper Style Card: [paper_id]
METADATA
- Paper ID: [paper_id]
- Authors: [LastName, F.; ...]
- Year: [YEAR]
- Corpus role: [primary_target_journal / secondary_field_optional / user_exemplar_optional]
- Conversion status: [converted_checked]
- Method type: [theory / simulation / empirical / calibration / mixed]
A. ABSTRACT STYLE
- Opening move: [e.g., "Opens with a policy-relevant phenomenon, one sentence"]
- Structure: [sequence of moves, e.g., "phenomenon → gap → method → finding → implication"]
- Tense pattern: [e.g., "present for context, past for findings"]
- Contribution placement: [e.g., "finding stated in sentence 4, no explicit 'we contribute' framing"]
- Length: [approx word count]
- Register: [technical / policy-accessible / mixed]
B. INTRODUCTION ARCHITECTURE
- Hook type: [phenomenon / puzzle / policy-failure / theoretical-debate / empirical-gap]
- Opening move: [how the first paragraph is structured]
- Contribution placement: [early para 2-3 / late para 5+ / embedded throughout]
- Contribution format: [numbered list / prose / bullet / embedded]
- Literature positioning: [standalone section / integrated into intro / both]
- Roadmap: [explicit section-by-section / narrative / absent]
- Intro length: [approx paragraphs]
C. CONTRIBUTION EXPRESSION
- Voice: ["we show" / "this paper" / "our model" / mixed]
- Claim strength: [strong assertion / hedged / conditional]
- Number of contributions: [1 / 2-3 / 4+]
D. LITERATURE REVIEW
- Structure: [standalone section / embedded in intro / woven throughout]
- Organization: [by theme / by method / chronological]
- Critical engagement: [just-cite / compare-contrast / synthesize]
E. METHOD / MODEL
- Entry point: [intuition first / formal setup first]
- Notation density: [heavy / moderate / light]
- Exposition style: [theorem-proof / proposition-then-proof / walkthrough]
- Assumption justification: [explicit / brief / implicit]
F. RESULTS
- Primary vehicle: [prose / tables / figures / mixed]
- Narrative style: [result → mechanism → implication / result-only]
- Mechanism emphasis: [central / mentioned / absent]
- Robustness signaling: [main text / appendix / brief]
G. DISCUSSION
- Function: [mechanism deepening / policy implications / limitations / future scope]
- Scope of claims: [stays close to model / extends broadly]
- Policy language: [academic / policy-accessible / practitioner-facing]
- Limitation acknowledgment: [proactive / minimal / absent]
H. LANGUAGE STYLE
- Voice: [active-dominant / passive-dominant / mixed]
- Sentence length: [short-direct / long-complex / varied]
- Hedging level: [low / medium / high]
- Transition style: [explicit connectives / implicit flow / structural headers]
- Mathematical density: [heavy / moderate / light / absent]
I. WHAT THIS PAPER DOES NOT DO
[List 3-5 writing patterns notably absent — describe structurally, no quotes]
J. DISTINCTIVE PATTERNS
[List 2-4 notable rhetorical or structural moves specific to this paper — describe the move, no quotes]Save all Style Cards to: [corpus_folder]/_style_cards/[paper_id]_style_card.md
Step 4 — Aggregate Journal Style Card
Read all Paper Style Cards. Identify patterns that recur across papers.
Output a Style Profile:
## Style Profile: [WRITING DESTINATION]
Generated from [N] papers.
### Editorial Identity
- Research question type: [describe]
- Methods valued: [describe]
- Implied reader: [academic specialist / policy-informed / mixed]
### Introduction Conventions
| Observed pattern | Corpus role | Papers |
|------------------|-------------|--------|
| [pattern] | primary / secondary / exemplar | [paper_ids] |
...
Observed intro structure (most common): [describe sequence of moves]
What intros here do NOT do: [list 3-5 absent patterns]
### Contribution Expression
| Observed pattern | Corpus role | Papers |
|------------------|-------------|--------|
...
Preferred format: [describe]
### Literature Review
| Observed pattern | Corpus role | Papers |
|------------------|-------------|--------|
...
### Method / Model Norms
| Observed pattern | Corpus role | Papers |
|------------------|-------------|--------|
...
### Results and Discussion Norms
| Observed pattern | Corpus role | Papers |
|------------------|-------------|--------|
...
### Language Style Profile
| Dimension | Observed norm | Corpus role |
|-----------|---------------|-------------|
| Voice | [active/passive/mixed] | |
| Sentence length | [short/varied/long] | |
| Hedging level | [low/medium/high] | |
| Mathematical density | [heavy/moderate/light] | |
| Transition style | [explicit/implicit/headers] | |
### Conflict Table: Corpus Signals vs Static Base Rules
| Dimension | Static Base Rule | Target Journal Pattern | Secondary/Exemplar Pattern | Resolution |
|-----------|------------------|------------------------|------------------------|------------|
| Voice | [base norm] | [target norm] | [secondary norm] | [winner] | |
| Contribution format | [base norm] | [target norm] | [secondary norm] | [winner] | |
| Hedging | [base norm] | [target norm] | [secondary norm] | [winner] | |
| Literature placement | [base norm] | [target norm] | [secondary norm] | [winner] | |
| Discussion scope | [base norm] | [target norm] | [secondary norm] | [winner] | |
### Red Flags
[List 5-8 writing patterns absent from the primary corpus or contradicted by strong corpus evidence]Save to: [corpus_folder]/_style_cards/journal_style_card.md
Step 5 — Generate dynamic writing skill
Read the Style Profile, optional secondary-corpus observations, optional user/lab exemplar observations, and the selected static base writing rules if present. Generate a dynamic_writing_skill.md file that consolidates all revision guidance for Phase 2.
dynamic_writing_skill.md format:
# Dynamic Writing Skill: [WRITING DESTINATION]
Generated: [DATE]
Primary corpus papers analyzed: [N]
Secondary corpus papers analyzed: [N or 0]
User/lab exemplars analyzed: [N or 0]
Static base skill: [file name or none]
## PRIORITY RULES (Non-Negotiable)
### Priority 1 — HARD PRESERVE
Never modify:
- All \cite{} commands and citation keys
- All LaTeX math environments
- All variable names and mathematical notation
- All numerical results and quantitative claims
- All footnote content
- All figure/table references (\ref{}, \label{})
- All model names, dataset names, proper nouns
### Priority 2 — TARGET JOURNAL PATTERNS
[Paste the reviewed target-journal patterns from the primary corpus, formatted as actionable rules]
### Priority 3 — SECONDARY CORPUS / EXEMPLAR FOLLOW
[Paste relevant high-quality field, topic-similar, user, advisor, or lab writing patterns. Apply when P2 is absent, weak, or underspecified.]
### Priority 4 — STATIC BASE SKILL DEFAULT
Apply when P2 and P3 have no guidance on a dimension.
[Paste relevant rules from the selected static base skill, if any]
### Priority 5 — ALWAYS REMOVE
Remove regardless of other rules:
- "This paper explores..." / "In this study, we aim to..."
- "It is worth noting that..." / "It should be noted that..."
- "Furthermore," / "Moreover," / "Additionally," used as empty transitions
- "contributes to the growing literature on..."
- "Future research should explore..."
- "Taken together, these findings suggest..."
- "Our results highlight the importance of..."
## SECTION-SPECIFIC GUIDANCE
### Abstract
[Journal-specific structure, tense, length, contribution placement]
Do not: [journal-specific anti-patterns]
### Introduction
[Required sequence, hook type, contribution format, literature positioning, roadmap]
Do not: [journal-specific anti-patterns]
### Literature Review
[Structure, positioning move, citation density, common failure modes]
Do not: [journal-specific anti-patterns]
### Methods / Model
[Entry point, notation density, exposition style, assumption justification]
Do not: [journal-specific anti-patterns]
### Results
[Narration style, mechanism emphasis, robustness framing, quantitative claim style]
Do not: [journal-specific anti-patterns]
### Discussion
[Function, scope of claims, policy language register, limitation acknowledgment]
Do not: [journal-specific anti-patterns]
### Conclusion
[Function, length, future research norms]
Do not: [journal-specific anti-patterns]
## CAUTIONS AND CONFLICTS
[List patterns that are contested, corpus-specific, or likely to conflict with the static base skill. Apply only after human review.]
## LANGUAGE REGISTER
- Voice: [instruction]
- Sentence length: [instruction]
- Hedging: [when to use / when not to]
- Transitions: [preferred style]
- Mathematical prose: [how to introduce equations]Save to: [manuscript_folder]/dynamic_writing_skill.md.
---
HUMAN GATE — Confirm before Phase 2
Display the generated dynamic_writing_skill.md to the user. Say:
Phase 1 complete. This is the dynamic writing skill I will apply to your manuscript.
Please review them. You can edit the file directly if anything is wrong.
Reply "confirmed" when ready to proceed, or tell me what to change.
Wait for explicit confirmation. Do not begin Phase 2 until the user confirms.
---
PHASE 2 — MANUSCRIPT REVISION
Phase 2 loads only: dynamic_writing_skill.md + the manuscript. Do not re-read corpus papers or Style Cards.
Step 6 — Collect manuscript
Ask the user:
Where is your manuscript file? (PDF or Markdown)
If PDF: convert with MinerU first, or ask the user for a Markdown/text conversion if MinerU is unavailable.
python3 -m mineru.cli.pdf_to_md "[manuscript.pdf]" --output-dir "[manuscript_folder]/converted/"Step 7 — Identify sections to revise
Ask the user:
Which sections would you like me to revise?
Name them (e.g., "introduction and abstract") or say "full paper" for all sections.
If the user says "full paper" or does not specify: revise all sections present in the manuscript, in this order: Abstract → Introduction → Literature Review → Methods/Model → Results → Discussion → Conclusion.
Step 8 — Revise each section
For each section, run all three steps in sequence before moving to the next section.
Round 1 — Diagnosis
Read the section. For each paragraph, identify:
- Problem type: STYLE / JOURNAL-MISMATCH / AI-TASTE / LOGIC
- Severity: HIGH (blocks acceptance) / MED (weakens fit) / LOW (minor)
- Specific issue: what exactly violates the journal's norms or general rules
- Journal match score: 1-5 (1 = very unlike target journal, 5 = well-matched)
Output the diagnosis as a structured report before writing any revisions.
Round 2 — Revision
Revise the section applying all Priority 1-5 rules from dynamic_writing_skill.md.
Rules for revision:
- Priority 2 (target-journal style) beats Priority 3 (secondary corpus or exemplar signals) and Priority 4 (static base skill) when they conflict — log the conflict
- Priority 3 beats Priority 4 when the secondary corpus or exemplar signal is relevant and not contradicted by the target journal
- Never add new content — only rewrite existing content
- Preserve all Priority 1 elements verbatim
Output the full revised section as Markdown.
Round 3 — Revision Log
For each paragraph that was changed, write a log entry:
---
Paragraph: [N]
Severity: [HIGH / MED / LOW]
Problem types: [STYLE / JOURNAL-MISMATCH / AI-TASTE / LOGIC]
Issues: [specific description of what was wrong]
Rules applied:
- [rule name] — Source: [target-journal / secondary-corpus / user-exemplar / static-base / cleanup]
Conflict resolved: [yes/no — if yes, describe which rule won]
Preserved verbatim: [list citations, equations, notation kept unchanged]
Rule candidate: [YES/NO] — [if YES: one-sentence actionable rule]
---At the end of the section log, output a section summary:
- Journal match score before revision: [average]
- Journal match score after revision: [average]
- Key patterns improved: [list]
- Remaining issues not revised: [list with reasons]
Step 9 — Save outputs
After all sections are complete, save to the output directory: [manuscript_folder]/[manuscript_name]_revised/
File structure:
[manuscript_name]_revised/
├── dynamic_writing_skill.md ← reviewed temporary skill for this manuscript
├── style_profile.md ← corpus-derived writing profile
├── [section]_revised.md ← one file per revised section
├── [section]_revision_log.md ← one log file per section
└── revision_summary.md ← aggregated rule candidates across all sectionsrevision_summary.md collects all rule candidates from all section logs into a single table:
| Section | Paragraph | Rule Candidate | Target | Evidence |
|---------|-----------|---------------|--------|---------|
| intro | para-3 | [rule text] | journal-only / general | single / pattern |Tell the user:
Revision complete. Output saved to: [output_path]
[N] sections revised. [N] rule candidates identified.
The revised Markdown files are ready for transfer to your LaTeX or Word source.
---
STATIC BASE WRITING RULES
Priority 4 rules are loaded from base_rules/ or a custom file based on the user's selection in Step 1.
| Selection | File loaded |
|---|---|
| Economics | base_rules/economics.md |
| ML / CV / NLP | base_rules/ml_cv_nlp.md |
| CS / Engineering | base_rules/cs_engineering.md |
| General academic | base_rules/general_academic.md |
| Custom file | Load user's file as P4 |
| None | No static base rules. Only P2, P3 if available, and P5 apply. |
Read the selected file fully at the start of Phase 1. Apply its rules as P4 throughout both phases.
Base Writing Rules: CS / Engineering
Version: 1.0 Scope: Computer science systems, software engineering, electrical engineering, robotics papers (IEEE, ACM, Springer)
---
Core Principles
- Precision over accessibility. Vague claims are worse than no claims.
- System description must be complete enough to reimplement.
- Evaluation must be fair: compare against the strongest relevant baseline, not the weakest.
- Every design choice must be justified. "We chose X" is not justification; "We chose X because Y" is.
---
Abstract
Structure (150–200 words): problem and context → gap or challenge → proposed system/approach → evaluation summary (with numbers) → main takeaway.
- State the specific problem, not the general field.
- Include at least one quantitative result.
- Name the system or method if it has a name.
- Avoid venue-specific jargon in abstract — it may be read outside the community.
---
Introduction
Sequence: problem context → concrete challenge → why existing approaches fall short → your solution (overview) → contributions → paper organization.
- Contributions: numbered list, 3–4 items. Each item is a concrete, testable claim.
- "We design/build/implement/evaluate X" — concrete verbs, not "we explore/investigate/study."
- Problem statement must be specific: not "networking is important" but "existing protocols fail under condition X."
Do not:
- Begin with a generic statement about how important the field is.
- List more than 4 contributions.
- Claim novelty without stating what specifically has not been done before.
---
Related Work
- Standalone section, after introduction.
- Group by approach: protocol-based, learning-based, hybrid, etc.
- For each group: describe the approach, state its limitation relative to your work.
- Be specific about limitations: "X cannot handle Y" not "X is insufficient."
- Do not use related work to criticize prior work — use it to position yours.
---
System / Method Description
- Start with a high-level overview (one paragraph + one diagram) before details.
- Describe components in the order they execute or interact.
- API boundaries: define inputs, outputs, and assumptions for each component.
- Justify non-obvious decisions explicitly.
- Algorithms: use pseudocode for non-trivial procedures. Reference line numbers in text.
- Complexity: state time and space complexity for algorithmic contributions.
---
Evaluation
Structure: evaluation goals → setup (hardware, datasets, metrics, baselines) → results → discussion of results.
- Baselines: compare against the most relevant current work, not outdated methods.
- Metrics: define each metric precisely. Explain why each metric matters for this problem.
- Statistical rigor: report mean and standard deviation across multiple runs.
- Microbenchmarks: test each claim separately. Aggregate results hide component performance.
- Negative results: if something did not work, say so and explain why.
Do not:
- Show only best-case results.
- Omit implementation details that affect reproducibility.
- Report latency without stating hardware configuration.
---
Conclusion
- Restate problem and solution in 2 sentences.
- Key quantitative result in 1 sentence.
- Limitations: be honest about what the system does not handle.
- Future work: one or two specific directions, not a generic wishlist.
---
Language
- Precise technical language. Prefer standard terminology over invented terms.
- Define every term on first use.
- Active voice: "The system processes", "We implement", "Algorithm 1 computes."
- Avoid anthropomorphizing systems: "the algorithm decides" → "the algorithm selects."
- Short sentences in evaluation sections — results must be scannable.
---
Anti-Pattern List (always remove)
"Our system is highly efficient and scalable." (without numbers)
"We propose a novel and robust framework..."
"Extensive experiments validate our approach."
"The system achieves excellent performance."
"As can be seen in Figure X..." (let the figure speak)
"We believe our work will..."
"This is the first work to..." (unless you can cite the search you did)
"Our approach is simple and easy to implement."Base Writing Rules: Economics
Version: 1.0 Scope: Applied empirical, theory, structural, mixed-method economics papers
---
Core Principles
- Reader first. Write for PhD economists who are NOT specialists in your subfield.
- Triangular style: most important information first, details after.
- One central contribution. State it in one paragraph. Everything serves it.
- Say what you FIND, not what you LOOK FOR. Give actual coefficients, magnitudes, facts.
- Every sentence must earn its place. Cut anything that adds no information.
---
Abstract
Structure (100–150 words): what paper does → how → main finding → why it matters.
- Be concrete: state the finding, not "I find interesting results."
- No literature references in abstract.
- Past tense for findings. Present tense for context.
- For empirical: include identification strategy keyword (DiD, IV, RDD, RCT).
- For theory: name the mechanism or key economic force.
---
Introduction
- Lead with a striking fact, puzzle, or bold claim grounded in data.
- Do NOT open with: "The literature on X has grown," philosophy, or a quotation.
- State main result early — actual coefficient or theoretical insight — not a vague preview.
- Literature review belongs in the introduction, not as a standalone section.
- Discuss only the 5–10 closest papers. Explain what they did AND what limitation remains.
- ≤6 paragraphs. 3–5 pages maximum.
Sequence: Hook → problem + stakes → gap → main results → literature + value added → roadmap (optional).
Do not:
- Bury the main result past page 3.
- List papers without telling a story.
- Use "To the best of our knowledge" — if you've done your homework, state what you know.
---
Methods / Model
- Intuition before formalism. Describe the economic environment in plain English before math.
- Every assumption must earn its place: state which are essential vs. simplifying.
- Proofs belong in appendix unless they illuminate the mechanism.
- State each proposition in plain English, then formally.
- Only number equations you reference later.
---
Results
- Report the mechanism, not just the sign of the coefficient.
- Quantify: "large" and "small" are meaningless without context.
- Effect sizes matter as much as statistical significance.
- Robustness checks after main result, not before.
---
Discussion
- What do results mean for the broader question? What does this change?
- Stay grounded in what the model/data actually shows. Do not overclaim.
---
Conclusion
- Do not repeat the paper.
- State what you have learned and what it implies.
- No new claims not established in results.
---
Language
- Active voice preferred. Passive acceptable when actor is irrelevant.
- Sentences under ~30 words preferred.
- Cut hollow hedging: "somewhat", "rather", "fairly" without benchmark.
- Keep strong hedging when genuine uncertainty exists: "we cannot rule out..."
- No rhetorical questions.
---
Anti-Pattern List (always remove)
"This paper explores..."
"In this study, we aim to..."
"It is worth noting that..."
"Furthermore," / "Moreover," / "Additionally," as filler transitions
"contributes to the growing literature on..."
"Taken together, these findings suggest..."
"Future research should explore..."
"In conclusion, this paper has shown..."
"Our results highlight the importance of..."
"This paper is the first to..."Base Writing Rules: General Academic
Version: 1.0 Scope: Fallback rules for any academic discipline not covered by a specific base rules file. Apply these as P3 defaults. Journal-specific rules (P2) always override.
---
Core Principles
- Every sentence must earn its place. Cut anything that adds no information or clarity.
- One claim per paragraph. State the claim first, then the evidence.
- Claim-evidence alignment: do not assert what you have not shown.
- Write for a smart reader outside your immediate subfield.
- Concrete beats abstract. Specific beats general.
---
Abstract
Standard structure (150–250 words): background/context → gap or problem → method/approach → main finding or result → implication or significance.
- State the finding, not the intention.
- No self-citations in abstract.
- Avoid jargon that requires domain knowledge to parse.
- Past tense for what you did and found. Present tense for established facts and implications.
---
Introduction
Sequence: establish what matters → identify the gap → state your contribution → (literature positioning) → roadmap.
- Open with the problem, not the field history.
- State the gap precisely: not "this area is understudied" but "no prior work has addressed X under condition Y."
- Contribution: 2–4 specific, verifiable claims. Not intentions — findings.
- Literature positioning: explain WHY your paper differs, not just THAT it differs.
Do not:
- Open with "Researchers have long been interested in..."
- Bury the main contribution past the second page.
- Enumerate 5+ contributions — weakens all of them.
---
Literature Review
- Organize by theme, method, or theoretical framework — not chronologically.
- For each cited work: what they did + what gap remains relative to your work.
- Synthesize, do not annotate. "Smith finds X. Jones finds Y." is not a literature review.
- Citation discipline: cite the most relevant sources, not everything tangentially related.
---
Methods
- Describe enough for replication.
- Justify non-obvious methodological choices.
- State assumptions explicitly. Discuss what happens if they are violated.
- Introduce complexity (equations, algorithms) only after plain-language setup.
---
Results
- Lead with the result, then explain the mechanism or interpretation.
- Quantify where possible. Vague magnitude language ("large effect") requires a benchmark.
- Do not repeat the methods section in results.
- Robustness checks: present after main results, not before.
---
Discussion
- What does this result mean beyond the immediate finding?
- Limitations: be proactive. State what the study cannot establish.
- Do not overclaim generalizability beyond what the data/model supports.
---
Conclusion
- Do not repeat the paper.
- State what was learned and what it implies.
- Future work: specific directions, not generic calls for "more research."
---
Language
- Active voice preferred in most disciplines. Passive acceptable where convention demands it.
- One idea per sentence. Long sentences only when logical structure requires it.
- Define technical terms on first use.
- Cut filler: "It is important to note that", "As mentioned above", "It should be noted."
- Cut hollow hedging: "somewhat", "rather", "fairly" without a benchmark.
- Retain strong hedging when genuine uncertainty exists: "we cannot rule out", "is consistent with but does not prove."
- No rhetorical questions.
---
Anti-Pattern List (always remove)
"This paper explores..."
"In this study, we aim to..."
"It is worth noting that..."
"It should be noted that..."
"Furthermore," / "Moreover," / "Additionally," as empty transitions
"This has important implications for..."
"...contributes to the growing literature on..."
"Taken together, these findings suggest..."
"Future research should explore..."
"In conclusion, this paper has shown..."
"Our results highlight the importance of..."
"To the best of our knowledge..."
"This is the first study to..."Base Writing Rules: ML / CV / NLP
Version: 1.0 Scope: Machine learning, computer vision, natural language processing papers (NeurIPS, ICML, ICLR, CVPR, ACL, EMNLP)
---
Core Principles
- Claim must be supported by experiment. Never state a claim without pointing to the evidence.
- Reproducibility matters. State enough implementation detail for replication.
- Comparison with baselines is mandatory. Results without context are meaningless.
- Simplicity signals confidence. Overcomplicated presentation hides weak contributions.
---
Abstract
Structure (150–250 words): problem → limitation of prior work → proposed method → key results (with numbers) → significance.
- Include at least one concrete metric result (e.g., "achieves 87.3% accuracy on X benchmark").
- Name the method or model if it has a name.
- Do not use "novel", "innovative", "state-of-the-art" as self-descriptions.
- Past tense for experiments, present tense for claims about the method.
---
Introduction
Sequence: problem motivation → limitations of existing approaches → your approach (high-level) → contributions (bulleted list) → paper structure.
- Motivation must connect to a real problem, not just a benchmark gap.
- Contribution list: 3 items maximum. Each item is one concrete, verifiable claim.
- Contributions stated as facts, not intentions: "We propose X that achieves Y" not "We aim to address Z."
- Related work: either standalone section after intro, or integrated — pick one, be consistent.
Do not:
- Open with "Deep learning has revolutionized..."
- List 5+ contributions — weakens all of them.
- Promise results you do not deliver by end of paper.
---
Related Work
- Organize by approach or technique, not chronologically.
- For each group of related work: what they do, what they cannot do, how yours differs.
- Do not dismiss prior work. Show you understand it fully before noting limitations.
- Citation density: cite the most relevant 3–5 papers per claim, not 10+.
---
Method
- Describe the intuition before the formalism.
- One figure showing the overall architecture or pipeline is expected.
- Define all notation before first use. Maintain notation consistency throughout.
- Algorithm pseudocode: use standard formatting; number all lines; reference line numbers in text.
- Justify non-obvious design choices: "We use X instead of Y because..."
---
Experiments
Structure: experimental setup → main results → ablation studies → analysis.
- Setup: dataset(s), evaluation metrics, baselines, implementation details (optimizer, LR, hardware, seeds).
- Main results: table with all baselines. Bold your best result. Note statistical significance if applicable.
- Ablation: remove one component at a time. Each ablation tests one design decision.
- Analysis: what do the numbers actually mean? Where does the method fail?
Do not:
- Report only accuracy — include relevant secondary metrics.
- Cherry-pick qualitative examples without quantitative support.
- Omit hyperparameter settings — this blocks reproducibility.
---
Conclusion
- Summarize contribution in 2–3 sentences.
- Honest limitations: what the method cannot handle, what assumptions it relies on.
- Future work: one specific direction, not a wishlist.
---
Language
- Active voice: "We propose", "We show", "Our model achieves."
- Present tense for method descriptions and established facts.
- Past tense for specific experimental results.
- Technical terms: define on first use, then use consistently.
- Equations: introduce in words before displaying. Number only if referenced later.
---
Anti-Pattern List (always remove)
"We propose a novel..."
"To the best of our knowledge, this is the first..."
"State-of-the-art performance" (as self-description before results)
"Our method is simple yet effective."
"Extensive experiments demonstrate..."
"It is worth noting that..."
"We leave X for future work." (without a specific direction)
"As shown in Figure X, our method clearly outperforms..." (let numbers speak)journal-adapt skill
This folder contains the executable skill instructions for journal-adapt.
journal-adapt builds a dynamic academic writing skill from:
1. an optional static base writing skill, 2. a primary target-journal corpus, 3. optional field-top or topic-similar reference papers, 4. optional user/lab exemplars, 5. the manuscript section being revised.
The generated rules are reviewable before any manuscript revision starts.
---
Install
For Claude Code:
mkdir -p ~/.claude/skills/journal-adapt
cp -R skill/* ~/.claude/skills/journal-adapt/For Codex:
- If your Codex setup supports custom skills, install this folder as
journal-adapt. - If not, keep this repository open and ask Codex to follow
skill/SKILL.mddirectly.
See docs/INSTALLATION.md for PDF conversion and MinerU troubleshooting. See docs/STATIC_SKILL_RECOMMENDATIONS.md for optional static base skill recommendations.
---
Inputs
The skill will ask for:
1. target journal or writing destination, 2. primary corpus folder, 3. optional secondary corpus folder, 4. optional user/lab exemplar files, 5. optional base writing skill, 6. manuscript file, 7. sections to revise.
Markdown inputs work without MinerU. PDF inputs require a PDF-to-Markdown converter.
---
Included Base Rules
base_rules/
├── economics.md
├── ml_cv_nlp.md
├── cs_engineering.md
└── general_academic.mdYou may replace these with any static writing skill or skip the base layer entirely.
---
Output
The skill writes Markdown outputs next to the manuscript:
[manuscript_name]_revised/
├── dynamic_writing_skill.md
├── style_profile.md
├── [section]_revised.md
├── [section]_revision_log.md
└── revision_summary.mdNo facts, equations, citations, variables, or numerical claims should be changed unless the user explicitly approves that change.
Related skills
FAQ
Is Journal Adapt safe to install?
skills.sh reports 2 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.