Month Start

Month-Ahead Scan (global, MCP-only)

Replaces the old project-local /month-start (now archived at Journals/.claude/skills-legacy/month-start/). Same reasoning as week-start/SKILL.md's header. CLAUDE.md at /Users/latuconsinafr/Personal/Trading/Journals/CLAUDE.md remains the rulebook.

If anything this session suggests a rule should change, per CLAUDE.md §20.14: add it to CLAUDE.md §21.3, do not act on it.

This still sets context only — same constraint as week-start. No verdict, thesis, or hypothetical here; those only originate from /sod. Persists nothing to journal_rollups either — checked the old system first: month-start never wrote a file there (unlike week-start's week_ahead_scan.md), so there's no monthAheadScanMd-equivalent field to write to. This session exists to inform the pilot, not to leave a record of itself. It does, as of 2026-08-25, produce a real monthly technical score and fundamental digest for the heatmap (write_technical_score/write_fundamental_digest, timeframe 1M) — that's scoring, not a trading decision. As of 2026-08-30, it also writes validated levels (write_level, timeframe 1M) for any zone from Step 4.2 that clears §3.3's validation bar.

Step 0 — confirm the MCP server is reachable, then resolve the active set

Call get_account_state first. If it fails, stop and explain just run needs to be running. Then call get_active_instruments — do not assume a fixed instrument set for Step 3 below.

Step 1 — resolve the month

Use the current YYYY-MM, unless the pilot gives one explicitly.

Step 2 — check what's changed since last month

• get_account_state — balance, cumulativeDeposited, hardStopThreshold, sizingPhase. This already reflects any deposit made since last month automatically (it's computed live from the deposit ledger, not something this skill recalculates) — just report what it says, including whether the sizing phase (§8) has crossed from A to B.
• Whether XAU has become tradeable — get_active_instruments (already called in Step 0) returns tradeableBalanceThreshold per instrument; compare XAUUSD's against the current balance from the step above. (Corrected 2026-08-25 — this used to require a manual look at the Accounts page since no tool exposed instrument specs; get_active_instruments now does.)
• MT5 server-time offset — ask the pilot to re-verify against MT5 Market Watch; DST can flip it and there's no way for Claude to know the broker's current offset independently.
• If a deposit needs recording, point the pilot to the Accounts page's deposit ledger form (/accounts) — same "real entries go through the web form" pattern as trade entries, not something this skill writes on the pilot's behalf.

Step 3 — get the required charts

Clean 1M (monthly) and 1W (weekly) charts, per active instrument — required, same blocking pattern as sod/SKILL.md Step 3. 1M is this session's own resolution and gets a real technical score (Step 5). 1W is context only — never its own write_technical_score call here; week-start owns that write. Check charts/[DATE]/month-start/ on disk first; ask only for what's missing.

Step 4 — run the scan

1. Scan the macro calendar for the month ahead — central bank meetings, major data releases — across every active instrument (Step 0's get_active_instruments). Every time/date from the calendar itself (§19 primary sources).
2. Independent monthly technical read, per instrument, from the 1M chart — same §3 checklist rigor as /sod applies to D1/H4/M15, at monthly resolution. Then look at the 1W chart for context: has anything shifted since the last few weeks' overviews? Inform this from get_journal_rollups (period: "weekly", recent limit) too, not just the fresh chart.
3. Monthly fundamental digest, per active currency (§4, timeframe 1M) — the broadest, deepest research cadence in this practice short of yearly: full-cycle policy stance, growth trajectory, not just this month's calendar. §19 sources only.

Step 5 — write through MCP

1. write_calendar_event — for each relevant event surfaced in Step 4.1. Leave timeUtc unset and say so if it isn't verified against a primary source.
2. write_technical_score — once per active instrument, timeframe: "1M", from Step 4.2. Never call this with timeframe: "1W" — that's week-start's write to make, not this session's.
3. write_level at timeframe: "1M" — THIS IS THE PRIMARY WRITE FOR THIS SESSION. Do this one before step 4, never skip it in favor of step 4. One call per zone from Step 4.2's monthly read that clears §3.3's validation bar: named prior turns, each with a date and a wick.
   • The date must be exact, obtained by counting bars from the nearest labeled gridline — never "approx," and sparse gridlines are never a reason to skip writing a level.
   • Apply the same counting effort to every pair this session — do not verify one more carefully than the others. But decide per pair, not for the session as a whole: if one pair's turn can't be dated, that one is unvalidated — it does not mean skipping every other pair that can be dated. Partial coverage is the normal, correct outcome, not a fallback.
   • A stated tolerance ("±1-2 days") is not exact and does not pass; an unvalidated pair doesn't get written with a hedge, it doesn't get written.
   • Do this by reading the image and counting candles — never by writing or running a script, pixel-measurement tool, or any automated axis calibration; that's a fragile detour, not extra rigor, and a bug in one is never a reason to write zero levels instead.
   • A zone without nameable turns stays prose-only in write_technical_score's technicalBasis.
4. write_level at timeframe: "1W" — SECONDARY, ADDITIVE TO STEP 3 ABOVE, NEVER A SUBSTITUTE FOR IT. One call per zone visible on the same Step 4.2 context read of the 1W chart that clears the same §3.3 bar (same exact-date, same per-pair rigor, same no-tooling rule as step 3). Levels are backward-looking facts, not a forward call, so this isn't restricted to this session's own 1M write the way write_technical_score is — but it only ever supplements step 3, it does not replace it. write_level upserts by overlapping price range, so this can only add to or confirm what week-start already logged at 1W, never contradict it silently.
5. write_fundamental_digest — once per non-metal active currency only, timeframe: "1M", from Step 4.3. Never call this for XAU/XAG — the tool itself rejects a metal currency value now (a real mistake, happened more than once, now a hard schema error); it forces a 0-10 currency-strength scale onto something §4 explicitly wants read on a different -10..+10 risk-sentiment scale instead.
   • write_risk_sentiment, once per metal active currency, timeframe: "1M", from Step 4.3 — as of 2026-09-03 this is the correct write for metals, not a prose-only fallback. Same timeframe parameter as write_fundamental_digest, so a monthly call no longer collides with /sod's daily call for the same currency, and it auto-populates the metal's heatmap cell the same way, once the paired currency has a score at this exact date+timeframe. Nothing else gets written this session — see the header note on why journal_rollups isn't touched here.