claude-trading-skills from install to live trading — a 74-skill trading toolbox for Claude

A bundle of 74 Claude skills and 11 workflows. Its feedback workflow demands a closed trade — so I fed it a real execution journal from a weltiq paper slot and

Done when: you have run the crypto-regime-analyzer skill yourself and hold the two crypto-regime report files it scores 0–100.

1. What this is

tradermonty/claude-trading-skills is a bundle of Claude skills. Not a Python library, not an MCP server — a repository of 74 SKILL.md files and the scripts that come with them. You either copy skill folders into Claude Code or upload .skill files to the Skills tab in the web app. The goal the author states in the README is to structure the trading process, "not to hand buy/sell decisions to an AI".

"This is a research, journaling and risk-review aid, not an automated trading system. It does not place orders, does not provide a signal service, and does not run hidden scheduled jobs." — from the README (emphasis original)

The back half is already designed

One thing sets it apart from the other decision tools in this series — the back half of the feedback loop is already designed. Of the 11 YAML files in workflows/, trade-memory-loop opens like this.

when_to_run: >-
  Every time a position is closed (full or partial exit). ...
when_not_to_run: >-
  Do not run before a position is closed ...
required_skills: [trader-memory-core, signal-postmortem]

It is a workflow that says run me every time a trade closes — and this tool places no orders. Today the user writes that "closed trade" in by hand.

What is empty is not a defect in this tool, it is a slot. And that slot is the same shape as weltiq's exit. Section 5 is the record of pouring an execution journal into it and counting where it stops.

2. Install

All you need is Python (this article ran on 3.14 — outside the range the repository states, and it worked) and zero money. The skills used here need no key; FMP, FINVIZ Elite and Alpaca are all optional. The one verified path is to clone the repository and copy the skill folder into ~/.claude/skills/. There is no build step.

git clone --depth 1 https://github.com/tradermonty/claude-trading-skills
cd claude-trading-skills
cp -r skills/crypto-regime-analyzer ~/.claude/skills/
python3 -m pip install -r skills/crypto-regime-analyzer/requirements.txt

Install

One clone and you are done. Look at the three numbers in the middle — 74 skills, 11 workflows, 74 .skill bundles for the web app. The 49M at the bottom is the size of the whole repository. The skill used in this article has exactly one dependency line: requests.

The clone took 2.977 seconds. Each skill needs something different and that is written down in skills-index.yaml, so you do not have to install all 74.

Where you get stuck

3. First result

There is a separate skill whose job is to tell you which of the 74 to use — trading-skills-navigator. I ran that first as the smallest example, asking in Korean — "I want to trade Bitcoin and make a profit while keeping losses within −2%. Which skill should I use?":

비트코인을 거래해서 손실은 −2% 안에서 막고 수익을 내고 싶어. 어느 스킬을 써야 해?

Navigator fallback

I asked about Bitcoin and back came a US equity market-breadth workflow (market-regime-daily). Look at status: "fallback" and selected_persona: null in the middle — the router could not find a match for this question and handed back the beginner default.

This is not success yet. This router does not know crypto questions. Rewording it as "crypto bitcoin trading with strict drawdown limit" produced the same fallback. What it does do is say so: the output reads "No persona matched; used the universal beginner fallback." and tells you to rephrase, which beats confidently producing a wrong answer.

So instead of the router I showed the whole catalogue to the tool itself and made it pick. I pasted in just the 74 names and the description each skill wrote about itself, said "pick only the skills whose own description says they fit this request", and it landed on crypto-regime-analyzer.

Running crypto-regime-analyzer

The run log is on top and the generated report below. Two places to look — the stretch in the middle where rate limited (429); backing off 60s... appears three times (which is why it took 5 minutes 48.88 seconds), and the BTC Dominance Regime | 15% | — | NO DATA row in the table below.

This is what success looks like. You get a 0–100 score with the breakdown of six components, and it writes down which components are missing — dominance only switches on once 31 days have accumulated locally, because the free tier gives only the current value, and until then its weight is redistributed and the row reads NO DATA. Python produces the score; the LLM puts it into words. That distinction is the subject of section 4.

There is no dashboard — it is a thing you call

There is no dashboard, no web UI and no TUI; terminal output is all there is. No server to start, no port. All you see is text coming back in the chat and the reports the skill drops as files. The documentation site has a Quality Dashboard menu item, but that is a catalogue-quality metrics page, not a trading screen. The one screen with pictures is that documentation site, and it just opens in a browser.

The documentation site

https://tradermonty.github.io/claude-trading-skills/ — a catalogue showing all 74 skills by category. Look at the "Which Skill Should I Use?" list at the bottom right — the entries are written in ordinary language, and that same language is what summons the skill.

Move the whole skill folder into ~/.claude/skills/ (leave scripts/ out and it cannot produce a score), and when you call it, mix in the words from the description: at the top of the skill and phrase it as a question — something like "is crypto risk-on or risk-off right now?". You know it fired when crypto_regime.json and crypto_regime.md land. No files, or an answer back in 3 seconds, means the script never ran.

This article did not rely on automatic skill invocation — I ran the chosen skill by sending its SKILL.md verbatim. Claude Code's own skill-indicator UI was not captured — unverified.

4. The best way to use it — where the script ends and the LLM begins

The best way to use this tool is to know where that boundary is. The repository says the navigator is deterministic — "a Python recommender consumes metadata and SKILL.md merely puts the result into words" — and the other skills are shaped the same way, so asking the same question several times shows you which layer wobbles. I ran crypto-regime-analyzer three times from an empty cache.

The raw inputs keep moving and the score is 81.8 all three times. Funding fell from 18.6% annualized to 11.2% and the component score stayed at 55, because scores are assigned by band — design, not a defect. But it means that is the resolution of the score, so do not read 81.8 appearing three times as "the market didn't change".

On the same day, though, the same mission asked twice came back with different answers. The two were 2 hours 41 minutes apart, and in between the regime score was the same 81.8 RISK_ON.

The biggest change is retest. The second's reasoning was that "price is near recent highs, so an immediate buy risks short-term exhaustion" — but at the time of the first decision the price was also just below the 72-hour high. The ruler for the planned loss changed too, and the mission asked for the second one — the first decision was measuring something the mission never asked about.

So in practice, use it like this. Take the score as given, and ask a second time for any trading rule expressed as a number. If the two answers agree, the rule came from market data; if they diverge, it came from prose. Every tool with an LLM in it works that way — here the lower layer is deterministic, so you can see the boundary.

Where it meets weltiq — the fixed-quantity trap

I put the first rule onto a weltiq paper account as written, and the first attempt was blocked.

Entry blocked

The strategy container finished warm-up and went straight to entry_blocked. Look at "reason": "insufficient_balance" and the price below it — the fixed quantity of 0.116 BTC that the tool settled on cannot be bought at the current price with 10,000 USDT of capital.

The tool sized 0.116 BTC against the price at the time of the first decision (85,350), which was 9,900 USDT then. But at execution time the price was 86,026, and weltiq checks with a 1% balance-guard margin applied just before the order — 0.116 × 86,026.32 × 1.01 = 10,078.84 > capital of 10,000. I changed none of the tool's numbers, raised capital to 11,000, resubmitted, and it went in. A tool that sizes by fixed quantity produces a quantity that overruns capital once the price moves between decision and execution. There is no way to make the tool speak in "% of capital".

Everything I ran, at a glance

5. Moving it to weltiq — an integration experiment

This tool's conclusion is an entry, a stop, a target and a quantity, as numbers — not an order. You rewrite those numbers as a weltiq rule document, and the success path is five steps.

Three lines of setup — sign up for weltiq ({{CTA_URL}}) → My page → issue a key under connection management.

1. Turn the tool's numbers into a rule document — "buy on reaching above 85,350 → stop 83,800 · target 88,200".
2. Attach a paragraph of reasoning in your own words.
3. Create the strategy container with stop conditions attached — stop at 200 cumulative loss (−2% of capital), auto-close after 6 hours.
4. It fills on the next confirmed candle. The rule holds even with you and the tool switched off.
5. Download the execution record and hand it back to the tool.

Step 3 cannot be skipped — leave it out and both stop_max_loss and stop_after_hours come back Field required. That gate is the boundary of autonomy. However many times the tool re-decides on its own, the door from that result into a resident execution needs a limit a human wrote. (There is a second gate that demands the reasoning; I could not trigger it this time — unverified.)

5-1. Pouring a journal into the empty input

The trade-memory-loop from section 1 is the most valuable part of this tool and at the same time the least usable part, because its input is a closed trade and it places no orders. So I poured an execution journal straight into that slot — the workflow YAML and four SKILL.md files verbatim, the execution-record export unprocessed, and the instruction "run it as written; if it doesn't fit, tell me which step fails and why".

Where the feedback workflow stopped

All five steps read Not run. Look at "Precondition not met" on step 1, and at the fact that the numbers in the EXECUTABLE RULE below did not change at all.

The tool refused to run the workflow, and it was right to — the position hasn't closed.

"Precondition not met. There is no full or partial close. The position remains open, so no closed_thesis_record can be created." "Not run. This requires the closed-trade record from Step 1. The current unrealized loss is not a trade outcome and must not be classified as thesis failure, execution failure, market regime, or randomness." — the tool's output, verbatim (2026-09-22 01:49 KST)

And then it raised something nobody asked it to.

"The raw export also reveals a control issue: the container-level loss limit is 500 USDT, or 5% of starting capital, which is wider than the requested -2% objective."

That is a criticism of weltiq's configuration, and it is correct. The earlier run's stop condition of 500 (−5%) was set to satisfy the mandatory gate and sits on a different layer from the mission's −2%, but you cannot tell those apart from the journal alone. The strategy container for this article was set at 200 (−2%), exactly as it said.

5-2. So what got in, and how many fields

Besides the SKILL.md the LLM reads, signal-postmortem has a Python script, and that is where the real join is. I converted the fill record into the format that script consumes and ran it: after Warning: No FMP API key available came Outcome distribution: NEUTRAL: 1.

The third row is the heart of this part. In batch mode this script fetches realized_returns from FMP itself. Even when the record has the value it is not used, and without a key it is left as an empty dict. The classification runs off that empty value, so the answer is always NEUTRAL. The standalone recording mode is worse — it hard-codes entry_price to 0.0.

In other words this feedback loop is built on the assumption of "hold a US stock for 5 or 20 days, then get the return from FMP". A record with minute-level fills and realized P/L will not go in that shape. Joining them needs one line on the repository's side — if the record already has realized_returns, use it.

So here is how to attach it. Give the tool only the regime call and the numbers for the rule, and leave what that rule does in a world with costs and fills to the execution side. Hand the record back to the open thesis side rather than to signal-postmortem — that slot does not require a closed trade.

5-3. The loop is one square short here

I moved the tool's rule into a document without changing a single number, put it on a strategy container, and it went as far as a fill.

The weltiq strategy container

Three places to look — price_above_85350 under ORDERS (the entry line the tool chose became the signal name verbatim), the fill price 86052.42438150 and the fee 9.98208123 USDT under FILLS, and the rule-document fingerprint in the execution log at the bottom.

1 fill, buy 0.116 BTC. Expected 86,043.82 → filled 86,052.42438150 (slippage 8.60), fee 9.98208123 USDT (taker 10bp). The protective stop order (stop_market 0.116 @ 83,800) was accepted, and realized P/L is 0 because the position is still held.

I handed that record back unprocessed and asked for a fresh decision, and it refused to amend and returned the rule unchanged. Even after I opened a time_exit_bars field and told it "this engine accepts an exit after N bars", it put none — the reason being that the position hasn't closed, so it would not change the rule. "No change" is a decision too, and that decision matches its own workflow document.

So how long do you wait for a closed trade? I replayed each of the two rules against past candles.

Replay 30 days of 1-minute candles and the closed-trade count is 0. It enters once and touches neither the stops (83,800 · 84,600) nor the targets (88,200 · 88,800). The resident run was in the same state.

This is the hardest number this part produced. "The feedback input is empty" means empty by exactly this much. What has to be supplied is not "a fill" but "a closed trade", and bolting on an execution engine does not produce one. A tool that owns a feedback workflow cannot run it because of its own rule, which has no time-exit field. So what this article confirmed ends here — decision → rule → fill went through; fill → feedback is standing still.

6. After using it

What was good

• It states what it does not do, up front. "Does not place orders, is not a signal service, runs no hidden scheduled jobs" is in the README
• The workflows are machine-readable YAML. required_skills, artifacts and decision_gate are in the file, so finding "what to pour where" took under 30 minutes
• It honors preconditions and raises things nobody asked about. It stood all five steps down as Not run with reasons, and spotted from the journal alone that the stop condition was wider than the mission's constraint
• The scoring layer is deterministic and you can start with no key. Everything used in this article was free and keyless

What was not

• A 74-skill router that does not know crypto questions. I asked about Bitcoin and a US equity workflow came back as the fallback
• The feedback script is frozen in a US-equity shape. It ignores a record's realized returns, so every classification falls out as NEUTRAL. The standalone recording mode hard-coding entry_price to 0.0 looks like a bug
• Sizing comes out as an absolute quantity and there is no time-exit field. The first overruns capital and blocks entry; the second leaves the position sitting when the market does not move
• The regime score is coarse and the first run takes nearly 6 minutes. Within the same UTC date it is cached and returns instantly — do not read the resulting identical number as "the market didn't change"

Cost

7. What to do next

Install just crypto-regime-analyzer and ask "is crypto risk-on or risk-off right now?". Two report files landing on disk is success, and the next step is to throw the same question in a second time and see whether the numeric rule wobbles.

Part 6 is jesse (★8.6k). If this part was "it decides but does not execute", jesse is the opposite side — a backtest engine at its core, with a UI for inspecting decision points on the chart and Monte Carlo for separating skill from luck.

Getting ready for weltiq — 3 lines 1. Sign up: {{CTA_URL}} 2. My page → issue an API key under connection management 3. claude mcp add weltiq --header "Authorization: Bearer <key>" https://weltiq.ai/mcp

You can move the rule from this article straight across and run it for 24 hours.

Every command, output and number in this article came from runs actually performed on 2026-09-21 and 22. No real money moved; everything is simulated, and none of it is a trading opinion. The trial and error, the raw logs and the defect list that are not written here are in the verification record.