Engineering Response

Use this skill to turn comments into traceable revision tasks and professional English responses.

Core Stance

• Preserve each comment before responding.
• Answer every concern or mark it as unresolved.
• Map responses to manuscript evidence, a revision location, or explicit author input needed.
• Do not invent experiments, line numbers, figures, citations, analyses, or manuscript changes.
• Prefer concise, evidence-linked responses over defensive explanations.
• When a comment reveals misunderstanding, first check whether the manuscript caused it.
• Separate misreadings from real gaps. A misreading (a fallback mistaken for the main mechanism, a reused component read as added hardware) is fixed in the manuscript framing: an operating-envelope paragraph, a clearer split between primary and fallback mechanisms, a corrected word. A real gap (an unfair baseline, an unmeasured component, missing cost) needs a control or measurement when feasible, or an explicit limitation when not.
• Do not force an incomparable system into the results table to satisfy a comparison request. Discuss it qualitatively, state the differences in task, data, and hardware, and keep the controlled comparison as the main evidence. A weak baseline can be reframed as a reference configuration.

Boundaries

• Use this skill for comment triage, revision planning, rebuttal drafts, and response letters.
• Use engineering-writing for manuscript section drafting after a comment has been turned into a concrete edit.
• Use engineering-polishing for prose-only improvements.
• Use engineering-figure-table for caption, figure, or table revisions.
• Use engineering-validation before claiming a response package is complete or before using final line numbers.

When to Open Extra Files

Workflow

1. Split editor/advisor/reviewer comments into stable IDs.
2. Classify each comment by type, severity, section, and missing input.
3. Identify the real complaint, not just the surface wording.
4. Choose revise, defer with reason, or no change with reason.
5. Define prohibited over-edit.
6. Define acceptance evidence and minimum verification.
7. Decide whether the mode is rebuttal, revision response, camera-ready note, or internal revision plan.
8. If the response claims completed changes, run the diff-verification gate.
9. Draft the response only after the change or placeholder is clear. If the change is planned but not done, draft a plan or author-input note, not a final completed-change response.
10. Run completeness and factuality checks before calling the package ready.

Default Output

Response strategy summary
- Package status:
- Main risks:
- Response mode:
- Validation needed before final response:

Comment-response tracker
| ID | Original comment | Type | Severity | Real complaint | First target | Second target | Action | Evidence/change needed | Prohibited over-edit | Acceptance evidence | Verification | Line-number status | Status |

Allowed status values: `Done with evidence`, `Planned`,
`Needs author input`, `Defer with reason`, `No change with reason`, and
`Not supported`.

Draft response
[English point-by-point response]

Unverified items
- line numbers:
- experiments:
- citations:
- figures/tables:

Revision checklist
- ...