Skip to content
Research
Skill

/light-review-rebuttal

Build auditable peer-review revision and author-response packages for Light stage 13. Use after receiving reviewer comments, a decision or meta-review; when drafting a rebuttal or response letter; when triaging major/minor revisions; when simulating a pre-submission review; or

BOOST
From plugin
light-skills
64123 skills
Install
$ npx -y skills add Light0305/Light-skills --skill light-review-rebuttal --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/light-review-rebuttal

Context preview

The summary Claude sees to decide when to auto-load this skill.

Build auditable peer-review revision and author-response packages for Light stage 13. Use after receiving reviewer comments, a decision or meta-review; when drafting a rebuttal or response letter; when triaging major/minor revisions; when simulating a pre-submission review; or

SKILL.md

light-review-rebuttal.SKILL.md
name: light-review-rebuttal
description: Build auditable peer-review revision and author-response packages for Light stage 13. Use after receiving reviewer comments, a decision or meta-review; when drafting a rebuttal or response letter; when triaging major/minor revisions; when simulating a pre-submission review; or when a rejection may require a user-chosen 13→3 novelty, 13→5 experiment, or 13→8 writing back-edge. Consumes the selected venue/context and real PDF facts, preserves reviewer wording, atomizes issues, binds claims/evidence/actions/provenance, separates PLANNED from DONE, checks current venue limits without borrowing another venue's rules, and emits the stage-13 gate without changing venue, manuscript, evidence, citations, figures, PDF, or passport automatically.

Review and rebuttal

Build a source-preserving review registry, issue matrix, revision plan, evidence/change map, response draft, commitment ledger, unknown/failure record, and delivery package. Treat prose generation as the last layer, not the first.

Read [`review-rebuttal-resource-map.md`](review-rebuttal-resource-map.md) before a real run. Read [`references/workflow_contract.md`](references/workflow_contract.md) before creating or consuming canonical JSON. Read [`references.md`](references.md) when selecting review/rule sources. The competitor evidence is [`../../docs/competitors/review-rebuttal.md`](../../docs/competitors/review-rebuttal.md).

Non-negotiable boundaries

1. Consume venue-matching's selected handoff and review context. Verify selected identity, `selected_at` timezone, `selection_basis`, user/delegated authorization, chosen candidate ID, fit/risk row, unmodified rule envelopes, source evidence path/as-of/source IDs, manuscript profile, and PDF path/hash/pages/page size/profile/compliance. Never switch venue, reorder tiers, or turn venue `UNKNOWN` into a fact. 2. Keep reviewer, editor, decision, and meta-review text verbatim in the canonical registry. Atom labels, root causes, strategies, and generated prose are interpretation layers; they never replace source text. 3. Record fetch time, source URL/type, round, reviewer ID, attachments and `AVAILABLE|UNKNOWN|UNAVAILABLE|STALE`. A 401/403/429/5xx, timeout, login, private invitation or network failure is `UNAVAILABLE`, not “no review.” 4. Never invent an experiment, analysis, citation, change, line number, reviewer identity, venue rule or result. `PLANNED` and `IN_PROGRESS` may not be phrased as completed. `DONE` requires a real change locator; completed experiment/analysis additionally requires verifiable run provenance with a matching SHA-256, not merely a local path. Before marking a response package ready, run the atom/action contract gate so source spans, reconstruction hashes, policy/ethics authorization and perspective-specific self-review are machine-checked rather than trusted. 5. Paper-writing owns manuscript claims and edits. Result-analysis owns evidence strength. Citation owns new-reference identity and claim support. Figure owns visual honesty. Typesetting owns PDF rebuild/compliance. This skill records and routes work; it does not impersonate those producers. 6. Stage 13 critical is narrow: only a routable root cause (`novelty|experiment|writing`) explicitly marked `rejection_driving=true` with a complete decision/meta-review/reviewer evidence envelope may become critical. Major labels or an overall Reject alone do not make every comment critical. 7. `reviewer_classify` and `reroute` produce advice only. Stop after presenting evidence and alternatives. Run `passport add-back-edge` only after the user chooses the root cause/back-edge. Never mutate the passport automatically.

Canonical workflow

1. Verify upstream identity

Require:

  • `light.selected_venue_handoff.v1`;
  • `light.review_rebuttal_venue_context.v1`;
  • `light.paper_claims.v1`;
  • `light.evidence_strength.v1`;
  • citation registry when any new citation is proposed;
  • the actual delivered PDF and its stage-11 facts.

Run:

python scripts/review_workflow.py \
  --spec review-input.json \
  --outdir review-delivery

If venue identity, rule envelopes, PDF hash, compliance, claims or evidence IDs do not agree, stop and repair the producer artifact. Do not “normalize” a conflict away.

The selected handoff must also retain A32's audit fields: timezone-bearing `selected_at` that is not in the future, non-empty `selection_basis`, `decision_authority=user`, coherent `selected_by/status`, delegated `user_authorization` when applicable, unchanged `fit_risk`, and a readable `source_evidence.path` whose SHA-256 matches the selected handoff and whose `as_of/source_ids` cover every sourced venue rule.

2. Capture reviews and decisions

For user-provided/private material, copy the text into `reviews[].raw_text` without correction and record `reviews[].raw_sha256` plus a timezone-aware `captured_at`; the workflow re-computes the hash and blocks future/naive capture times. For a public OpenReview forum:

python scripts/fetch_openreview.py \
  --forum <forum-id> \
  --out openreview-capture.json

If the live API is unavailable but a fixed public PeerRead/OpenReview snapshot is the declared evidence source, capture that exact commit-pinned JSON instead:

python scripts/fetch_openreview.py \
  --peerread-url <raw-fixed-commit-json-url> \
  --out peerread-capture.json

The capture is calibration/source evidence. Do not redistribute restricted reviews. If capture is unavailable, continue only with material the user provided and retain the failure record.

3. Atomize without erasing source

Create one atom for each distinct `request`, `claim`, `question`, `misunderstanding`, or `editorial` item. Each atom must contain an exact contiguous source span copied from `raw_text`, with start/end offsets, span text and SHA-256. Also create addressable coverage units and a

Read more
Ships withlight-skills

面向科研、竞赛与创新项目的 AI 全流程技能包

Get the whole plugin
Stats
647
Stars
77
Forks
Maintained
Maintenance
Python
Language
MIT
License
3mo ago
Last commit
4mo ago
Created
4h ago
Added

Repo: Light0305/Light-skills

Other skills on light-skills.

light-figure
Skill

light-figure

Light 科研主线第 9 步·图表:图服务论点(每图支撑哪条 claim、删了缺什么)+ 出版级规格(栏宽/字号/色盲安全/ 误差棒+n+显著性)+ 视觉诚实(不偷偷截 y 轴/不双…