Engineering response
Skill 169884902hzl/engineering-paper-skills/skills/engineering-response
Draft, audit, or revise English response letters and revision plans for engineering papers from advisor, senior-author, reviewer, or editor comments. Use when the user provides comments, decision letters, rebuttal notes, revision drafts, or asks how to respond, what to revise, how to classify comments, how to avoid over-editing, or how to map each comment to manuscript changes.From its SKILL.md
npx -y skills add 169884902hzl/engineering-paper-skills --skill engineering-responseAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.7 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
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.
Boundaries
- Use this skill for comment triage, revision planning, rebuttal drafts, and response letters.
- Use
engineering-writingfor manuscript section drafting after a comment has been turned into a concrete edit. - Use
engineering-polishingfor prose-only improvements. - Use
engineering-figure-tablefor caption, figure, or table revisions. - Use
engineering-validationbefore claiming a response package is complete or before using final line numbers.
When to Open Extra Files
| File | Open when |
|---|---|
| references/comment-routing.md | Classifying advisor/reviewer comments and deciding which section to edit first |
| references/revision-tracker.md | Turning comments into concrete edit tasks with acceptance evidence |
| references/comment-resolution-worksheet.md | Building a full comment-to-action worksheet before editing |
| references/response-letter.md | Drafting point-by-point English responses |
| references/comment-examples.md | Handling common comments about experiments, methods, claims, captions, related work, conclusions, or abstract |
| references/tone-and-risk.md | Handling disagreement, impossible requests, missing experiments, or high-risk claims |
| references/contradictory-reviewer-strategy.md | Reviewers ask for conflicting detail, compression, experiments, or framing |
| references/partial-compliance-response.md | Authors can only partially satisfy a reviewer request |
| references/rebuttal-vs-revision-mode.md | Deciding whether the output is rebuttal, revision response, or camera-ready note |
| references/diff-verification.md | A response says a manuscript change, line number, experiment, figure, or table has already been added |
| references/examples.md | Needing concrete response tracker and reply examples |
| references/failure-modes.md | Handling false completed-change claims or impossible reviewer requests |
| ../_shared/evidence-boundary.md | A response may claim unsupported experiments, citations, or edits |
| ../_shared/citation-boundary.md | A response mentions added or corrected references |
| ../_shared/citation-verification-workflow.md | A response relies on externally discovered references that have not passed a verification gate |
| ../_shared/claim-strength.md | A response or manuscript change needs claim downgrading |
| ../_shared/list-to-argument.md | A comment batch arrives as an unordered list |
| ../_shared/output-mode.md | The user asks for response text only |
| ../_shared/terminology-ledger.md | A comment asks for renaming methods, metrics, or categories |
Workflow
- Split editor/advisor/reviewer comments into stable IDs.
- Classify each comment by type, severity, section, and missing input.
- Identify the real complaint, not just the surface wording.
- Choose
revise,defer with reason, orno change with reason. - Define prohibited over-edit.
- Define acceptance evidence and minimum verification.
- Decide whether the mode is rebuttal, revision response, camera-ready note, or internal revision plan.
- If the response claims completed changes, run the diff-verification gate.
- 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.
- 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
- ...
What ships with it: 13 files
20.1 KB alongside SKILL.md
agents/
- openai.yaml240 B
references/
- comment-examples.md2.4 KB
- comment-resolution-worksheet.md1.5 KB
- comment-routing.md1.5 KB
- contradictory-reviewer-strategy.md408 B
- diff-verification.md2.8 KB
- examples.md3.0 KB
- failure-modes.md2.7 KB
- partial-compliance-response.md380 B
- rebuttal-vs-revision-mode.md611 B
- response-letter.md937 B
- revision-tracker.md2.3 KB
- tone-and-risk.md1.4 KB