agentleFS
catalsqlb-cmdcatalsqlb-cmd/Prism-H/skills/skills-codex/rebuttal/SKILL.md

rebuttal

Skill16 starsChanged 6 months agoMITView on GitHub

Workflow 4: Submission rebuttal pipeline. Parses external reviews, enforces coverage and grounding, drafts a safe text-only rebuttal under venue limits, and manages follow-up rounds.

14 other projects use a version of this, 6 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use daily-arxiv, exp-eval and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • LambenthanSkill

    daily-arxiv

    每日从 arXiv 拉取新论文,过滤相关性,auto-ingest 高优先级论文,检测 SOTA 更新

    Also in 5 projects that use this

  • LambenthanSkill

    exp-eval

    实验判决门:Review LLM 独立评判实验结果 → 4 种判决路径 → 自动更新 claims confidence、ideas status、graph edges

    Also in 5 projects that use this

  • skyllwtSkill

    exp-pilot-eval

    Pilot result evaluation — read pilot results, apply success criteria, update idea page (pilot_result, failure_reason if failed), generate PILOT_VERDICT_REPORT. Called by /ideate Phase 5 after /exp-pilot-run.

    Also in 4 projects that use this

  • skyllwtSkill

    exp-pilot-run

    Pilot experiment execution — read Pilot Spec YAML, write pilot code, run experiment(Confirm with the user before operation and require the applicant to conduct manual inspection), return results. Called by /ideate Phase 5. Does NOT modify wiki pages or judge pass/fail.

    Also in 4 projects that use this

  • phanghonghaoSkill

    poster

    HTML/CSS A4 海报生成。从沙龙/活动 Markdown 文件生成科技风 A4 海报 PDF/PNG。Use when user mentions: poster, 海报, 海报生成, make poster, generate poster, 活动海报, 沙龙海报.

    Also in 4 projects that use this

  • +6 more from Lambenthan
  • +1 more from skyllwt

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 9 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 12 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    follow-up rounds: after the initial rebuttal

    line 17
  2. Very specific:

    run new experiments automatically unless AUTO_EXPERIMENT = true

    line 22
  3. Distinctive:

    If venue rules or limit are missing, stop and ask before drafting.

    line 58
  4. Very specific:

    If rebuttal/REBUTTAL_STATE.md exists, resume from the recorded phase

    line 72
  5. Distinctive:

    If ambiguous, pause and ask

    line 81
  6. Distinctive:

    If unresolved blockers exist, pause and present them to the user

    line 105
  7. Very specific:

    QUICK_MODE exit: if QUICK_MODE = true, stop here and present ISSUE_BOARD.md + STRATEGY_PLAN.md.

    line 107
  8. Distinctive:

    If the strategy plan identifies issues that require new evidence (sources, cases, statutes, sharper arguments):

    line 113
  9. Very specific:

    When the evidence is developed, update ISSUE_BOARD.md

    line 117
  10. Very specific:

    If the evidence is weak or inconclusive, switch to narrow_concession or future_work_boundary

    line 118
  11. Distinctive:

    When new reviewer comments arrive:

    line 177
  12. Very specific:

    If continuity helps, reuse the same reviewer agent via send_input

    line 183
  13. Distinctive:

    Never fabricate evidence, numbers, derivations, citations, or links

    line 188
  14. Distinctive:

    Never overpromise. Only promise what the user explicitly approved.

    line 189
  15. Distinctive:

    Every reviewer concern must be tracked and accounted for

    line 190

“Common” is measured: kept by at least 6 in 10 of the 12 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Workflow 4: Rebuttal

Prepare and maintain a grounded, venue-compliant rebuttal for: $ARGUMENTS

Scope

This skill is optimized for:

  • ICML-style text-only rebuttal
  • strict character limits
  • multiple reviewers
  • follow-up rounds after the initial rebuttal
  • safe drafting with no fabrication, no overpromise, and full issue coverage

This skill does not:

  • run new experiments automatically unless AUTO_EXPERIMENT = true
  • generate new theorem claims automatically
  • edit or upload a revised PDF
  • submit to OpenReview / CMT / HotCRP

Lifecycle Position

Workflow 1:   idea-discovery
Workflow 1.5: experiment-bridge
Workflow 2:   research-review (pre-submission)
Workflow 3:   paper-writing
Workflow 4:   rebuttal (post-submission external reviews)

Constants

  • VENUE = ICML — Default venue
  • RESPONSE_MODE = TEXT_ONLY — v1 default
  • REVIEWER_MODEL = gpt-5.4 — Used via a secondary Codex agent for internal stress-testing
  • MAX_INTERNAL_DRAFT_ROUNDS = 2
  • MAX_STRESS_TEST_ROUNDS = 1
  • MAX_FOLLOWUP_ROUNDS = 3
  • AUTO_EVIDENCE = false — When true, invoke /research-refine (or /statute-case-mapper, /comparative-law) to develop new evidence for reviewer concerns. Never fabricate evidence.
  • QUICK_MODE = false — When true, only run Phase 0-3 and stop after strategy
  • REBUTTAL_DIR = rebuttal/

Override: /rebuttal "paper/" — venue: NeurIPS, character limit: 5000

Required Inputs

  1. Paper source — PDF, LaTeX directory, or narrative summary
  2. Raw reviews — pasted text, markdown, or PDF with reviewer IDs
  3. Venue rules — venue name, character/word limit, text-only or revised PDF allowed
  4. Current stage — initial rebuttal or follow-up round

If venue rules or limit are missing, stop and ask before drafting.

Safety Model

Three hard gates. If any fails, do not finalize:

  1. Provenance gate — every factual statement maps to a known source
  2. Commitment gate — every promise maps to already-done / approved-for-rebuttal / future-work-only
  3. Coverage gate — every reviewer concern ends in answered / deferred intentionally / needs user input

Workflow

Phase 0: Resume or Initialize

  1. If rebuttal/REBUTTAL_STATE.md exists, resume from the recorded phase
  2. Otherwise, create rebuttal/ and initialize the output documents
  3. Load the paper, reviews, venue rules, and any user-confirmed evidence

Phase 1: Validate Inputs and Normalize Reviews

  1. Validate that venue rules are explicit
  2. Normalize all reviewer text into rebuttal/REVIEWS_RAW.md verbatim
  3. Record metadata in rebuttal/REBUTTAL_STATE.md
  4. If ambiguous, pause and ask

Phase 2: Atomize and Classify Reviewer Concerns

Create rebuttal/ISSUE_BOARD.md.

For each atomic concern, record:

  • issue_id
  • reviewer, round, raw_anchor
  • issue_type
  • severity
  • reviewer_stance
  • response_mode
  • status

Phase 3: Build Strategy Plan

Create rebuttal/STRATEGY_PLAN.md.

  1. Identify 2-4 global themes resolving shared concerns
  2. Choose a response mode per issue
  3. Build the character budget
  4. Identify blocked claims
  5. If unresolved blockers exist, pause and present them to the user

QUICK_MODE exit: if QUICK_MODE = true, stop here and present ISSUE_BOARD.md + STRATEGY_PLAN.md.

Phase 3.5: Evidence Sprint (when AUTO_EVIDENCE = true)

Skip entirely if AUTO_EVIDENCE is false.

If the strategy plan identifies issues that require new evidence (sources, cases, statutes, sharper arguments):

  1. Generate a mini evidence plan from the reviewer concerns
  2. Invoke the appropriate evidence skill, e.g. /research-refine "rebuttal/REBUTTAL_EVIDENCE_PLAN.md"
  3. When the evidence is developed, update ISSUE_BOARD.md
  4. If the evidence is weak or inconclusive, switch to narrow_concession or future_work_boundary
  5. Save the developed evidence to rebuttal/REBUTTAL_EVIDENCE.md. Never fabricate evidence.

Phase 4: Draft Initial Rebuttal

Create rebuttal/REBUTTAL_DRAFT_v1.md.

Structure:

  1. Short opener
  2. Per-reviewer numbered responses
  3. Short closing

Also generate rebuttal/PASTE_READY.txt with exact character count.

Phase 5: Safety Validation

Run all lints:

  1. Coverage
  2. Provenance
  3. Commitment
  4. Tone
  5. Consistency
  6. Limit

Phase 6: Stress Test

spawn_agent:
  model: gpt-5.4
  reasoning_effort: xhigh
  message: |
    Stress-test this rebuttal draft:
    [raw reviews + issue board + draft + venue rules]

    1. Unanswered or weakly answered concerns?
    2. Unsupported factual statements?
    3. Risky or unapproved promises?
    4. Tone problems?
    5. Paragraph most likely to backfire with a meta-reviewer?
    6. Minimal grounded fixes only. Do not invent evidence.

    Verdict: safe to submit / needs revision

Save the full response to rebuttal/MCP_STRESS_TEST.md. If a hard safety blocker remains, revise before finalizing.

Phase 7: Finalize — Two Versions

Produce:

  1. rebuttal/PASTE_READY.txt — strict version, ready to paste
  2. rebuttal/REBUTTAL_DRAFT_rich.md — extended version with optional sections marked
  3. Update rebuttal/REBUTTAL_STATE.md
  4. Present the remaining risks and any lines needing manual approval

Phase 8: Follow-Up Rounds

When new reviewer comments arrive:

  1. Append them to rebuttal/FOLLOWUP_LOG.md
  2. Link to existing issues or create new ones
  3. Draft the delta reply only
  4. Re-run safety lints
  5. If continuity helps, reuse the same reviewer agent via send_input
  6. Escalate technically, not rhetorically

Key Rules

  • Never fabricate evidence, numbers, derivations, citations, or links
  • Never overpromise. Only promise what the user explicitly approved.
  • Every reviewer concern must be tracked and accounted for
  • Preserve raw records
  • Shared concerns go in the opener; reviewer-specific details go in the per-reviewer sections
  • Answer friendly reviewers too
  • Respect the hard character limit

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.