# Year Start > Run the Year-Ahead Scan for the trading journal (CLAUDE.md Section 13, at /Users/latuconsinafr/Personal/Trading/Journals/CLAUDE.md). Global, MCP-only, context only. Invoke at the start of a new year. - Skill: `latuconsinafr/year-start` (Agent Skill) - Install (CLI): `npx skillmds@latest add latuconsinafr/year-start` - Raw SKILL.md: https://api.skillmd.com/api/skills/latuconsinafr/year-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/year-start --- # Year-Ahead Scan (global, MCP-only) **Replaces the old project-local `/year-start`** (now archived at `Journals/.claude/skills-legacy/year-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. **Context only, persists nothing to `journal_rollups`** — same as `month-start`/`quarter-start`: the old system never wrote a file here either. **It does, as of 2026-08-25, produce a real yearly technical score and fundamental digest** (`write_technical_score`/`write_fundamental_digest`, timeframe `1Y`) — the top of the cascade: a `1Y` fundamental read feeds down through every finer timeframe that doesn't have its own more specific research yet (`resolveFundamentalTimeframe` in `lib/pairs.ts`), and the `1Y` heatmap column is real, same mechanic as every other timeframe. **As of 2026-08-30, it also writes validated levels** (`write_level`, timeframe `1Y`) for any zone from Step 3.2 that clears §3.3's validation bar. Still no verdict, thesis, or hypothetical — those only originate from `/sod`. ## 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 below. ## Step 1 — resolve the year Use the current year, unless the pilot gives one explicitly. ## Step 2 — get the required charts **Clean 1Y-equivalent and 1M (monthly) charts, per active instrument — required, same blocking pattern as `sod/SKILL.md` Step 3.** The 1Y-equivalent is this session's own resolution and gets a real technical score (Step 4). 1M is context only — never its own `write_technical_score` call here; that stays `month-start`'s (or `quarter-start`'s refresh) write to make. **"1Y-equivalent" is deliberately not "a literal yearly candle chart"** (added 2026-09-05, same reasoning `quarter-start` already applies to its own missing quarterly-candle resolution): MT5 has no yearly timeframe at all — `MN1` is its coarsest. A genuine `12M`/yearly chart exists on other platforms (e.g. TradingView) and is fine to use if the pilot already has one open, but nobody should need a second platform just for this session. Either is acceptable: - A true yearly-candle chart, from whatever platform provides one, **or** - A wide-zoomed `MN1` (monthly) view spanning many years — the same chart `month-start` reads at its normal zoom, just pulled back to show a multi-year span instead. State plainly which one was provided; a wide-Monthly substitute doesn't change anything about how Step 3.2 is read (multi-year swing structure is multi-year swing structure regardless of which candle body encodes it), it's purely a note about provenance. The `write_technical_score`/`write_level` calls in Step 4 are still `timeframe: "1Y"` either way — the cadence of the *read* is what "1Y" means here, not a claim about the literal candle resolution of the source image. Check `charts/[DATE]/year-start/` on disk first; ask only for what's missing. ## Step 3 — run the scan 1. High-level scan of known major macro themes for the year — central bank policy paths, elections, known geopolitical calendar. 2. **Independent yearly technical read, per instrument, from the 1Y-equivalent chart** (Step 2 — a true yearly chart or a wide-zoomed `MN1` view, whichever was provided) — same §3 checklist rigor as `/sod`, at yearly resolution: multi-year swing structure, the handful of levels that actually matter at this scale. Then look at the 1M chart for context, informed by **`get_journal_rollups`** (`period: "quarterly"`, recent `limit`) too. 3. **Yearly fundamental digest, per active currency** (§4, timeframe `1Y`) — the broadest cadence in this practice: multi-year policy regime, not just this year's calendar. §19 sources only. ## Step 4 — write through MCP 1. **`write_calendar_event`** — for each relevant event surfaced in Step 3.1. Leave `timeUtc` unset and say so if unverified. 2. **`write_technical_score`** — once per active instrument, `timeframe: "1Y"`, from Step 3.2. 3. **`write_level` at `timeframe: "1Y"` — 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 3.2's yearly 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: "1M"` — SECONDARY, ADDITIVE TO STEP 3 ABOVE, NEVER A SUBSTITUTE FOR IT.** One call per zone visible on the same Step 3.2 context read of the 1M 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 `1Y` write — 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 `month-start`/`quarter-start` already logged at `1M`, never contradict it silently. 5. **`write_fundamental_digest`** — once per **non-metal** active currency only, `timeframe: "1Y"`, from Step 3.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: "1Y"`, from Step 3.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 yearly 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.