benchmark
The benchmark skill defines comparison metrics and extracts baseline values from the current implementation during Phase 3 of an experiment workflow. It reads metric outputs from the current analysis notebook, identifies any missing computations by setting a `needs_computation` flag, and appends a structured Phase 3 entry to the experiment's log.json file so downstream evaluation phases can reference and compare against established baseline performance.
git clone --depth 1 https://github.com/Upsonic/Upsonic /tmp/benchmark && cp -r /tmp/benchmark/src/upsonic/prebuilt/applied_scientist/template/skills/benchmark ~/.claude/skills/benchmarkSKILL.md
# Benchmark Skill
## Purpose
Define the comparison metrics and extract baseline values from the current implementation. Record them as a structured JSON entry so downstream phases and final evaluation can read them directly.
## When to Use
Phase 3 — after both current analysis and research analysis are complete.
## Input
| Parameter | Type | Description |
|-----------|------|-------------|
| experiment_path | path | `experiments/{research_name}/` |
## Actions
1. **Define comparison metrics:**
- Include ALL metrics already used in `current.ipynb`.
- Add any additional metrics that are relevant for the new method.
- For classification: accuracy, precision, recall, F1, AUC-ROC (as applicable).
- For regression: MSE, RMSE, MAE, R² (as applicable).
- Include training time if measurable.
2. **Extract baseline values:**
- Read metric values from `current.ipynb` output cells.
- If a metric is not computed in the notebook, record it as `null` and set `"needs_computation": true` — both notebooks must then compute it.
3. **Append a Phase 3 entry to `{experiment_path}/log.json`** under `phases`:
```json
{
"name": "Phase 3: Benchmark",
"completed_at": "2026-04-17T10:45:00Z",
"metrics": [
{
"name": "accuracy",
"description": "Fraction of correctly classified samples.",
"higher_is_better": true,
"baseline": 0.8726,
"needs_computation": false
},
{
"name": "f1",
"description": "F1 score (binary, positive class).",
"higher_is_better": true,
"baseline": 0.7277,
"needs_computation": false
},
{
"name": "roc_auc",
"description": "Area under the ROC curve.",
"higher_is_better": true,
"baseline": 0.9274,
"needs_computation": false
},
{
"name": "training_time_seconds",
"description": "Wall-clock training time.",
"higher_is_better": false,
"baseline": null,
"needs_computation": true
}
],
"notes": "training_time_seconds must be added to both notebooks for a fair comparison."
}
```
Do not overwrite earlier entries; append to the `phases` array.
## Output
- `{experiment_path}/log.json` — updated with Phase 3 benchmark entry
- Clear list (in `metrics`) of what the new implementation must computePerform structured code reviews with actionable feedback. Use when a user asks to review code, check code quality, find bugs, audit security, improve performance, or assess maintainability. Trigger when user says things like "review this code", "check for bugs", "is this code secure", "any issues with this", "code quality check", or pastes code asking for feedback. Also trigger for pull request reviews and pre-merge code checks. Do NOT trigger for writing new code from scratch, refactoring requests without review context, or general programming questions.
Analyze, explore, clean, and visualize datasets with statistical rigor. Use when user asks to analyze data, find patterns, compute statistics, create visualizations, clean messy data, or explore a dataset. Trigger when user says things like "analyze this data", "what trends do you see", "find patterns in", "create a chart", "clean this dataset", "run statistics on", "what does this data tell us", or provides CSV/Excel/JSON data for exploration. Also trigger for A/B test analysis, cohort analysis, and data quality assessments. Do NOT trigger for simple data format conversions, database query writing without analysis, or ETL pipeline design.