agentleFS
davidromeodavidromeo/tradeblocks-skills/skills/compare/SKILL.md

compare

Skill3 starsChanged 47 days agoMITView on GitHub

Performance comparison for trading strategies. Compare backtest vs actual results, strategy vs strategy metrics, block vs block, or period vs period performance. Use when exploring differences between theoretical and live execution, understanding how two strategies relate, or analyzing performance across time periods.

16 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use evaluate, create and 6 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • NVIDIASkill

    evaluate

    Scores existing Sports Intelligence AVLM inference outputs with avlm/evals: MCQ accuracy (run_mcq_eval.sh, INFERENCE_DIR), open-ended LLM-as-judge scores (needs CLIENT_API_KEY for the configured judge endpoint), tennis category breakdowns, run comparisons, chance-level sanity checks and triage of mcq_results.json or llm_judge_results.json. Use when the user asks to score, evaluate, benchmark or compare predictions.jsonl from inference runs, or to explain a suspicious accuracy. Not for running inference, training, quantization, data preparation, or third-party API model inference: never open, list or run anything under avlm/evals/inference_3rdparty, including when the user asks for it; it is excluded from the release.

    Also in 3 projects that use this

  • MicrosoftSkill

    create

    Also in 3 projects that use this

  • AnthropicSkill

    analyze

    Answer data questions -- from quick lookups to full analyses. Use when looking up a single metric, investigating what's driving a trend or drop, comparing segments over time, or preparing a formal data report for stakeholders.

    Also in 3 projects that use this

  • OpenAISkill

    audit

    Audit or critique a product flow, journey, workflow, funnel, onboarding path, checkout path, settings path, screen, or multi-step product experience by capturing screenshots first, then reporting UX, design, and accessibility findings inline from that evidence. Use Figma only when the user explicitly asks for a board. Use when the user asks to audit, review, critique, inspect, assess, analyze, evaluate, or give feedback on a product experience.

    Also in 6 projects that use this

  • MicrosoftSkill

    report

    Turn an exploration (threads, findings, charts) into a single Markdown report — note, blog post, executive summary, KPI dashboard, slide brief, or multi-section analytical report, with embedded charts.

    Also in 3 projects that use this

  • AnthropicSkill

    start

    Set up your bio-research environment and explore available tools. Use when first getting oriented with the plugin, checking which literature, drug-discovery, or visualization MCP servers are connected, or surveying available analysis skills before starting a new project.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 2 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 14 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Ask the user what they want to compare:

    line 23
  2. Distinctive:

    Ask: "What would you like to compare?"

    line 32
  3. Very specific:

    Use compare_backtest_to_actual to explore how theoretical performance compares to live execution.

    line 36
  4. Very specific:

    Start with groupBy: "strategy" and scaling: "perContract" for an overview

    line 58
  5. Very specific:

    Use outliersOnly: true to find the worst slippage trades

    line 60
  6. Very specific:

    Use detailLevel: "trades" for field-by-field comparison on outliers

    line 61
  7. Very specific:

    Use compare_blocks for a quick overview, then block_diff when blocks share strategies and you want to understand what changed.

    line 124
  8. Very specific:

    Use get_period_returns with period type and optional date filters.

    line 130

“Common” is measured: kept by at least 6 in 10 of the 14 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Performance Comparison

Explore differences between strategies, execution modes, or time periods.

Prerequisites

  • TradeBlocks MCP server running
  • At least one block with trade data loaded
  • For backtest vs actual: Both trade log and reporting log for the same strategy
  • For strategy vs strategy: Multi-strategy block or two blocks
  • For block vs block: Two or more blocks

Process

Step 1: Identify Comparison Type

Ask the user what they want to compare:

TypeUse CasePrimary Tool
Backtest vs ActualExplore theoretical vs live executioncompare_backtest_to_actual
Strategy vs Strategy (same block)Compare strategies within a portfolioget_strategy_comparison
Block vs BlockCompare separate portfolios side-by-sidecompare_blocks / block_diff
Period vs PeriodAnalyze same strategy across time rangesget_period_returns

Ask: "What would you like to compare?"

Step 2a: Backtest vs Actual Comparison

Use compare_backtest_to_actual to explore how theoretical performance compares to live execution.

Key parameters:

  • blockId: Block folder name
  • scaling: How to compare P&L fairly (see below)
  • strategy: Optional filter to specific strategy
  • dateRange: Optional date filter
  • matchedOnly: Only include trades where both backtest and actual exist
  • groupBy: Group results by "none", "strategy", "date", "week", or "month"
  • detailLevel: "summary" (aggregate by date+strategy) or "trades" (individual trade comparison with field-by-field differences)
  • outliersOnly: Only return high-slippage outliers (z-score threshold)
  • outliersThreshold: Z-score threshold for outlier detection (default: 2)

Scaling modes (see references/scaling.md):

ModeWhat It DoesUse When
rawShows P&L as-isContract sizes match between backtest and actual
perContractDivides each P&L by contract countComparing per-lot performance regardless of size
toReportedScales backtest DOWN to match actual contract countBacktest uses more contracts than actual

Recommended approach:

  1. Start with groupBy: "strategy" and scaling: "perContract" for an overview
  2. Drill into specific strategies with groupBy: "month" to spot trends
  3. Use outliersOnly: true to find the worst slippage trades
  4. Use detailLevel: "trades" for field-by-field comparison on outliers

Tool returns:

  • Per-date/strategy comparison with backtest vs actual P&L
  • Slippage calculation (actual minus backtest)
  • Match status (whether both sides exist for each date)
  • Summary totals and average slippage percentage
  • Outlier detection with z-scores

Present findings from the data:

  • Total backtest P&L vs Total actual P&L (at selected scaling)
  • Matched trade count (how many dates have both)
  • Average slippage (percentage deviation from backtest)
  • Unmatched trades (missed fills or extra trades)
  • Outliers (trades with unusually high slippage)

Step 2b: Strategy vs Strategy Comparison (Same Block)

For comparing strategies within the same block, use get_strategy_comparison:

Key parameters:

  • blockId: Block folder name
  • sortBy: "netPl", "winRate", "trades", "profitFactor", "name"
  • sortOrder: "asc" or "desc"
  • minTrades: Minimum trades per strategy to include
  • startDate / endDate: Optional date filters

Tool returns per strategy:

  • Trade count, win rate, net P&L
  • Average win, average loss
  • Profit factor

Present as a ranked table:

StrategyTradesWin RateNet P&LProfit Factor
...............

For deeper comparison between two specific strategies, also run:

  • get_correlation_matrix to understand how they move together
  • get_statistics on each (with strategy filter) for full metric suites

Correlation context:

  • Very low (<0.2): Strategies move independently
  • Low (0.2-0.4): Some independence
  • Moderate (0.4-0.6): Shared behavior
  • High (>0.6): Similar movements, less diversification

Step 2c: Block vs Block Comparison

For comparing separate portfolio blocks:

Option 1: Side-by-side metrics via compare_blocks:

  • blockIds: Array of block IDs (max 5)
  • metrics: Optional filter to specific metrics (e.g., ["sharpeRatio", "maxDrawdown", "profitFactor"])
  • sortBy: Sort by any metric

Option 2: Strategy overlap analysis via block_diff:

  • blockIdA: First block (baseline)
  • blockIdB: Second block (comparison target)
  • Shows shared vs unique strategies between blocks
  • Calculates performance deltas for shared strategies

Use compare_blocks for a quick overview, then block_diff when blocks share strategies and you want to understand what changed.

Step 2d: Period vs Period Comparison

For analyzing performance across time:

Use get_period_returns with period type and optional date filters.

Key parameters:

  • period: "monthly", "weekly", or "daily"
  • dateRange: Optional filter to specific time range
  • normalizeTo1Lot: Normalize for fair comparison across different position sizes
  • strategy: Optional strategy filter

Present period breakdown:

  • Performance by month/quarter/year
  • Best and worst periods
  • Trends or regime changes

Questions to explore:

  • "How does recent performance compare to earlier results?"
  • "Are there periods that stand out?"
  • "Does performance vary by time of year?"

Step 3: Present Findings

Synthesize the data into what stands out:

Comparison Summary:

  • What was compared: [backtest vs actual / strategy A vs B / block X vs Y / period X vs Y]
  • Key observation: [Most notable difference from the data]
  • Magnitude: [Size of the divergence]

What the data shows:

  • [Notable finding 1 from tool output]
  • [Notable finding 2 from tool output]
  • [Any patterns or anomalies]

Context for interpretation:

  • [Possible explanations for observed differences]
  • [Factors that may affect the comparison]

Present these as observations from the historical data. The user can decide what meaning to draw from the findings.

Interpretation Reference

For detailed explanation of scaling modes, see references/scaling.md.

Related Skills

After comparison analysis:

  • /tradeblocks:health-check - Deep dive into either strategy
  • /tradeblocks:portfolio - Explore correlation and diversification
  • /tradeblocks:wfa - Test parameter robustness

Notes

  • Backtest results typically look better than live (ideal fills, no slippage)
  • Some degradation from backtest to live is expected
  • High correlation between strategies means they may draw down together
  • Short comparison periods have more noise than signal
  • Scaling mode choice affects what story the data tells

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.