/template

name: stage1-breakdown-template
description: Base template for Stage1 reviewer-comment breakdown. Use when creating or extending conference-specific Stage1 skills (for example ICLR, ICML, NeurIPS, ACL) so shared extraction, splitting, and response-mapping logic stays consistent.

Stage 1 · Breakdown Base Template

Use this template as the shared core for all Stage1 conference variants. Conference-specific files must apply this template first, then add only necessary overrides.

Shared input assumptions

• Input is one reviewer's full text (OpenReview export, PDF copy, DOC/DOCX paste, etc.).
• Review sections may appear as headings, bullets, numbered lists, or mixed prose.
• A single bullet can contain multiple independent concerns.

Shared mandatory workflow

1. **Extract conference-defined scores (numbers only)**

• Extract every score required by the conference extension.
• Keep values numeric only (for example `6`, `4`, `3`), without scale explanations.
• If a score is missing, leave it empty rather than inventing.

2. **Preserve designated sections verbatim**

• Keep conference-defined preserved sections unchanged.
• Keep line breaks where possible.

3. **Split issue-bearing sections into atomic issues**

• Split conference-defined weakness/question sources into issue-level items.
• One atomic issue should correspond to one independent concern or request.
• Split further if one item contains multiple asks.

4. **Create response blocks (`Response1` ... `ResponseN`)**

• Each response block must include:
• `title`: generated short subtitle
• `source`: `weakness` or `question`
• `source_id`: `weaknessN` or `questionN`
• `quoted_issue`: exact verbatim text of the mapped atomic issue

5. **Apply prefix and numbering rules**

• Issues from weakness-type source sections must use `weaknessN`.
• Issues from question-type source sections must use `questionN`.
• Number `weaknessN` and `questionN` independently.

Shared splitting heuristics

Split when any of these applies:

• Multiple independent asks connected by "and", "also", "in addition", "furthermore".
• Topic shift inside one bullet (for example novelty vs experiments).
• Distinct actionable requests (for example "clarify theorem" and "add baseline").
• Different concern types in one item (for example validity + writing quality).

Do not split when sentences elaborate one single concern.

Shared output skeleton

Use this structure, with conference-specific keys provided by the extension file:

# Stage1 <CONFERENCE> Breakdown

## Scores
- <score_key_1>: <number>
- <score_key_2>: <number>

## Preserved Sections
- summary: |
  <verbatim text>
- strength: |
  <verbatim text>

## Atomic Issues
- weakness1: "<verbatim quoted issue>"
- weakness2: "<verbatim quoted issue>"
- question1: "<verbatim quoted issue>"

## Responses
### Response1
- title: <generated subtitle>
- source: weakness
- source_id: weakness1
- quoted_issue: "<same verbatim text as weakness1>"

Shared quality checklist

Before finalizing, verify:

• Preserved sections are unchanged.
• Every atomic issue appears exactly once in `Atomic Issues`.
• Every atomic issue maps to exactly one response block.
• Every `quoted_issue` is verbatim.

Conference extension contract

Conference-specific Stage1 files must define:

• Score field mapping and required score keys.
• Preserved section mapping.
• Weakness/question source section mapping.
• Output header text (`# Stage1 <CONFERENCE> Breakdown`).

Do not rewrite shared logic in conference files unless a true conference-specific exception exists.