# Month Start > Run the Month-Ahead Scan for the trading journal (CLAUDE.md Section 13, at /Users/latuconsinafr/Personal/Trading/Journals/CLAUDE.md). Global, MCP-only, context only — creates no verdict, thesis, or hypothetical, and (matching the old system) persists nothing beyond any calendar events surfaced. Invoke on the first trading day of the month. - Skill: `latuconsinafr/month-start` (Agent Skill) - Install (CLI): `npx skillmds@latest add latuconsinafr/month-start` - Raw SKILL.md: https://api.skillmd.com/api/skills/latuconsinafr/month-start/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: latuconsinafr (https://skillmd.com/u/latuconsinafr) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/latuconsinafr/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.