I spent months building a trading system. Then I spent more months trying to make it profitable. The numbers kept coming back red.

Same signals. Same entries. Same logic. Still losing.

Then I changed one thing. The exits.

Here's what I learned.

Win Rate Is a Vanity Metric

Everyone chases high win rates. 70%, 80%, 90%. It feels good to be right.

But being right doesn't pay the bills. Expectancy does.

Expectancy = (Win Rate × Avg Win) - (Loss Rate × Avg Loss)

A 60% win rate with 6-pip winners and 12-pip losers is a losing system. Do the math: (0.60 × 6) - (0.40 × 12) = -1.2 pips per trade.

An 18% win rate with 72-pip winners and 16-pip losers is profitable: (0.18 × 72) - (0.82 × 16) = +0.64 pips per trade.

The second system looks like a disaster if you're watching the win/loss count. It feels terrible. You lose five, six, seven in a row. But the math works.

You're Probably Cutting Winners Too Early

Most traders set a take profit target. Price hits it, trade closes, you feel smart.

But what if that trade would have run another 50 pips?

I tested fixed take profits against trailing exits across five years of data. Every market condition. COVID volatility. Trending years. Choppy sideways garbage.

Fixed TP: -2,650 pips over 5 years.

Trailing exits: +937 pips over 5 years.

Same signals. Same entries. Different exits.

The fixed TP approach cut winners at 6-7 pips on average. The trailing approach let them run to 72 pips on average.

That's a 10x difference in average winner size. It more than compensates for the lower win rate.

The Fear Tax

Why do we cut winners early? Fear.

• Fear of giving back gains
• Fear of a winner turning into a loser
• Fear of being greedy

So we grab quick profits and feel responsible. Meanwhile the trade keeps running without us.

This is the fear tax. You pay it every time you close early because you're scared. Over thousands of trades, it adds up to everything.

Letting winners run isn't greed. It's math.

Adaptive Beats Fixed

Markets change. Trending periods, ranging periods, volatile spikes, dead zones.

A system with fixed parameters has one mode. It works sometimes. It bleeds other times.

An adaptive system reads conditions and adjusts. Tight exits when things are choppy. Loose exits when trends develop. Not predicting the future—responding to the present.

Five years of data showed me: the only approach that stayed profitable across all conditions was the one that adapted.

Trust the Trail

Trailing stops feel uncomfortable. You watch profits fluctuate. You see green numbers shrink before the exit triggers.

But trailing stops do something fixed TPs can't: they let winners run while still protecting gains.

The trick is setting them loose enough to breathe. Too tight and you get stopped out on noise. Too loose and you give back too much.

Find the balance. Then trust it.

What I Actually Learned

The edge isn't in finding better entries. Everyone obsesses over entries. When to get in. The perfect setup. The confirmation signal.

Entries matter less than you think.

The edge is in how you manage the trade after you're in. How you protect capital. How you let winners develop. How you adapt to conditions.

I spent months trying to find better signals. The signals were fine. The exits were broken.

Fix your exits.

---

Data: 126,598 M15 bars, EUR/USD, Dec 2020 - Dec 2025. Fixed TP tested at 0.75x and 1.0x ATR. Trail-only used 10x ATR (effectively no fixed target).

The Problem

When you ask Claude to do multiple independent things - update several config files, research three topics, or process a batch of items - it typically handles them one by one. This works, but it's slow when the tasks don't depend on each other.

The Solution: Forced Parallelization

The skill establishes clear triggers for when to parallelize:

• User explicitly requests parallel/concurrent execution
• Task has 3+ clearly independent components
• Time/budget constraint makes sequential infeasible
• Multiple files/systems to process independently

The Forcing Function

The most interesting part is the budget constraint. If sequential execution can't meet the user's time expectations, Claude MUST parallelize or fail. No middle ground.

IF estimated_sequential > budget * 1.5:
    Parallelization is MANDATORY - just do it

How It Works

When triggered, Claude:

1. Decomposes the task using pattern detection (embarrassingly parallel, pipeline, diamond, mixed DAG)
2. Verifies independence - no shared files, no order dependencies, no shared resources
3. Dispatches multiple Task agents in a single message (they run concurrently)
4. Synthesizes results, checking for conflicts and failures

Testing It

Asked Claude to research three topics at once. Instead of sequential calls, it spawned 3 parallel agents:

Agents dispatched: 3
Architecture patterns: Agent found 5 relevant patterns
Error handling: Agent identified 3 strategies
Testing approach: Agent found 4 testing patterns

The Meta Part

This skill was designed collaboratively - I asked questions about triggers, decomposition, and synthesis, chose the most comprehensive options, and Claude built it. The whole thing took one session.

Skills are how you teach Claude new capabilities without changing its training. Just markdown files that get loaded when relevant. The parallel-execution skill is now part of my toolkit.

Loop closed.