Install
$ agentstack add skill-openghz-embodied-ai-paper-writer-embodied-ai-paper-writer ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
About
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 )`
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` partn
…
## Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- **Author:** [OpenGHz](https://github.com/OpenGHz)
- **Source:** [OpenGHz/embodied-ai-paper-writer](https://github.com/OpenGHz/embodied-ai-paper-writer)
- **License:** MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.