Engineering Writing

Use this skill to write the paper's argument from the author's evidence. Most of what makes a strong engineering paper is decided before prose: which claim, which comparison, which table, which figure. This skill puts that experience first and leaves sentence craft to the model.

Hard Floor

• Never invent experiments, results, numbers, baselines, citations, datasets, or completed work. Planned work stays planned.
• If a fact that would change the scientific claim is missing, mark a concise placeholder ([RESULT NEEDED], [CITATION NEEDED], [VALUE?]) or ask, and keep writing the parts that are supported.
• Use mechanisms the author supplies. Do not add a physical or causal mechanism the author did not give.
• For an existing paper, read the live source and local project instructions before rewriting. Preserve LaTeX labels, citations, macros, and terminology.
• Final manuscript prose defaults to English. Non-English notes are source material; rebuild the argument in English rather than translating sentence by sentence.

Boundaries

• Use engineering-polishing for wording once the section logic is stable.
• Use engineering-figure-table for captions, table design, and visual roles.
• Use engineering-response for reviewer, editor, or co-author comments.
• Use engineering-paper-auditor for a pre-submission reviewer simulation.
• Use engineering-validation for builds, references, and readiness claims.

Experience First

• What to write first, and how to write while results are incomplete: writing-process.md. In short: lock one sentence, allocate the page budget, design result tables before the remaining experiments, design figures from the tables, then write Methods, Experiments, Introduction, and the Abstract last.
• What reviewers will attack, so the draft can pre-empt it: reviewer-attack-patterns.md. Check P1 (handicapped baseline), P2 (unstated operating assumption), P3 (unmeasured internal component), and P4 (added cost versus a simpler alternative) whenever drafting Introduction, Methods, or Experiments.
• How senior authors restructure a draft: revision-moves.md.

Section Notes

• Abstract: the concrete failure mode, the method core, the evaluation scope, and the strongest numbers. Write it last.
• Introduction: task difficulty, the core bottleneck, why existing routes fall short, the design requirement that follows, and the proposed formulation. Let the problem drive the story, not the tool. State the key idea at principle level; keep mechanism detail for Methods. Each contribution is a testable sentence; their number follows the independent, supported advances.
• Related Work: organize by technical axis; give the nearest neighbors the detail the positioning needs; state only differences and limitations the sources support.
• Methods: a reader path (input, intermediate object, transformation, handoff, execution and failure handling), not a module directory. Say how every decision rule is computed; label heuristics as heuristics.
• Results: ranking, key number, the interpretation the evidence supports, per-category results, and the operating boundary. Turn numbers into findings (bottleneck, stage attribution, method-family verdict, closing lesson; see "From Numbers To Findings" in revision-moves.md). Present an unmeasured mechanism as an interpretation, not a cause. Keep setup short and parameters in a table.
• Ablation: relate each major delta to a component role or failure mode, and remember that cumulative ablations depend on the order of addition.
• Robustness and failure: the stress axis, the trend, the route by which the factor affects the method, what still works, and the hardest regime.
• Conclusion: the method, the strongest evidence, a bounded takeaway, and future work derived from the observed failure regime.

Scope belongs in the prose as a concrete operating condition, not as a disclaimer. Keep it wherever a passage is read on its own (Abstract, headline result, Conclusion) and avoid repeating it in adjacent sentences. Process language ("the supplied notes show", "pending verification") and audit language ("without claiming") do not belong in manuscript prose.

Request Modes

• WRITE (draft, compose, turn notes or results into prose): return usable manuscript prose first. Add a short note after it only for placeholders, missing evidence, or claims the author should check.
• PLAN (outline, paper plan, contribution design, writing order): start from the one-sentence thesis, the section job map, the table slots, and the contribution-evidence map.
• AUDIT: hand off to engineering-paper-auditor.
• POLISH: hand off to engineering-polishing.

Follow the user's requested length and format. If the user asks for prose only, return prose only.

When to Open Extra Files

Open only what the task needs; none of these files is mandatory.