# ieee-skills: a set of Codex skills that checks a paper the way a reviewer would, not the way a proofreader does

> ieee-skills is an unofficial collection of ten Codex skills for IEEE-style paper work. Its stated aim is not smoother sentences but the evidence chain an IEEE reviewer inspects: object, operating conditions, baseline, experiments, figures.

**CloudWave818/ieee-skills** — Codex skills for IEEE-style paper writing, polishing, reviewing, experiments, figures, LaTeX, citations, and paper reading.

- Repository: https://github.com/CloudWave818/ieee-skills
- Stars: 348 · Forks: 20
- Language: Python
- License: MIT
- Published: 2026-09-18 · Updated: 2026-09-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/cloudwave818-ieee-skills

## Reviewer objections, not proofreading, as the design target

Most writing assistants operate at the sentence: they smooth grammar and vary phrasing. ieee-skills sets a different target. The README states its concern is whether an IEEE reviewer will accept the manuscript: whether the object of study is defined, whether the operating conditions hold, whether the baseline comparison is fair, whether the experiments actually support the claims, and whether a figure is still readable after two-column scaling.

That reframing decides who this is for. It suits engineering-paper authors in areas the README names: AI, communications, control, signal processing, power electronics, embedded systems, robotics and hardware. It is less useful to someone who only wants English polishing, because polishing is one skill of ten here, not the point.

The project is explicit that it is unofficial and not an IEEE product, and it is MIT licensed. It ships as Codex skills, with a documented set of ten covering research-material triage, drafting, polishing, pre-review, experiment design, figure and table checks, reviewer response, LaTeX, citation verification and paper reading.

## The evidence chain the skills are organised around

The organising idea is a single chain the README prints directly, and every skill maps onto one link of it:

```text
对象 -> 工况/约束 -> 工程危害 -> 现有方法局限 -> 方法依据 -> 实验证据
```

Read left to right that is: object, operating conditions and constraints, engineering hazard, limitations of existing methods, rationale for the method, experimental evidence. The claim underneath is that IEEE papers fail less often on English than on a broken link in that chain, an abstract that promises a new method with no object or operating condition, a method section that lists modules without saying why they fit the system, or experiments that never prove a specific claim.

This is an opinionated model, and it is the reason the toolset is more than a prompt pack. Each skill has a narrow job tied to a link, so `ieee-writing` and `ieee-polishing` handle the wording links, `ieee-experiment` handles evidence, `ieee-figure-table` handles presentation, and `ieee-reviewer` simulates the person who checks the whole chain at once.

## SubmitCheck: running one manuscript through the whole pipeline

The flagship usage the README recommends is not calling a single skill but running a manuscript through an ordered pipeline it calls IEEE SubmitCheck:

```text
messy research materials
  -> ieee-summarize
  -> ieee-writing
  -> manuscript draft
  -> ieee-reviewer
  -> ieee-experiment
  -> ieee-figure-table
  -> ieee-citation
  -> ieee-latex
  -> reviewer-facing revision priorities
```

The stated outputs are concrete artefacts rather than edited prose: an IEEE reviewer risk report sorted into Critical, Major and Minor; a claim-evidence matrix listing what each core claim needs, what exists and what experiment is missing; a baseline fairness checklist; a figure and table first-impression audit for two-column readability and grayscale legibility; a citation-support audit; and an IEEEtran layout diagnosis. Ending on a revision priority list, rather than an instruction to keep improving, is the part that matches how a real submission decision gets made.

The `ieee-summarize` skill sits before writing and is the newest addition, introduced on 2026-08-12 per the README's update log. Its job is to turn a folder of scattered idea notes, experiment logs, code, exported AI conversations, literature summaries and screenshot notes into a structured IEEE Research Brief, so the writing skill receives organised input instead of a mess.

## How the skills are invoked

Invocation is natural-language with a skill reference, and the README gives the exact form. A reviewer simulation, for instance, is requested like this:

```text
Use $ieee-reviewer
```

followed by the instruction, such as treating the paper as an IEEE Transactions reviewer would in a pre-review pass. The same `Use $<skill>` pattern drives the others: `$ieee-summarize` to build the research brief, `$ieee-experiment` to check whether the experiments support the abstract's claims, `$ieee-figure-table` to test whether a figure survives two-column scaling, and `$ieee-response` to answer reviewer comments in a fixed shape of edit made, new evidence, and manuscript location.

Because distribution is as Codex skills rather than an installable binary with its own commands, the practical entry points are the project repository and its GitHub Pages introduction. The README's own install and quick-start sections are where to confirm the current setup steps before use; treat the skill index in the README as the authoritative list of what each of the ten does.

## A limitation the project built a guard against: accusing reviewers

The 2026-08-12 update notes that `ieee-reviewer` and `ieee-response` gained a review-quality audit that identifies vague, contradictory, unsupported or template-like reviewer comments, and the README adds an explicit caution: it does not lightly accuse a reviewer of using AI. That guard is worth calling out, because a tool that flags low-quality reviews is one prompt away from generating a confrontational, unfounded response accusing a human reviewer of machine writing, which is exactly how an author burns a revision.

The honest limitation is broader. Every output here is a model's judgement about a reviewer's likely reaction, not a reviewer's actual decision. A claim-evidence matrix can be wrong about what evidence a venue expects, and a figure audit cannot know a specific editor's tolerance. The project is a rehearsal of the review, and a rehearsal is only as good as the model running it. The `ieee-polishing` skill's AI-like prose repair is a similar double edge: the same skill that removes template phrasing is judging what counts as template phrasing.

## Against a general academic-writing assistant

The clearest alternative is a general academic-writing assistant, the kind that rewrites for clarity and grammar across any field. That tool is faster to adopt and field-agnostic, and for fixing English it is often enough.

The difference in approach is scope of judgement. A general assistant edits the text in front of it. ieee-skills refuses to stop there: it asks whether the experiments justify the claims and whether the baseline is fair, questions a grammar tool never raises because answering them needs a model of IEEE reviewing rather than a model of English. The cost of that ambition is specificity. ieee-skills is tuned for IEEE engineering venues and their conventions, so an author submitting to a venue with different norms inherits assumptions that may not apply. Pick the general assistant for language across many venues. Pick ieee-skills when the risk is an IEEE reviewer rejecting on evidence, and you want that objection surfaced before submission rather than after.

## Maintenance signals and licensing

The maintenance picture is legible from the README's own update log, which records dated changes through 2026-08-12: the new summarize skill, the figure-table drawing upgrade with an IEEE matplotlib house-style helper, and the review-quality audit. Datestamped changelog entries are a better maturity signal than any badge, because they show what actually moved and when.

Bilingual documentation is a maintenance commitment in itself. The project ships a Chinese README and an English `README_EN.md`, and the skills are described as working in both Chinese and English, which fits its evident audience of authors writing English IEEE papers from a Chinese-language working context. That dual surface has to be kept in step on every change.

MIT licensing keeps reuse simple: the ten skills can be adapted, extended or folded into a private workflow with attribution. What a reader should verify first is fit. The example deliverables in the `examples/` folder are, by the README's own statement, illustrations of the report shape rather than fabricated acceptance cases, so the right first step is to drop your own abstract, experiment table or reviewer comments into one and judge whether the output matches what your target venue actually checks.

## Conclusion

Use ieee-skills if you write IEEE engineering papers with Codex and want the reviewer's evidence objections surfaced before submission, not after: the SubmitCheck pipeline and the claim-evidence matrix are its real contribution. It is the wrong tool if you only need English polishing, since that is one skill of ten and a general assistant does it with less overhead, or if you submit to venues outside its IEEE engineering focus. Verify fit first by running one skill, such as ieee-reviewer, over your own abstract and experiment table and checking whether its risk report matches what your target venue actually enforces.

## FAQ

### Is ieee-skills an official IEEE project?

No. The README states it is unofficial and not an IEEE product, describing itself as a set of IEEE-style academic writing and review skills. It is MIT licensed.

### What does ieee-skills do that a normal polishing tool does not?

It checks the reviewer-facing evidence chain: whether the object, operating conditions, baseline fairness, experiments and figure readability hold up, rather than only improving sentences. Ordinary polishing is just one of its ten skills.

### How are the ieee-skills invoked?

Each is called in natural language with a skill reference, for example Use $ieee-reviewer followed by your instruction. The README documents the flagship IEEE SubmitCheck pipeline that chains several skills over one manuscript.

## Sources

- [CloudWave818/ieee-skills on GitHub](https://github.com/CloudWave818/ieee-skills)
- [Issues](https://github.com/CloudWave818/ieee-skills/issues)
- [License: MIT](https://github.com/CloudWave818/ieee-skills/blob/main/LICENSE)
- [README](https://github.com/CloudWave818/ieee-skills/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cloudwave818-ieee-skills