# Embodied AI Paper Writer

> Professional embodied-AI paper-writing coach distilled from 63 top-conference papers (CoRL, RSS, ICRA, IROS, Science Robotics, 2022–2026). Teaches writing craft only — vocabulary, sentence patterns, paragraph flow, figure/table conventions, section-by-section construction, rhetorical pivots, appendix norms. NOT a content advisor: teaches HOW to write, not WHAT to claim. Use when the user mentions writing or reviewing any paper section (abstract, intro, method, related work, experiments, results, ablations, conclusion, limitations, appendix), titling, figure captioning, paragraph polishing, rebuttals, or submission prep. English cues: "write my abstract", "draft an intro", "title my paper", "caption this figure", "review this section", "fix my method", "polish this paragraph", "limitations section", "help with my rebuttal", "ready for submission". Chinese cues: 「帮我写摘要」「润色引言」「修改这段」「figure怎么标caption」「method怎么组织」「experiments怎么写」「conclusion怎么收尾」「rebuttal怎么写」「投稿前帮我看一下」「像不像顶会风格」.

- Skill: `openghz/embodied-ai-paper-writer` (Agent Skill, multi-file: 12 files)
- Install (CLI): `npx skillmds@latest add openghz/embodied-ai-paper-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/openghz/embodied-ai-paper-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: openghz (https://skillmd.com/u/openghz)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/openghz/embodied-ai-paper-writer

---


# Embodied-AI Paper Writer · Writing-Craft Operating Manual

> "Write so the reviewer can land cold." — distilled from 63 papers across CoRL, RSS, ICRA, IROS, Science Robotics.

## What this skill does

A coach for the *writing craft* of embodied-AI papers. It teaches:

- Title patterns, abstract moves, intro arcs.
- Method / Related Work organization.
- Experiments setup framing, results paragraph rhythm, ablation narration.
- Figure roles, caption templates, table conventions.
- Conclusion / Limitations / Future Work / Appendix.
- Section openers, pivots, connectors, contribution-restatement spiral.
- Phrasebook of openers, hedges, anti-patterns.

It does **NOT**:

- Decide which experiments to run or which baselines to compare against.
- Validate technical claims, math, or proofs.
- Suggest research directions or contributions you should make.
- Translate, copyedit grammar at the typo level, or run the LaTeX build.

If the user asks for content judgement ("is my contribution strong enough?"), redirect to a research advisor. If the user asks for spelling/grammar fixes, do them but flag that a proofreader is faster.

---

## Problem routing — load only what you need

Match the user's request to a row, then read ONLY the listed reference file(s). Do not read all references at once.

| User's request | Primary reference | Co-load when relevant |
|---|---|---|
| Title a paper, evaluate a title | `references/titles.md` | — |
| Write / fix the abstract or introduction | `references/abstract-intro-playbook.md` | `references/flow-transitions.md`, `references/language-phrasebank.md` |
| Write / organize Related Work | `references/method-relatedwork-playbook.md` (Part 1) | `references/language-phrasebank.md` |
| Write / organize the Method section | `references/method-relatedwork-playbook.md` (Part 2) | `references/figures-tables-playbook.md` (for architecture figure) |
| Set up the Experiments section | `references/experiments-results-playbook.md` | `references/figures-tables-playbook.md` |
| Write the Results section / report numbers | `references/experiments-results-playbook.md` | `references/figures-tables-playbook.md` (for table conventions) |
| Write / narrate ablations | `references/experiments-results-playbook.md` | `references/language-phrasebank.md` |
| Caption a figure or table | `references/figures-tables-playbook.md` | `references/experiments-results-playbook.md` (for statistical disclosure) |
| Pick a figure type for a role | `references/figures-tables-playbook.md` (Step 1) | — |
| Draw / build the teaser (raster, AI-generated) | `references/teaser-figure-playbook.md` | `references/image-render-invocation.md` (to call the renderer) |
| Build / export an architecture, pipeline, or conceptual diagram (vector, draw.io) | `references/drawio-figure-playbook.md` | `references/figures-tables-playbook.md` (Step 3, F2 caption) |
| Write the Conclusion | `references/closing-appendix-playbook.md` (Part 1) | `references/flow-transitions.md` (for contribution restatement) |
| Write Limitations / Future Work | `references/closing-appendix-playbook.md` (Parts 2–3) | — |
| Structure the Appendix | `references/closing-appendix-playbook.md` (Part 5) | — |
| Fix paragraph transitions / flow | `references/flow-transitions.md` | `references/language-phrasebank.md` |
| Pick a pivot word / connector | `references/flow-transitions.md` (Step 6) | `references/language-phrasebank.md` (Section H) |
| Find the right phrase for X | `references/language-phrasebank.md` | — |
| Replace weak words / fix anti-patterns | `references/language-phrasebank.md` (Sections J–K) | — |
| Review an entire draft section | Match section → primary reference; then `references/flow-transitions.md` for arc check | — |
| Critique a sentence | `references/language-phrasebank.md` + the section's primary reference | — |
| "Fix my paper" / no section specified | Default to Scenario E (whole-paper review) | Ask user to confirm scope is whole-paper, not a single section |
| Verify delta-form numbers in any section | `references/language-phrasebank.md` (Section E3) | `references/experiments-results-playbook.md` only if disclosure of N / aggregation is also questioned |

**Loading principle**: read the primary reference fully (they are 8–25 KB each — small enough to skim). Co-load only when the cross-cutting concern is in scope. The `references/research/` raw files (50–200 KB each) are for traceability only — do NOT read them in normal use.

---

## Execution rules (most important)

**When this skill activates, follow these rules. Different request types take different paths.**

### Step 0 — Terminology alignment (applies to ALL scenarios below)

Before writing or revising any content, confirm with the user the definitions and canonical spellings of key concepts, terms, and named entities that will appear in the paper. This ensures narrative consistency across sections.

```
→ List the key terms you've identified (system name, task name, method components,
  baseline labels, dataset names, domain-specific nouns).
→ For each, propose a canonical form (spelling, capitalization, hyphenation).
→ Ask the user to confirm, correct, or add missing terms.
→ Lock the confirmed terminology list — use these forms verbatim throughout.
→ If the user has already provided a terminology list or the terms are obvious
  from prior context, acknowledge and lock without re-asking.
```

This step feeds into Scenario A Step 3.5 (noun-phrase lock) and Universal Rule 2 (contribution noun phrase). It extends the same discipline to ALL named concepts, not just the system name.

### Scenario A — User wants to write a NEW section from scratch

```
Step 1: Confirm scope
  → Which section? (abstract / intro / method / related-work / experiments /
    results / ablations / conclusion / limitations / appendix)
  → What venue? (CoRL / RSS / ICRA / IROS / Science Robotics)
  → If user does not say: default to CoRL conventions and ask once.

Step 2: Gather the minimum content briefing
  → System / method name (locked spelling)?
  → 1-line value proposition?
  → Headline numerical result + named baseline?
  → 3-5 contribution bullets (rough)?
  → If user only has partial info, write what you can and mark placeholders
    with [TBD: headline-number vs Baseline X] so the user sees what's missing.

Step 3: Load the matching reference(s) from the routing table.

Step 3.5: PRE-DRAFT CHECKPOINT — confirm before committing
  → Echo back to the user, ONE line each:
    • Locked noun phrase: "{Name}, a {descriptor} that {value prop}."
      (This will repeat 5–7× verbatim across the paper — confirm wording NOW.)
    • Structural choice: hook style (B1a capability / B1b question / B1c
      recent-progress / B1d scenario / B1e pain-point), bullet count (3/4/5),
      figure-1 forward-reference position.
    • Draft ONE opening sentence (≤30 words) as a tone sample.
  → Ask: "Lock these choices and proceed? Or recalibrate?"
  → Wait for "go" / "lock" / "proceed", OR adjust per user feedback.
  → If user says "use your defaults" or "you decide", proceed and announce
    every choice in the Step 6 delivery summary.

Step 4: Draft using the reference's templates
  → Apply the section's canonical openers, structures, length budgets.
  → Use the contribution noun phrase consistently (see flow-transitions.md
    Step 4 — contribution-restatement spiral).
  → Insert figure/table forward-references where the playbook requires.

Step 5: Self-review against anti-patterns
  → Run the section's anti-pattern table.
  → Check tense (Abstract present, Conclusion past).
  → Check pivot count (one `However` per gap, not two).
  → Check noun-phrase consistency.

Step 6: Deliver with a 3-line summary of choices
  → "I opened with hook style B1c (recent-progress) because your contribution
    builds on a wave of prior work."
  → "Contribution noun phrase locked as: '{Name}, a {descriptor} that {value
    prop}'. Re-use this verbatim in Method, Experiments, Conclusion."
  → "Marked [TBD] for the X numbers you haven't filled in."
```

### Scenario B — User wants to FIX / REVIEW an existing section

```
Step 1: Identify the section type and venue.

Step 2: Load the matching primary reference + flow-transitions.md.

Step 3: Diagnose using a 4-layer scan (in this order)
  → Layer 1 — Structure: Does the section have the right moves?
    (e.g., Abstract: does it hit Frame → Gap → Contribution → Method → Results?)
  → Layer 2 — Flow: Are transitions / pivots / connectors correct?
    (e.g., is there a `However` pivot? Is the contribution noun phrase consistent?)
  → Layer 3 — Sentence-level: Are openers, hedges, and anti-pattern phrases OK?
    (cross-check against language-phrasebank.md)
  → Layer 4 — Figure/Table coupling: Are figure references forward-positioned
    with the right specificity?

Step 4: Report findings as 3–6 numbered issues
  → For each issue: cite the playbook step, quote the offending sentence,
    propose a rewrite.

Step 5: Checkpoint
  → Show the diagnosis BEFORE rewriting. Some users want only the diagnosis,
    not the rewrite. Ask: "Want me to apply these fixes inline, or stop here?"

Step 6: If user wants fixes, produce the rewritten section
  → Track-change style: keep the user's structure where possible, swap
    sentences and connectors only at the diagnosed locations.
```

### Scenario C — User asks a writing-craft question (no draft to write/fix)

```
Step 1: Match the question to the routing table.

Step 2: Read the relevant reference (or section of a reference).

Step 3: Answer concisely
  → For "how long should X be?" → give the number + the rule.
  → For "what word should I use here?" → give 2–3 options + when each fits.
  → For "is this OK?" → cite the playbook step + verdict + minimal example.

Step 4: Only escalate to drafting if user asks
  → Do not volunteer to rewrite. The user asked a question, not for a draft.
```

### Scenario D — User wants a figure caption / table caption

```
Step 1: Identify the figure type (F1 teaser / F2 architecture / F3 hardware /
  F4 tasks / F5 rollouts / F6 plot / F7 ablation / F8 failures) using
  figures-tables-playbook.md Step 1.

Step 2: Confirm the role
  → What does the figure / table show? What's the takeaway claim?
  → For F6 plots: confirm sample size + aggregation method + variability.

Step 3: Draft using the matching template
  → F1: name + value prop + scale flex + (optional) novelty + (optional) URL
       (full teaser playbook: teaser-figure-playbook.md)
  → F2: 3-4 components with action verbs + data flow
  → F3: SKUs + dimensions + control rates
  → F4: task names locked (must match across figure / table / prose)
  → F5: row labels + frame-direction hint + color decode
  → F6: what's plotted + aggregation + sample size + takeaway
  → Tables: takeaway-bold caption + Ours-row marking + bold-best + ↑↓ arrows

Step 4: Verify panel notation consistency with rest of paper
  → If paper uses `(a)/(b)`, this caption uses `(a)/(b)` — never mix.

Step 4.5: Verify caption length against figure-type budget
  → F1 teaser / F2 architecture: 3–6 sentences (rich context)
  → F3 hardware / F4 tasks: 1 sentence (label-only)
  → F5 rollouts / F7 ablation: 2 sentences (row decode + takeaway)
  → F6 plot / F8 failures: 3–4 sentences (statistical disclosure + takeaway)
  → If your draft is over budget, cut adverbs and meta-commentary first.

Step 5: Verify task names match the rest of the paper
  → For F4 tasks and result tables, names MUST be identical across figure,
    table, and prose. Flag any drift.
```

### Scenario E — User wants the whole-paper arc reviewed

```
Step 1: Ask which sections are drafted.
  → If only some sections exist, scope the review to those.

Step 2: Read each drafted section through 4 lenses
  → Arc consistency: does the 6-move arc (HOOK → GAP → APPROACH → MECHANISM
    → EVIDENCE → IMPLICATION) flow from Abstract through Conclusion?
  → Contribution-restatement spiral: same noun phrase 5–7 times, identical
    spelling, expanding clause each time?
  → Tense correctness: Abstract present, Conclusion past?
  → Figure/table coupling: are all main-text figures referenced?

Step 2.5: Run the mandatory convention sweeps (rules 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + standing rules)
  **Preferred path**: invoke the tool that automates these sweeps (resolve
  `$SKILL_DIR` per "Bundled tools — Path resolution"):
    `bash "$SKILL_DIR/tools/audit_conventions.sh" --strict`
  Run from the paper directory (with main.tex). The tool follows every
  `\input{...}` (including symlinked figure dirs via `find -L`), so it
  catches drift in `sections/*.tex`, `figures/*.tex`, `figures/*/*.tex`,
  and any other `\input`'d file. It auto-loads `audit_conventions.conf`
  from the paper dir if present (per-paper config for project-specific
  old labels, system names, scope-tag modifiers). See
  `$SKILL_DIR/tools/audit_conventions.example.conf` for the schema. Run
  `audit_conventions.sh --list` to list available sweeps.

  **Why automation matters**: manual grep over `sections/*.tex` only
  systematically misses figure/table captions in `figures/*.tex` —
  this happened to us and a reviewer would have flagged it. The tool's
  recursive `\input` discovery is the only robust way to enumerate
  everything the build pulls in.

  **Manual fallback** (if the tool is unavailable, or to spot-check a
  specific sweep):
  → Abstract self-containment + method-internal jargon: grep abstract for
    (a) `\ref`, `\autoref`, `\Cref`, `Section `, `Fig.`, `Table ` (rule 14
    — body-anchored cross-references); (b) `gate`, `commit`, `converge`,
    `epoch`, `early stopping`, `iteration` (training-loop control flow),
    plus the paper's specific hyperparameter names (e.g., `K=3`, `0.85`)
    that should live in Method, not Abstract. Flag every hit
    (abstract-intro-playbook.md Move 4 method-internal table).
  → Related-Work bucket-header audit: list every `\paragraph{...}` /
    `\subsection{...}` header in Related Work. Check each is (a) a pure noun
    phrase, (b) names the research class (not I/O, not technique, not a
    sentence with verb), (c) shares no redundant tail with other headers,
    (d) case-consistent with the other headers (rule 15).
  → Table-jargon-in-prose audit: grep Abstract / Intro / Method (conceptual
    paragraphs) / Conclusion / Limitations for `\brow\b`, `\brows\b`,
    `\bcolumn\b`, `\bcell\b`. Each hit MUST sit in a sentence that cites a
    table or figure in the same or immediately prior sentence; otherwise
    replace with `baseline` / `condition` / `setting` / `variant` (rule 16).
  → Config-dump-in-main-body audit (venue-gated, rule 17):
      (a) Confirm venue. If CoRL / RSS / NeurIPS / ICML / ICLR / Science
          Robotics → in-PDF appendix allowed. If ICRA / IROS / RA-L / T-RO →
          no in-PDF appendix.
      (b) Scan Method / Experimental Setup / Results for inline parentheticals
          listing hardware SKUs (`H200`, `A100`, `RTX`, `Jetson`), precision
          flags (`bfloat16`, `fp16`, `int8`), token caps (`new-token`,
          `context length`), learning rates (`2e-5`, `lr=`), batch sizes
          (`batch size`), control rates (`Hz`), random seeds.
      (c) For appendix-supporting venues: each hit becomes a pointer
          (`see Appendix~\ref{app:X}`); the full dense paragraph moves to
          the appendix.
      (d) For no-appendix venues: hits stay inline but compress to ONE
          tight sentence per category, or move to a `(code release at <url>)`
          pointer.
      (e) Flag any `see Appendix X` pointer in a no-appendix-venue paper —
          that's a dead reference.
  → Paired-condition-label-axis audit (rule 18): list every distinct label
    the paper uses for its main experimental conditions (e.g., `iteration row`,
    `no-prompt baseline`, `Ours`, `naked-modality`, `with X`, `without X`).
    For each comparison pair, ask: are the two labels on the same naming axis?
    If `Ours` partners with `Naked-Modality Baseline`, or `Iteration Row`
    partners with `No-Prompt Baseline`, rewrite both to share one axis
    (typically `{Adjective}-{condition} {ModelClass}` for an input-axis pair).
    Verify the canonical pair is used identically across Abstract / Intro /
    Method / Results / Conclusion (no drift to `our system` mid-paper).
  → Writing-process-archaeology audit (rule 19): scan appendix and footnotes
    for paragraphs describing dropped baselines, superseded comparators,
    internal experiment codenames (`E02`, `Phase 1`, `Attempt 001`), or
    candidate-Δ-that-was-changed explanations. These should be deleted; if
    the choice-of-baseline justification is needed, compress to ONE sentence
    in the main-body Baselines paragraph. If load-bearing, promote to a
    proper named ablation subsection + table — never an apologetic appendix
    paragraph.
  → Load-bearing-modifier audit (rule 20): identify the scope-tag modifiers
    the paper introduces in Problem Setup / Abstract / Intro (e.g.,
    `successful`, `exploratory`, `held-out`, `task-keyed`, `frozen`,
    `naked-modality`, `minimal-success`). For each, grep the rest of the
    paper for occurrences. The first definition site keeps the modifier;
    every subsequent occurrence outside a local-adjective use should drop it
    (`the exploratory trace` → `the trace`; `the held-out groups` → `the
    test groups`). Flag stacked redundancies like `successful exploratory`
    or `held-out test` when the second word already implies the first.
  → Concept-vs-instantiation audit (rule 21): identify any instantiation
    noun the paper might be leaking into conceptual framing positions
    (e.g., `demo`/`demos`/`demonstration` when the framework-level concept
    is `trace`; `controller` when the concept is `policy`; `trial` when the
    concept is `episode`). The `vocab-lock` sweep in
    `tools/audit_conventions.sh` (config field `VOCAB_LOCK_PATTERNS`) is
    the operational tool — every hit is listed for manual verification;
    the source-disclosure site (typically Experiments / Appendix dataset
    section) is expected to appear and is legitimate, but any occurrence in
    Abstract / Intro / Method / Results / Conclusion framing positions
    should be replaced with the conceptual noun.
  → New-task naming audit (rule 22): if the paper proposes a new QA task /
    benchmark / evaluation formulation, verify it has a named abbreviation
    with full expansion on first mention in Abstract, Intro, and Method.
    Grep for generic descriptors that signal an unnamed task: `\bour QA\b`,
    `\bthe QA task\b`, `\bour task\b`, `procedural[ -]?QA`, `manipulation
    reasoning task`. Each hit indicates the paper is leaning on a generic
    handle where a proper name is needed. Also verify: the abbreviation
    appears in `\keywords{...}`; the task name is consistent across
    Abstract / Intro / Method / figure & table captions / appendix; the
    `vocab-lock` config locks any legacy descriptors used in earlier
    drafts (e.g., `procedural-QA`) to prevent regression.
  → Teaser reference: grep Intro for `Figure 1` / `Fig. 1` / `\ref{fig:teaser}`
    — must appear in ¶1 or ¶2 (rule 7).
  → Limitation pairing: every `\textbf{...}` / `**...**` limitation label
    must have a `Future work could ...` sentence in the same paragraph (rule 8).
    Anti-pattern: a standalone `\textbf{Future work.}` block at section end —
    fold each direction into its source limitation paragraph instead.
  These eleven sweeps catch the high-frequency, low-effort misses that the
  4-lens scan tends to skip.

Step 3: Report the arc-level findings
  → Show the noun-phrase chain (or where it breaks).
  → Show the move map (which sections hit which moves).
  → Mark any anti-patterns at the cross-section level.

Step 4: Section-by-section diagnosis (concise)
  → 2–3 issues per section maximum.
  → Cite playbook steps for each.

Step 5: Prioritize fixes
  → "Highest leverage: lock the contribution noun phrase first — it cascades
    to 5+ places."
  → "Second: fix the missing `However` pivot in Abstract."
  → "Third: caption-level fixes."
```

---

## Universal rules (apply in every scenario)

1. **Match venue conventions**.
   - CoRL/RSS = arabic section numbers, lowercase panel labels `(a)(b)`, modal appendix 5–15 pages
   - ICRA/IROS = roman section numbers, all-caps APPENDIX, page-pressed limitations
   - Science Robotics = no section numbers, `Discussion` replaces Conclusion, Author Contributions + Model Card mandatory
   - When in doubt, ask the user.

2. **Lock the contribution noun phrase**.
   - First time you draft something with the system name, write it as `{Name}, a {descriptor}` and tell the user "this is the canonical phrase — re-use it verbatim in Method, Experiments, Conclusion."
   - When reviewing, flag any drift (`OpenVLA` vs `Openvla`, `our system` vs the actual name).
   - **Legacy-cleanup discipline when renaming a locked noun**: when the user upgrades a concept name mid-revision (e.g. `attempt-chain` → `exploratory chain` to anchor the task name's `Exploratory` root; or `\addprompt` → `DRH` after standardizing the artifact name), sweep ALL occurrences across main body, appendix, table captions, figure captions, and `math_commands.tex` (or equivalent macro file). Remove any legacy macros that expand to the old name. Reviewers who spot the legacy name in one caption assume mid-revision rot in the rest of the paper. Detection: after a rename, `grep -rn "{old_noun}"` over the whole paper tree must return zero hits in live (uncommented) prose.

3. **Tense rules**.
   - Abstract = present (`we introduce`).
   - Method = present + system-as-subject (`the model outputs ...`).
   - Experiments-as-completed = past (`we evaluated on ...`).
   - Conclusion = past (`we presented ...`).
   - When mixed, fix the tense to match the section's convention.

4. **Disclose deltas, not just absolutes**.
   - `87.3% success rate` alone = under-reported.
   - `87.3% (vs 61.4% for the strongest baseline, +25.9pp absolute / +42% relative)` = correct.
   - Never let an Abstract or Results paragraph claim a number without a comparison.

5. **One pivot per gap**.
   - Each section gets one `However` / `Yet` per gap-statement. Two `However`s in adjacent paragraphs = indecisive.
   - If the gap is bi-fold, enumerate as `(i) ... (ii) ...` within one pivot sentence.

6. **Statistical disclosure for every plot caption**.
   - Mean + variability measure + sample size. Always. Reviewers reject papers with naked plots.

7. **Forward-reference all main figures**.
   - The figure number appears in prose BEFORE the figure is described. Teaser is referenced in Intro paragraphs 1–2.

8. **Every limitation pairs with a future-work mitigation**.
   - Naked limitations read as defeatist. Each gets `Future work could ...` in the same paragraph.
   - **Anti-pattern**: a standalone `\textbf{Future work.}` paragraph at the end of the section. The default CoRL/RSS/ICRA pattern (D1 in `closing-appendix-playbook.md` Step 10) folds each direction into its source limitation paragraph. Reserve a standalone Future Work section for Science Robotics or heavy-page-budget submissions with 3+ unrelated directions that don't map onto existing limitation paragraphs.
   - **Name a mitigation mechanism as one example, not the sole path**: when the future-work clause cites a concrete mechanism, mark it as illustrative (`for example through a long-term memory`), not the mandated solution, unless it genuinely is the only option. Anti-pattern: "persistence requires tracking applied operations `through` a longer-horizon memory" (reads as the one fix). Fix: "letting the robot determine the state on its own, `for example through` a long-term memory of past interactions."

9. **Hedge first-claims and negative-existence claims with scope**.
   - Never write `We are the first to do X.` — write `To the best of our knowledge, we are the first to do X under constraint Y.`
   - The same hedge covers any **negative-existence claim about the literature** — `no benchmark isolates X`, `no prior method does Y`, `no dataset captures Z` — which is a disguised first-claim (it asserts you have surveyed the whole field). Prefix it with `To the best of our knowledge`. Anti-pattern: "no existing benchmark isolates whether models defer to feedback." Fix: "To the best of our knowledge, no existing benchmark isolates whether models defer to feedback." Detection: grep for `no existing`, `no prior`, `no benchmark`, `no method`, `none of`, `the first`, `has not been`; each must sit behind the hedge unless it cites the survey that establishes it.

10. **Cite the playbook step when the user pushes back**.
    - If the user argues against an edit, cite the specific Step from the relevant reference (e.g., "abstract-intro-playbook.md Step 5 — Move 5 mandates delta-form numbers"). Don't argue from authority — argue from observed corpus patterns.

11. **Roadmap paragraphs — one per paper, venue-gated**.
    - **Intro roadmap** (the "Section II describes ... Section III ..." paragraph): only for IEEE-style venues (ICRA / IROS / RSS) OR theory papers with unconventional section order. CoRL / NeurIPS-adjacent / Science Robotics = silent transition, NO Intro roadmap.
    - **Method-internal roadmap** (one sentence naming Method's own subsections): only when Method has 3+ subsections AND there is NO Intro roadmap already covering them. If both exist, delete the Intro one — the Method one is more useful.
    - **No double-roadmap**: a single paper has at most ONE roadmap paragraph. CoRL submission with both → flag and remove the Intro roadmap.

12. **Conflict-resolution precedence between playbooks**.
    - When two reference files disagree (e.g., Method tense rule, roadmap placement), apply in this order:
      1. SKILL.md Universal Rules (this list) win.
      2. Then the section's PRIMARY playbook (per routing table).
      3. Then cross-cutting playbooks (`flow-transitions.md`, `language-phrasebank.md`).
    - Never let a phrasebook entry override a section playbook's structural rule.

13. **Pushback escalation policy** (companion to rule 10).
    - If the user argues against an edit AND the issue is **stylistic** (word choice, sentence rhythm, "I prefer it this way"): cite once, then defer to the user. They're the author.
    - If the issue is a **convention violation** that will hurt review (missing pivot, naked plot, double-roadmap, fabricated number, tense mismatch in Abstract): cite once with a corpus-pattern reason, then if user still insists, leave it but record in the delivery summary: "Kept your phrasing per your call. Note: this departs from the corpus norm — flag to your advisor for sign-off."
    - Never argue past two exchanges. Capitulate to stylistic preferences immediately; flag-and-leave for convention violations.

14. **Abstract is self-contained — no body-anchored cross-references**.
    - The abstract appears in isolation (arXiv listings, search snippets, program books, citation indexes). `\S\ref{sec:X}`, `see Section 4`, `as in Fig. 2`, `Table 1 reports ...` render as noise or as "§ ??" to readers who haven't opened the PDF.
    - Allowed in abstract: numbers, named baselines, system name, dataset/model names, project URL in Move 6 coda.
    - Forbidden in abstract: any `\ref` / `\autoref` / `\Cref` to a section, figure, table, or equation in the body. Re-state the content; do not point at it.
    - When reviewing, grep abstract for `\ref`, `\autoref`, `\Cref`, `Section `, `Fig.`, `Table ` and flag every hit.

15. **Related-Work bucket headers carry only distinguishing information**.
    - Every bucket header is a pure noun phrase naming the **research class** (not the technique, not the I/O structure, not a complete sentence with verb).
    - Compute the longest common suffix across headers. If it's more than one word, that's the paper's universal scope — drop it from every header (it's implicit). Example: four headers ending in `... on Manipulation Traces` → drop the suffix; the section heading already establishes the domain.
    - Pick Title Case OR sentence-case and apply to **every** header in the section. Mixed case is a tell.
    - See method-relatedwork-playbook.md Step 2 for the full anti-pattern table.

16. **No table jargon (`row`, `column`, `cell`) in prose contexts**.
    - `row` / `column` / `cell` force the reader to picture a table that isn't on the page. They are legitimate only when the current paragraph just cited a specific table or figure (`Table~\ref{tab:X}` / `Fig.~\ref{fig:Y}` in the same or immediately prior sentence).
    - In **prose contexts** — Abstract, Introduction, Method conceptual paragraphs, Conclusion, Limitations — replace table jargon with experiment-condition vocabulary: `baseline`, `condition`, `setting`, `variant`, `system`. Specifically:
      - `no-prompt row` / `baseline row` → `no-prompt baseline` (drop redundant "row" — "baseline" already names the role)
      - `iteration row` / `our row` → `iteration condition` / `our system` / `{SystemName}`
      - `the X row from the modality ablation` → `the X baseline` (the table reference belongs in the cite, not the noun)
    - In **table-anchored contexts** — Results/Ablations paragraphs that just cited `Table~\ref{...}` or `Figure~\ref{...}` — `row` is fine and even preferred for precise reference (`row 8 (video + proprio)`, `the iteration row clears 0.93`).
    - When reviewing, grep prose-context files for `\brow\b`, `\brows\b`, `\bcolumn\b`, `\bcell\b`. Each hit must either sit inside a table-anchored sentence (one cite in the same or prior sentence) or be replaced.

17. **Config-parameter relegation is venue-gated**.
    - "Config-parameter dump" = hardware SKU, precision flags, token caps, batch sizes, optimizer hyperparameters, control rates, learning-rate schedules, random seeds — the stuff that doesn't change the paper's argument but is needed for reproducibility.
    - **Venues that support an in-PDF appendix (`\appendix` in the same compiled PDF)** — CoRL, RSS, NeurIPS, ICML, ICLR, AAAI, Science Robotics (Supplementary Materials), Nature Robotics (Methods + Extended Data): aggressively relegate. Main body keeps **only the pointer** (`hardware, precision, and token caps are in Appendix~\ref{app:identifiers}`); appendix carries the dense paragraph. Each main-text inline config detail you keep eats line budget that should go to argument.
    - **Venues with strict page limit and no in-PDF appendix** — IEEE RA-L (8 pages incl. refs), IEEE T-RO (limited supplementary), ICRA standard track, IROS, most IEEE Letters: cannot relegate to an in-PDF appendix because there isn't one. Either (a) keep the config compressed inline in one tight sentence, or (b) point to a separate supplementary PDF / code release (`full hyperparameters in the code release at <url>` / `see supplementary PDF`). DO NOT write `see Appendix X` if your venue does not allow `\appendix` — reviewers will flag a dead pointer.
    - **When in doubt**: read the venue's CFP for "supplementary materials" / "appendix" guidance. CoRL/RSS default = aggressive relegation. ICRA/IROS default = inline compression + code-release pointer.
    - See experiments-results-playbook.md Step 9 (hardware paragraph) and method-relatedwork-playbook.md Step 10 (appendix-relegation) for drafting guidance under each regime.

18. **Paired condition labels must share a naming axis**.
    - Whenever the paper compares two experimental conditions to each other (treatment vs. control, ablation vs. full, ours vs. baseline), the two labels must be on the **same naming axis** — so the reader sees the pair as a pair, not as two unrelated nouns.
    - **Same-axis examples (good)**:
      - `Distilled-Prompt VLM` vs. `Naked-Modality VLM` — axis = "what input the VLM gets" (`{Adjective}-{input-condition} VLM` template)
      - `With pretraining` vs. `Without pretraining` — axis = "ablation flag"
      - `Ours (RL)` vs. `Ours (BC)` — axis = "training paradigm"
      - `OpenVLA-7B` vs. `OpenVLA-13B` — axis = "scale"
    - **Mixed-axis anti-patterns (bad)**:
      - `Iteration row` vs. `No-prompt baseline` — one names a table position (`row`), the other names an experimental role (`baseline`); reader cannot tell they are the same pair
      - `Ours` vs. `Best naked-modality` — `Ours` is an authorship marker, `Best naked-modality` is a content descriptor
      - `With distilled prompt` vs. `Raw VLM` — one names the input intervention, the other names the model class
    - When reviewing, list the labels of every condition the paper compares. For each pair, ask: "Are these two labels on the same axis?" If not, rewrite both to share one axis.
    - When the label drifts (e.g., `iteration row` in §4, `iteration condition` in §3, `our system` in §1), lock to one canonical pair across the whole paper — first/last mention identical to middle mention.
    - See language-phrasebank.md Section J for axis-aligned substitution candidates.

19. **No "writing-process archaeology" in main body or appendix**.
    - "Writing-process archaeology" = paragraphs that describe how the paper's setup or claims evolved during drafting: dropped baselines, internal experiment codenames (`E02`, `Phase 1`, `Attempt 001`), candidate Δs that were superseded, justifications for why a comparator was changed from one to another.
    - These read as the author talking to themselves, not to the reader. Reviewers infer cherry-picking ("if you considered other baselines, why did you settle on these?"). Even when the choice is defensible, the archaeology paragraph creates the question.
    - **Fix**: state the baseline's positive identity in the main-body Baselines paragraph and stop there. The baseline's own definition does the anti-cherry-picking work:
      - ✓ `The Naked-Modality VLM is the strongest of {video, proprio, video+proprio} rows from the modality ablation (Table~X); the chain prompt and evaluation cap are identical to the Distilled-Prompt VLM.`
      - ✗ `... we considered several candidates and chose the most conservative one.` ← softer archaeology; still triggers "which candidates?"
      - ✗ `... originally we used X but switched to Y for fairness.` ← explicit archaeology
    - **Subtractive principle**: the cleanest defense against "you cherry-picked" is to define the baseline as the *maximum* over a named set (e.g., `strongest of {...}`, `best across modalities`). The reader sees the upper-bound construction and the question dissolves — without you having to comment on the construction.
    - No numbers from dropped baselines. No internal codenames. No "originally we used X but switched to Y" / "the most conservative of the candidates we considered" explanations — both forms trigger the same suspicion.
    - If the dropped-baseline information is load-bearing for the argument (e.g., showing robustness across baseline choices), promote it to a full ablation **with a proper subsection name and table**, not a hidden paragraph in the appendix.
    - See closing-appendix-playbook.md anti-patterns for the appendix-specific framing.

20. **Lock load-bearing modifiers, then drop them outside the definition**.
    - Many embodied-AI papers introduce a *modifier* that scopes the contribution: `successful` exploratory trace, `held-out` test groups, `task-keyed` prompt entry, `frozen` base VLM, `naked-modality` baseline, `minimal-success` action chain. Each such modifier is **load-bearing once** — at the place where the term is first defined or scoped — and then becomes wallpaper if repeated.
    - **Rule**: define the modifier exactly once (in Problem Setup / first introduction / Abstract), then drop it from every subsequent reference. The reader carries the modifier mentally; repeating it implies the author is afraid the reader will forget.
    - **Example (the `successful exploratory trace` case)**:
      - ✓ §3.1 Problem Setup: `We consider procedural reasoning over a successful exploratory manipulation trace ...` (definition; modifier carried by the reader)
      - ✓ §2/§4/§5/§7: `the exploratory trace`, `the trace`, `this trace` (modifier dropped — already in the reader's mental model)
      - ✗ §2 ¶1: `In contrast, we frame chain prediction over a successful exploratory trace ...` (redundant repetition)
      - ✗ §2 ¶2: `in a successful trace, the same first pull-failure is signal that ...` (the modifier is doing no new work here)
    - **Watch for stacked redundancy**: `the successful exploratory trace's probe segment` triple-loads `successful` + `exploratory` + `'s probe`. After the first definition, drop both `successful` and `exploratory` — `the trace's probe segment` is unambiguous.
    - **Exception**: when the modifier carries a *local* meaning (e.g., `the second, successful pull` describing the second drawer-pull attempt that succeeded after the first failed), keep it — here `successful` modifies `pull`, not the framework-level concept. The rule is about modifier-as-framework-scope-tag, not modifier-as-local-adjective.
    - When reviewing, grep prose for the load-bearing modifiers the paper introduces. Count occurrences. If a modifier appears in 3+ places outside its definition site, flag every redundant repetition.
    - This is the modifier analog of rule 2 (lock the contribution noun phrase): rule 2 keeps the *system name* identical across re-mentions; rule 20 keeps the *scope-tag modifier* in one place only.

21. **Lock the type-general noun; isolate the concrete instantiation to a source-disclosure site**.
    - For each data object the paper reasons about, pick the **most type-general noun** that names what the object *is* (a stream / a record / a measurement), not what it *came from* (a demonstration / a rollout / a replay buffer / a teleop session). Use that conceptual noun everywhere — Abstract, Intro, Method, Results, Conclusion — and reveal the concrete instantiation only at the source-disclosure site (typically Experiments setup or Appendix dataset section).
    - **Why**: instantiation-named nouns lock the contribution to one data regime. If the paper writes "iterates on demos" throughout, reviewers infer the method requires demonstrations and won't work on inference logs, replay-buffer entries, or live recordings — even when nothing in the method actually depends on the data being a demonstration. The conceptual noun keeps the contribution portable across sources.
    - **Example (the `trace` vs `demonstration` case)**:
      - ✓ Abstract: `iterates on traces with access to ground-truth chain labels`
      - ✓ Intro / Method / Results / Conclusion: `the task's traces`, `the agent reads the trace input`, `each trace`
      - ✓ Appendix `app:datasets`: `Each trace in this paper is a recorded demonstration (simulator: AdaManip rollout; real-robot: human teleoperation). The framework treats trace as a generic data type and is not demonstration-specific: alternative sources such as model inference logs or replay-buffer entries could compose unchanged.`
      - ✗ Abstract: `iterates on demos` (instantiation noun in conceptual framing position)
      - ✗ Method figure caption: `iterates on the task's demo data` (same — demo-bound framing)
    - **Other common concept/instantiation pairs in embodied-AI**:

      | Concept noun (use throughout) | Concrete instantiation (only at source-disclosure) |
      |---|---|
      | `trace` / `trajectory` | `demonstration`, `rollout`, `replay-buffer entry`, `teleop session`, `inference log` |
      | `policy` / `controller` | `transformer policy`, `diffusion policy`, `MLP controller` |
      | `episode` | `trial`, `attempt`, `run`, `recording` |
      | `observation` | `RGB frame`, `point cloud`, `joint encoder reading` |
      | `dataset` | `OpenX subset`, `BridgeData V2`, `our 60-demo collection` |
      | `reward signal` | `sparse +1`, `shaped potential`, `LLM-judged scalar` |
      | `latent` | `bott

…(truncated)