review-article

name	review-article
description	Review a draft article for academic/technical journal submission. Gives structured feedback on clarity, contribution, structure, novelty, and journal fit. Use when you have a draft article and want an expert critical review before submission.
argument-hint	<article_file_or_dir> [target_journal]
allowed-tools	Read, Write, Glob, Grep, WebSearch

Article Review

Perform a thorough editorial and peer-review style critique of a draft article for journal submission.

Arguments

• $0 — Path to the article file (.md, .txt, .tex, or a directory) (required)
• $1 — Target journal name (optional; e.g. "IEEE Software", "CACM", "IEEE TSE"). If omitted, review for general quality and suggest journals.

Workflow

Phase 1: Read and Understand the Article

Read the full article (or all files if a directory is given). Extract:

• Title and authors
• Abstract
• Sections / structure
• Core claim / contribution
• Methodology (if any)
• Evidence / examples used
• References (count, recency, diversity)

Phase 2: Evaluate Against Review Criteria

Assess the article on all of the following dimensions. For each, provide a score (1–5) and specific, actionable comments.

2a. Contribution and Novelty

• What is the central insight or contribution?
• Is it new? Has this been said before (and if so, is it said better here)?
• Would a practitioner or researcher learn something they didn't know?
• Is the problem worth solving / the question worth asking?

2b. Clarity and Writing Quality

• Is the abstract clear and self-contained?
• Is the title accurate and compelling?
• Are section transitions smooth?
• Is terminology defined before use?
• Are sentences and paragraphs concise? (Mark any that are bloated or confusing)
• Is passive voice overused?

2c. Structure and Logic

• Does the introduction set up the problem well?
• Does the conclusion follow from the argument?
• Are claims supported by evidence?
• Is the argument logically consistent throughout?
• Are there unsupported leaps in reasoning?

2d. Technical Depth and Accuracy

• Are technical claims correct?
• Is the methodology sound (for empirical work)?
• Are examples well-chosen and accurate?
• Are limitations acknowledged?

2e. Audience Fit

• Who is this written for? (researchers, practitioners, broad CS audience)
• Is the assumed background appropriate for the target venue?
• Is it too academic for a magazine, or too informal for a journal?

2f. References and Related Work

• Is related work adequately covered?
• Are key references missing?
• Are references recent (within 5 years where appropriate)?
• Are self-citations excessive?

2g. Journal Fit (if target journal specified)

• Load the journal profile from data/journal_profiles.json (see below) and apply specific constraints:
  • Does word count fit the limit?
  • Does it match the section's scope (for CACM)?
  • Does it satisfy required elements (e.g., IEEE Software practitioner takeaways)?
  • Is the tone right (practitioner vs. research)?

Phase 3: Produce the Review Report

Write a review report to output/<article_slug>_review.md with this structure:

# Article Review: <Title>

**Reviewed:** <date>
**Target Journal:** <journal or "Not specified">
**Article File:** <path>

---

## Summary Judgment

<2-3 sentences: overall assessment and recommended action>

**Recommended action:** Accept / Accept with minor revisions / Major revision needed / Reject and resubmit elsewhere

---

## Dimension Scores

| Dimension | Score (1–5) | Notes |
|-----------|-------------|-------|
| Contribution & Novelty | X | ... |
| Clarity & Writing | X | ... |
| Structure & Logic | X | ... |
| Technical Depth | X | ... |
| Audience Fit | X | ... |
| References & Related Work | X | ... |
| Journal Fit (if applicable) | X | ... |
| **Overall** | **X** | |

---

## Detailed Feedback

### Strengths
(What the article does well — be specific)

### Critical Issues (Must Fix)
(Problems that would likely cause rejection — numbered list)

### Suggested Improvements
(Enhancements that would strengthen the article — numbered list)

### Line-Level Notes
(Specific paragraphs/sentences with issues — quote the text, then comment)

---

## Journal Fit Assessment

<If target journal specified: detailed analysis of fit, including word count check,
required elements checklist, tone assessment, and recommendation on whether to
target this journal or a different one.>

### Recommended Journals
(If no journal specified, or if current target is wrong — list 2-3 best fits with rationale)

---

## Pre-Submission Checklist

Based on this review, the following items must be addressed before submission:

- [ ] <issue 1>
- [ ] <issue 2>
- [ ] ...

Output

• output/<article_slug>_review.md — Full review report

Journal Profile Reference

To load journal constraints, read data/journal_profiles.json in this project directory. Key profiles:

• ieee_software — 4,200 words, 15 refs, 150-word abstract, practitioner takeaways required
• cacm_practice — 10 pages, 40 refs, broad audience, practitioner-accessible
• cacm_research — 10 pages, 40 refs, innovative ideas
• ieee_tse — 12 formatted pages, rigorous research, IEEE 2-col format
• acm_queue — 3,500 words, invitation-only, practitioner-focused

Notes

• Be direct and specific — generic praise or generic criticism is not useful
• Quote actual text when identifying problems
• Distinguish between "must fix" (causes rejection) and "nice to have"
• If the article is genuinely strong, say so clearly — over-critical reviews waste the author's time
• For CACM, test whether a non-specialist could follow the article; this is a key editorial criterion
• For IEEE Software, the three practitioner takeaways must be genuinely actionable, not just restatements of the abstract