/ds-analysis-campaign

name: ds-analysis-campaign
description: Use when a quest needs one or more follow-up runs such as ablations, robustness checks, error analysis, or failure analysis after a main experiment.
skill_role: stage
license: MIT
metadata:
  author: ResearAI/DeepScientist
  version: "1.0.0"

Analysis Campaign

Use this skill when one or more follow-up runs are needed and the quest needs a coordinated evidence campaign.

This is the shared DeepScientist protocol for supplementary experiments after a durable result. Use the same route for:

• ordinary ablations / robustness / sensitivity work
• review-driven evidence gaps
• rebuttal-driven extra experiments
• writing-driven evidence gaps

For paper-facing work, treat “analysis campaign” broadly:

• not only post-hoc interpretation
• also ablations, sensitivity checks, robustness checks, efficiency or cost checks, highlight-validation runs, and limitation-boundary work beyond the main result

Do not assume a writing-facing campaign means “analysis only”.

Do not invent a separate experiment system for those cases.

Interaction discipline

• Follow the shared interaction contract injected by the system prompt.
• For ordinary active work, prefer a concise progress update once work has crossed roughly 6 tool calls with a human-meaningful delta, and do not drift beyond roughly 12 tool calls or about 8 minutes without a user-visible update.
• Hard execution rule: every terminal command in this stage must go through `bash_exec`; do not use any other terminal path for slice execution, smoke tests, Git, Python, package-manager, or file-inspection commands.
• Prefer `bash_exec` for campaign slice commands so each run has a durable session id, quest-local log folder, and later `read/list/kill` control.
• Keep ordinary subtask completions concise. When an analysis campaign or a stage-significant campaign checkpoint is complete, upgrade to a richer `artifact.interact(kind='milestone', reply_mode='threaded', ...)` report.
• That richer campaign milestone report should normally cover: which slices completed, the main takeaway, whether the claim got stronger or weaker, and the exact recommended next route.
• That richer milestone report is still normally non-blocking. If the post-campaign route is already clear, continue automatically after reporting instead of waiting for explicit acknowledgment.
• If the active communication surface is QQ and QQ milestone media is enabled in config, prefer at most one aggregated campaign summary PNG on a meaningful campaign milestone.
• That attachment should summarize the campaign as a whole; do not auto-send one image per slice.
• Treat connector-facing campaign PNGs as report charts, not draft paper figures.
• Preferred connector-chart palettes are Morandi-like and restrained:
• `sage-clay`: `#E7E1D6`, `#B7A99A`, `#7F8F84` for the default aggregated campaign summary
• `mist-stone`: `#F3EEE8`, `#D8D1C7`, `#8A9199` for conservative or uncertainty-heavy summaries
• `dust-rose`: `#F2E9E6`, `#D8C3BC`, `#B88C8C` only as a secondary accent when an extra comparison is necessary
• Connector-facing campaign chart requirements:
• one campaign-level message, not a crowded slice dashboard
• low saturation and limited color count
• clear aggregation labels and direct comparison against the main run or baseline
• prefer one summary figure that communicates the boundary change honestly
• Preferred campaign summaries are:
• point-range or bar summaries for slice-to-slice endpoint comparisons
• line plots only when the x-axis is truly ordered and comparable across slices
• small multiples instead of one rainbow figure when slices answer different questions
• If a campaign view uses continuous color, keep it sequential for ordered magnitude and diverging only for signed deltas around a meaningful center.
• Avoid rainbow / jet-like maps and decorative heatmaps when a simpler comparison plot would communicate the result better.
• Keep the same muted palette semantics across the full campaign so the same color means the same role in every slice summary.
• If a campaign figure is milestone-facing, paper-facing, or otherwise durable, open `figure-polish/SKILL.md` and complete its render-inspect-revise pass before treating the figure as final.
• If plotting in Python, reuse the fixed Morandi plotting starter from the system prompt and keep the same palette discipline across the whole campaign.
• If the runtime starts an auto-continue turn with no new user message, resume from the current campaign state and active requirements instead of replaying the previous user turn.
• Progress message templates are references only. Adapt to the actual context and vary wording so messages feel human, respectful, and non-robotic.
• If a threaded user reply arrives, interpret it relative to the latest campaign progress update before assuming the task changed completely.

Stage purpose

The analysis-campaign stage exists to test the strength, boundaries, and failure modes of a result. It preserves the core old DeepScientist analysis-experimenter discipline:

• each analysis run should correspond to one clear question
• campaign runs should stay isolated and comparable
• negative results must remain visible
• campaign-level conclusions should be aggregated explicitly

The campaign should behave like a disciplined evidence program, not an unstructured pile of extra runs.

For campaign prioritization and writing-facing slice design, read `references/campaign-design.md`. When the campaign is paper-facing and the mapping fields are not obvious, also read `references/writing-facing-slice-examples.md`.

Quick workflow

Treat this as the compressed campaign map. The authoritative slice protocol and aggregation rules remain in `Workflow`.

1. Bind the campaign to the parent run or idea and, when writing-facing, to the selected outline. 2. When the campaign is writing-facing, refresh `paper/paper_experiment_matrix.*` before freezing the sl