@researai/deepscientist 1.5.17 → 1.6.0

package/src/skills/optimize/references/prompt-patterns.md

@@ -0,0 +1,49 @@
+# Optimization Prompt Patterns
+
+These prompt structures are worth preserving across optimize subroutines.
+
+## Common skeleton
+
+- Introduction
+- Task description
+- Memory
+- Previous solution or previous line
+- Instructions
+- assistant_prefix when a stable response lead-in reduces drift
+- Explicit response format
+
+## Common reasoning contract
+
+- WHAT is changing?
+- WHY is the current line limited?
+- HOW should the change address the limitation?
+- KEEP UNCHANGED: what must remain stable for comparability?
+- NEXT ACTION: what concrete step follows this prompt?
+
+## Plateau pattern
+
+When the line is stagnating:
+
+- explicitly state that the current approach has plateaued
+- forbid trivial hyperparameter-only tweaks when a deeper change is needed
+- require a larger representational or architectural shift
+
+## Fusion pattern
+
+When combining lines:
+
+- identify the real strength of each source line
+- explain why those strengths are complementary
+- avoid combining everything
+- preserve the comparison surface
+
+## Debug pattern
+
+For debugging:
+
+- restate the concrete error
+- state the likely root cause
+- require the minimal targeted fix
+- preserve the original solution intent unless the bug proves the design invalid
+
+A good optimize pass changes the frontier or stops a stale line; it does not keep generating activity without moving the incumbent.

package/src/skills/paper-outline/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: paper-outline
+description: Use when creating, revising, validating, or repairing a research-paper outline before writing; turns experiment evidence into a clear paper idea, scoped claims, method abstraction, evaluation plan, analysis plan, and evidence boundaries without copying run logs into the manuscript.
+skill_role: companion
+---
+
+# Paper Outline
+
+Use this before `write` when the outline feels like a run log, result dump, engineering note, or group-meeting report instead of a paper plan.
+
+## One-Sentence Summary
+
+Keep one selected outline, but split two views:
+
+- `paper_view`: what the paper will say to readers.
+- `evidence_view`: where the exact runs, paths, rows, settings, and reproducibility details live.
+
+The paper should be faithful to the actual evidence, but it should not repeat the agent workflow.
+
+## Basic Workflow
+
+1. Read the current paper state.
+   Use `artifact.get_paper_contract(detail='full')`, `artifact.list_paper_outlines(...)`, and then `artifact.validate_academic_outline(detail='full')` if an outline exists.
+2. Find the one-sentence paper idea.
+   Ask: "What should a researcher remember after reading this paper?" This is not a metric row and not an implementation setting.
+3. Separate facts from interpretation.
+   Facts are measured results. Interpretations are the careful academic lesson supported by those facts. Unsupported claims go into "must not claim."
+4. Write or repair `paper_view`.
+   Fill the paper idea, problem/gap/method/result/limit, 1-3 scoped claims, method intuition, evaluation plan, and 4-8 useful analysis jobs.
+5. Keep engineering details out of the story.
+   Put ports, worktrees, batch shorthand, route decisions, user requests, artifact ids, exact file paths, and local commands into `evidence_view` or appendix-only reproducibility fields.
+6. Validate and compile.
+   Run `artifact.validate_academic_outline(detail='full')`. If it passes, run `artifact.compile_outline_to_writing_plan(detail='full')`.
+
+## What Good Means
+
+A good outline does three things:
+
+- It has a point: one clear claim or lesson, not a list of what the agent did.
+- It is honest: every claim is tied to durable evidence, and limits are explicit.
+- It is useful to a reader: the method and analyses teach something beyond "this setup got a number."
+
+Strong papers often start from simple code but make a useful idea legible. Residual connections are more than a code shortcut; the paper teaches how to make depth trainable. Attention is more than a module; the paper teaches how to remove a bottleneck. Do the same only when the quest evidence supports that kind of interpretation.
+
+## Mature Outline Reminder
+
+A mature paper outline is not just a section list. For `paper_type: full_empirical` and `outline_maturity: mature`, surface reminders when these are missing:
+
+- a central thesis and a central insight that are reader-facing, not just metric summaries
+- an `insight_ladder` showing how observed facts become allowed interpretations
+- 1-3 scoped claims, each with `evidence_needed` and `what_would_falsify_it`
+- a closest-neighbor / novelty boundary explaining what the paper is and is not claiming against prior or obvious alternatives
+- at least three likely reviewer objections, each mapped to planned evidence, manuscript revision, claim downgrade, or accepted limitation
+- 4-8 reviewer-facing analysis jobs beyond the headline result unless an explicit analysis-budget waiver downgrades the paper scope
+
+Analysis quantity has two reminder levels:
+
+- `paper_view.analysis_plan`: normally 4-8 planned analysis jobs for a mature empirical paper.
+- paper-facing evidence package: normally 5-10 ready experiment/analysis groups total before treating the manuscript as strong. If the user specifies a number such as 4-8 analyses, track that target visibly until completed, waived, or explicitly downgraded.
+
+## Required Shape
+
+Use this inside `artifact.submit_paper_outline(..., detailed_outline={...})`.
+
+```json
+{
+  "paper_view": {
+    "paper_type": "full_empirical",
+    "outline_maturity": "mature",
+    "working_title": "Paper-native title",
+    "narrative_strategy": {
+      "central_thesis": "The one idea the paper wants readers to remember",
+      "central_insight": "The reusable lesson suggested by the evidence",
+      "reader_takeaway": "What another researcher can learn or reuse"
+    },
+    "insight_ladder": [
+      {
+        "level": "Observed fact -> interpretation",
+        "statement": "What this fact teaches",
+        "evidence": ["main-result-id"],
+        "claim_links": ["C1"],
+        "risk": "What could make the interpretation too strong"
+      }
+    ],
+    "story_spine": {
+      "problem": "What scientific problem exists?",
+      "gap": "What prior/easy approach fails to address?",
+      "method": "What abstract method is introduced?",
+      "main_result": "What measured result supports the claim?",
+      "scope_limit": "Where the claim stops"
+    },
+    "positioning": {
+      "closest_neighbor": "The closest existing method, baseline, or obvious alternative",
+      "novelty_boundary": "Exactly what is new or reusable here",
+      "not_claiming": ["Claims this paper does not make"]
+    },
+    "core_claims": [
+      {
+        "claim_id": "C1",
+        "claim": "A scoped claim, not a section summary",
+        "scope": "Dataset/model/setting boundary",
+        "evidence_needed": ["main-result-id", "analysis-id"],
+        "what_would_falsify_it": "A result pattern that would weaken the claim"
+      }
+    ],
+    "method_abstraction": {
+      "paper_name": "Method name if stable",
+      "intuition": "Why the method should work",
+      "mechanism_steps": ["Step 1", "Step 2", "Step 3"],
+      "appendix_only_details": ["local serving topology", "exact batch/query budget"]
+    },
+    "evaluation_plan": {
+      "setting": "The scientific evaluation setting",
+      "datasets_or_benchmarks": [],
+      "baselines": [],
+      "metrics": [],
+      "controlled_factors": []
+    },
+    "analysis_plan": [
+      {
+        "analysis_id": "A1",
+        "title": "Component ablation",
+        "analysis_role": "component ablation",
+        "reviewer_question": "Does the claimed mechanism actually cause the gain?",
+        "claim_links": ["C1"],
+        "target_display": "Main-text ablation table",
+        "main_or_appendix": "main_text",
+        "failure_interpretation": "How the claim should change if this fails"
+      }
+    ],
+    "reviewer_objections": [
+      {
+        "objection": "Why a skeptical reviewer might reject or downgrade the paper",
+        "answer_route": "analysis | writing | claim_downgrade | limitation",
+        "linked_claims": ["C1"],
+        "needed_evidence": ["analysis-id"]
+      }
+    ],
+    "evidence_grounding": {
+      "observed_facts": ["Facts directly visible in durable results"],
+      "allowed_interpretations": ["Careful interpretations allowed by the facts"],
+      "must_not_claim": ["Claims the paper must avoid"],
+      "evidence_gaps": ["Missing checks or unresolved risks"]
+    }
+  },
+  "evidence_view": {
+    "claim_to_items": [],
+    "sections": [],
+    "unmapped_items": [],
+    "appendix_reproducibility": []
+  }
+}
+```
+
+The field names are machine-facing. The thinking should stay simple:
+
+- `central_thesis`: one-sentence paper idea.
+- `central_insight`: what readers learn.
+- `story_spine`: problem -> gap -> method -> result -> limit.
+- `evidence_grounding`: facts, allowed interpretations, and things not to claim.
+- `analysis_plan`: the checks a reviewer would ask for.
+
+## Analysis Plan
+
+A mature empirical paper usually needs 4-8 analysis jobs beyond the main result. Choose them because they support the story, not because of a fixed checklist.
+
+Useful analysis roles:
+
+- component ablation
+- robustness or sensitivity
+- stronger-baseline comparison
+- subgroup or case breakdown
+- failure taxonomy
+- mechanism or attribution check
+- cost, budget, or efficiency tradeoff
+- limitation or residual headroom analysis
+
+If there are fewer than 4, mark `outline_maturity: "idea_seed"` or provide `analysis_budget_waiver` with a real reason.
+
+## Bad To Good Examples
+
+Bad:
+
+- "The abstract reports dual ports and 64+64."
+
+Good:
+
+- "All methods are compared under the same evidence budget; the exact serving setup is appendix-only."
+
+Bad:
+
+- "The latest route selected outline-008 and reran opposite-port probes."
+
+Good:
+
+- "The method performs an independent evidence pass and updates a decision only when the new support satisfies preset checks."
+
+Bad:
+
+- "Section 3 reports all experiments and Section 4 reports more experiments."
+
+Good:
+
+- "The main result tests whether the method improves the target task. The analyses then ask why: whether the gain comes from the proposed component, whether it survives stronger baselines, where it fails, and what budget it costs."
+
+Bad:
+
+- "We did only two follow-up analyses because those were the latest completed runs."
+
+Good:
+
+- "The outline plans six follow-ups: ablation, stronger baseline, sensitivity, failure taxonomy, subgroup breakdown, and cost. If only two can be run, the paper is marked early/narrow instead of mature."
+
+## Validation
+
+Before handing to `write`, check:
+
+- `artifact.validate_academic_outline(detail='full')` passes.
+- The paper has one clear idea and 1-3 scoped claims.
+- If the outline is mature/full-empirical, `insight_ladder`, novelty boundary, reviewer objections, claim falsification criteria, and analysis-count reminders are present or explicitly waived.
+- The outline says what was observed, what can be interpreted, and what must not be claimed.
+- The analysis plan has 4-8 useful jobs, or a waiver.
+- Main-text experiment/analysis item ids are checked for stale duplicates that inflate evidence count.
+- `paper_view` does not mention quest, worktree, selected outline, route history, user requests, ports, or `64+64`.
+- Exact engineering details are in `evidence_view` or appendix-only fields.
+
+Read `references/outline-patterns.md` when you need more examples.

package/src/skills/paper-outline/references/outline-patterns.md

@@ -0,0 +1,87 @@
+# Paper Outline Patterns
+
+Use these examples when repairing an outline that is too close to implementation notes.
+
+## Pattern: Small Mechanism, Big Lesson
+
+Use when the method is simple but the result suggests a reusable principle.
+
+Bad outline:
+
+- "We add a guard and rerun evidence collection."
+
+Better outline:
+
+- "The paper argues that extra evidence helps only when acquisition and update are separated. Acquisition expands coverage; the guard prevents unsupported changes."
+
+Needed analyses:
+
+- guard removed
+- extra evidence without guard
+- guard with no extra evidence
+- failure cases where the guard rejects changes
+- budget sensitivity
+
+## Pattern: Targeted Repair
+
+Use when aggregate gains are modest but a diagnosed subset improves.
+
+Bad outline:
+
+- "The method improves only a small subset, so results are weak."
+
+Better outline:
+
+- "Aggregate metrics hide evidence-insufficiency pockets. The method is framed as targeted evidence repair, not a universal evaluator improvement."
+
+Needed analyses:
+
+- define the deficient subset
+- compare gains inside and outside the subset
+- show examples of repaired cases
+- show residual failures
+- compare with a stronger or simpler repair baseline
+
+## Pattern: Measurement Reframing
+
+Use when the contribution is mostly how to measure or select data/evidence.
+
+Bad outline:
+
+- "We compute many scores and report which one correlates best."
+
+Better outline:
+
+- "The paper argues that the useful notion of diversity/evidence/quality is the one that predicts downstream generalization under matched scale and quality."
+
+Needed analyses:
+
+- controlled comparison
+- correlation or ranking stability
+- failure case of old measure
+- proxy/model sensitivity
+- downstream result using the measure
+
+## Common Negative Examples
+
+Bad:
+
+- "The paper uses a selected outline, paper branch, and worktree."
+- "The abstract states dual ports, 64+64, and rerun switches."
+- "The method is the latest user requirement."
+- "The analysis plan has two runs because those are the completed ones."
+
+Better:
+
+- "The paper uses a fixed comparison budget on a held-out benchmark."
+- "Exact local serving settings are appendix reproducibility details."
+- "The method is described as an evidence-acquisition and guarded-update procedure."
+- "The analysis plan is chosen from reviewer questions: cause, robustness, stronger baselines, failure modes, and cost."
+
+## Quick Checklist
+
+- One-sentence idea: would a reader remember it?
+- Evidence: can every claim point to a result?
+- Scope: does the outline say where the claim stops?
+- Analyses: would 4-8 checks answer likely reviewer questions?
+- Language: can the text appear in a paper without explaining the agent workflow?

package/src/skills/paper-plot/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: paper-plot
+description: Use when structured numeric data, arrays, or CSV-like measurements should be turned into a publication-quality figure by adapting a bundled paper-style plotting template instead of improvising a new chart from scratch.
+skill_role: companion
+---
+
+# Paper Plot
+
+Use this skill when the job is to turn measured data into a paper-quality figure quickly and consistently.
+This companion skill is adapted from `Trae1ounG/paper-plot-skills/tree/main/plot-from-data`.
+
+## Interaction discipline
+
+- Follow the shared interaction contract injected by the system prompt.
+- If chart semantics, units, grouping, or the intended comparison are ambiguous, ask the user a focused follow-up question instead of guessing.
+- When the first durable render is ready, send a concise progress update that says which style was chosen, what data source was used, and where the output was written.
+
+## Use when
+
+- the user provides measured values, arrays, tables, or CSV-like data and wants a publication-quality figure
+- the chart can be expressed as a bar, line, scatter, or radar plot using one of the bundled styles
+- `write`, `analysis-campaign`, or `experiment` needs a first-pass paper-facing figure from structured results
+
+## Do not use when
+
+- the job is only final visual QA or last-mile refinement of an already rendered figure; use `figure-polish`
+- the figure is a disposable debug plot with no durable value
+- the figure requires a custom multi-panel composition that clearly does not fit any bundled template
+
+All bundled templates emit a `dpi=300` PNG first. If a paper-facing final export needs vector output or further visual refinement, hand the result to `figure-polish` after the first-pass render.
+
+## Available Styles
+
+| Style | Type | Script | Best for |
+|-------|------|--------|----------|
+| `bar_paired_delta` | Bar | `scripts/bar_memevolve.py` | Baseline vs. method paired comparison with explicit gain arrows |
+| `bar_grouped_hatch` | Bar | `scripts/bar_spice.py` | Multi-method comparison or ablation with highlighted primary method |
+| `line_confidence_band` | Line | `scripts/line_selfdistill.py` | Training or scaling curves with uncertainty bands |
+| `line_training_curve` | Line | `scripts/line_aime.py` | Ordered curves with reference lines or breakpoint markers |
+| `line_loss_with_inset` | Line | `scripts/line_loss_inset.py` | Curves that need a local zoomed inset |
+| `scatter_tsne_cluster` | Scatter | `scripts/scatter_tsne.py` | Clustered embedding plots with annotations |
+| `scatter_broken_axis` | Scatter | `scripts/scatter_break.py` | Scatter plots with broken-axis layout for outliers or large gaps |
+| `radar_dual_series` | Radar | `scripts/radar_dora.py` | Two-method multi-dimension comparison |
+
+## Workflow
+
+```
+1. Confirm the chart question, units, grouping, and preferred output location.
+2. Choose the closest bundled style; if two or more styles fit, ask the user or state the rationale.
+3. Read `references/<style_name>.md` for the exact layout, color, and rcParams expectations.
+4. Copy `scripts/<script>.py` into a quest-local figure workspace such as `paper/figures/scripts/<figure_id>.py`.
+5. Replace only the clearly marked data and label section in the copied script; keep the bundled template immutable.
+6. Run the copied script and inspect the rendered output.
+7. If the figure is durable or paper-facing, hand the result to `figure-polish` before treating it as final.
+```
+
+## Data Substitution Tips
+
+Each template script keeps the editable data block near the top, usually as `np.array(...)` declarations or a small dictionary.
+
+- Keep array rank and basic types stable unless you intentionally refactor the plotting logic.
+- If the number of categories changes, update width calculations, color lists, tick labels, and legend labels together.
+- Replace labels and legends directly in the copied script instead of post-editing the exported figure.
+- Keep the source data path and generated script path next to the figure output so the figure remains reproducible.
+
+## Detailed Style Parameters
+
+Read the corresponding file in `references/` for exact `rcParams`, colors, font sizes, spine settings, and tick directions before generating:
+
+- Bar: `references/bar_paired_delta.md`, `references/bar_grouped_hatch.md`
+- Line: `references/line_confidence_band.md`, `references/line_training_curve.md`, `references/line_loss_with_inset.md`
+- Scatter: `references/scatter_tsne_cluster.md`, `references/scatter_broken_axis.md`
+- Radar: `references/radar_dual_series.md`
+
+## Relationship to other skills
+
+- Use `paper-plot` for first-pass figure generation from structured data, especially for standard bar, line, scatter, and radar figure families.
+- Use `figure-polish` for final render-inspect-revise work on durable milestone or paper-facing figures.
+- In `write`, prefer this skill before inventing a new plotting stack for standard bar, line, scatter, or radar figures.

package/src/skills/paper-plot/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Paper Plot"
+  short_description: "Turn structured experiment data into publication-quality figures with bundled paper-style templates"
+  default_prompt: "Generate a publication-quality figure for my experiment data using the most suitable bundled style"

package/src/skills/paper-plot/references/bar_grouped_hatch.md

@@ -0,0 +1,96 @@
+# Style: `bar_grouped_hatch` (grouped bars with hatched primary method)
+
+**Source paper**: SPICE: Self-play in corpus environments improves reasoning  
+**Chart family**: Grouped bar chart with three bars per group and a hatched primary method  
+**Template script**: `repro/bar_spice.py`  
+**Original figure**: `image5.png`
+
+## Visual signature
+
+- **Ablation palette**: light orange `#FFB695`, mid orange `#FF7F5E`, deep red `#D00000`
+- **Comparison palette**: light gray `#D3D3D3`, mid gray `#A9A9A9`, deep red `#D00000`
+- **Hatch**: the primary method uses `//` with white hatch strokes on a dark red fill
+- **Bar borders**: every bar uses `edgecolor='white'` to keep symmetric white gaps between bars
+- **Spines**: keep only left and bottom for the open-axis look; hide top and right
+- **Grid**: y-only, very light gray, dashed, low visual weight
+- **Value labels**: show the number above every bar; highlight the primary method with bold deep red text
+- **Legend**: upper-right, framed, with the hatch pattern matching the plotted bars
+- **Overall feel**: concise paper figure with one clearly emphasized method
+
+## Key parameters
+
+```python
+# Ablation colors
+COLORS_ABL = ['#F5C5A3', '#E8845A', '#C0392B']
+
+# Comparison colors
+COLORS_CMP = ['#C8C8C8', '#707070', '#C0392B']
+
+HATCHES = ['', '', '//']            # Only the primary method uses hatching
+BEST_METHOD = 'SPICE'               # Render this method's value labels in bold red
+
+bar_total_width = 0.78              # Total width occupied by one grouped set
+grid = 'y-only'
+spine_all_visible = True
+ymax = 85
+x_positions = [0.00, 1.23, 2.46, 3.69]
+xlim = (-0.52, 4.18)
+legend_bbox = (0.992, 0.986)
+```
+
+## Typography
+
+| Element | Typeface | Size | Weight |
+| --- | --- | --- | --- |
+| Panel title | LaTeX serif / Computer Modern-like | 13.2 | Normal |
+| Legend text | LaTeX serif / Computer Modern-like | 9.2 | Normal |
+| Primary legend text | LaTeX serif / Computer Modern-like | 9.2 | Bold |
+| Value labels | LaTeX serif / Computer Modern-like | 8.7 | Normal |
+| Primary value labels | LaTeX serif / Computer Modern-like | 8.7 | Bold |
+| Axis labels / ticks | LaTeX serif / Computer Modern-like | 10.8-11.2 | Normal |
+
+```python
+plt.rcParams.update({
+    'text.usetex': True,
+    'font.family': 'serif',
+    'font.serif': ['Computer Modern Roman', 'STIX Two Text', 'DejaVu Serif'],
+    'axes.unicode_minus': False,
+})
+
+leg = ax.legend(...)
+for text in leg.get_texts():
+    if text.get_text() == BEST_METHOD:
+        text.set_fontweight('bold')
+```
+
+## Best use cases
+
+Use this style when you have:
+
+- several benchmarks on the x-axis
+- 2 to 4 methods per benchmark
+- one clearly primary method that should stand out
+- either an ablation panel or a baseline-vs-method comparison panel
+
+## Example input shape
+
+```python
+benchmarks = ['MATH500', "AIME'25", 'GPQA-Diamond', 'MMLU-Pro']
+data = {
+    'Method A': [68.2, 6.7, 26.3, 51.6],
+    'Method B': [72.6, 12.3, 31.8, 53.7],
+    'SPICE':    [78.0, 19.1, 39.4, 58.1],
+}
+best_method = 'SPICE'
+title = '(a) SPICE Ablations'
+ylabel = 'Accuracy (%)'
+xlabel = 'Benchmark'
+```
+
+## Variants
+
+- For a single-panel version, call the panel drawing helper once with one data block.
+- If you have more than three methods, reduce `bar_total_width` so the bars do not become too thin.
+- If the primary method is not the last bar, adjust the offset order rather than reworking the style logic.
+- Prefer `bbox_to_anchor` for legend micro-positioning instead of relying only on `loc='upper right'`.
+- Tune `xlim`, `x_positions`, and `legend_bbox` per panel instead of forcing both panels to share one rigid layout.

package/src/skills/paper-plot/references/bar_paired_delta.md

@@ -0,0 +1,72 @@
+# Style: `bar_paired_delta` (paired bars with explicit delta labels)
+
+**Source paper**: MemEvolve: Meta-Evolution of Agent Memory Systems  
+**Chart family**: Two-bar grouped comparison (`baseline` vs `method`)  
+**Template script**: `repro/bar_memevolve.py`  
+**Original figure**: `image1.png`
+
+## Visual signature
+
+- **Colors**: light steel blue `#A8C8E8` for baseline and navy `#1B3D6E` for the method
+- **Delta labels**: bold red percentage labels above the method bars
+- **Arrows**: solid arrows pointing from the baseline bar top to the method bar top
+- **Reference line**: a black dashed horizontal line at the baseline height spanning the pair
+- **Grid**: none
+- **Border**: all four spines visible with a moderately thick frame
+- **Title**: placed inside the axes near the upper-left corner
+- **Overall feel**: crisp paired-comparison figure that emphasizes absolute gains over baseline
+
+## Key parameters
+
+```python
+COLOR_BASELINE = '#A8C8E8'
+COLOR_METHOD   = '#1B3D6E'
+COLOR_DELTA    = '#CC2200'
+
+BAR_W = 0.32
+GAP = 0.08
+spine_linewidth = 1.4
+grid = False
+title_position = 'upper left inside axes'
+```
+
+## Typography
+
+| Element | Typeface | Size | Weight |
+| --- | --- | --- | --- |
+| Panel title | serif (Palatino / Times-like) | 11.5 | Bold |
+| Delta label | serif | 9.5 | Bold |
+| Y-axis label | serif | 10 | Normal |
+| X-axis ticks | serif | 10 | Normal |
+| Y-axis ticks | serif | default | Normal |
+
+```python
+plt.rcParams.update({
+    'font.family': 'serif',
+    'font.serif': ['Palatino', 'Times New Roman', 'DejaVu Serif'],
+})
+```
+
+## Best use cases
+
+Use this style when you have:
+
+- several groups on the x-axis
+- exactly two values per group: `baseline` and `method`
+- a need to emphasize the relative gain for each group
+
+## Example input shape
+
+```python
+groups = ['Web', 'xBench', 'TaskCraft', 'GAIA']
+baseline = [58.1, 55.2, 58.7, 59.3]
+method = [62.3, 61.2, 65.5, 61.0]
+delta = ['+7.1%', '+10.9%', '+11.9%', '+2.7%']
+title = 'OWL-Workforce'
+ylabel = 'Accuracy (Pass@1)'
+```
+
+## Known limitations
+
+- If the original figure used emoji or icon glyphs in the title, matplotlib serif fonts will not render them cleanly. Replace them with text or overlay them as images if needed.
+- This style works best when the gain range is modest. Very large deltas can make the arrow geometry look imbalanced.