# Week Start

> Run the Week-Ahead Scan for the trading journal (CLAUDE.md Section 13, at /Users/latuconsinafr/Personal/Trading/Journals/CLAUDE.md). Global, MCP-only — writes exclusively through the trading-journal MCP server, no markdown output. Context only — creates no verdict, thesis, or hypothetical. Invoke Sunday evening or Monday morning, before that day's daily session.

- Skill: `latuconsinafr/week-start` (Agent Skill)
- Install (CLI): `npx skillmds@latest add latuconsinafr/week-start`
- Raw SKILL.md: https://api.skillmd.com/api/skills/latuconsinafr/week-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/week-start

---


# Week-Ahead Scan (global, MCP-only)

**Replaces the old project-local `/week-start`** (formerly at `Journals/.claude/skills/week-start/`,
deferring to `Journals/PROMPTS.md`). Same reasoning as `sod/SKILL.md`'s header — that file and
`PROMPTS.md` are left in place, unused. `CLAUDE.md` at
`/Users/latuconsinafr/Personal/Trading/Journals/CLAUDE.md` remains the rulebook; §13 governs this
cadence's cascade rule.

**Instruments — resolved live via `get_active_instruments`, same as `sod/SKILL.md`.** Call it in
Step 0 alongside the connectivity check and use its full pair codes for every subsequent MCP call
— do not assume EU/GU/UJ/XAU (used here for readability only) is still the active set.

**This still sets context only — no verdict, thesis, or hypothetical.** Those only ever originate
from a daily (`/sod`) session; if asked for a directional call here, decline and point to `/sod`.
**It does, as of 2026-08-25, produce a real weekly technical score and fundamental digest** for the
heatmap (`write_technical_score`/`write_fundamental_digest`, timeframe `1W`) — that's scoring, not
a trading decision, and the distinction stays absolute: a number on the heatmap is not a verdict.
**As of 2026-08-30, it also writes validated levels** (`write_level`, timeframe `1W`) for any zone
named in Step 4.2 that clears §3.3's validation bar — `get_active_levels` has no timeframe filter,
so a weekly level surfaces on the "levels to watch" widget alongside daily ones from `/sod`.

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

Same as every other skill in this set — call `get_account_state` first. If it fails, stop, explain
`just run` needs to be running in `webapp/`, and do not proceed as if anything here will be
recorded. Then call **`get_active_instruments`** and use its result for the rest of this session —
do not assume the EU/GU/UJ/XAU shorthand used below still matches the active set.

## Step 1 — resolve the week

**Compute the ISO week with `date +%G-W%V`** (confirmed empirically 2026-08-19 to zero-pad
correctly, e.g. `2026-W34`, `2026-W02` for single-digit weeks) — unless the pilot gives one
explicitly. **Never hand-construct this string** — `get_journal_rollups` sorts `periodKey` as
plain text, and an unpadded week number (`2026-W5`) sorts in the wrong place relative to
`2026-W31`. This is not cosmetic; getting it wrong silently corrupts every cascade read that
follows.

## Step 2 — check whether this week's scan already exists

Call **`get_journal_rollups`** (`period: "weekly"`, small `limit`, e.g. 4). If a row for this
exact week's `periodKey` already has `weekAheadScanMd` set, confirm with the pilot before
overwriting rather than silently replacing it.

## Step 3 — gather what the scan needs

- From the same `get_journal_rollups` call: the **immediately prior** week's `overviewMd` (the
  highest `periodKey` strictly less than this week's), for the "has anything shifted since last
  week" comparison. If none exists yet (this is early in the practice), say so plainly — there's
  nothing to compare against yet, not an error.
- **`get_calendar_events`** for the days in the week ahead, per currency in the active set
  (Step 0's `get_active_instruments`) — or ask the pilot for anything not yet on file if this is
  being run before that research has happened.
- **Clean 1W (weekly) and 1D (daily) charts, per active instrument — required, same blocking
  pattern as `sod/SKILL.md` Step 3.** 1W is this session's own resolution and gets a real technical
  score (Step 5). 1D is context only — "has structure shifted since last week's daily reads" — never
  its own `write_technical_score` call; that stays `/sod`'s exclusive write, every single day.
  Check `charts/[DATE]/week-start/` on disk first, same convention as `sod` Step 3; ask only for
  what's missing.

## Step 4 — run the scan, in this order

1. Scan the economic calendar for the full week ahead across every active instrument — flag every
   high-impact event with its scheduled time (WIB, plus server and ET). Every time and date comes
   from the calendar itself (§19 primary sources) — leave a forecast/previous value blank and say
   so if it can't be verified, never guess.
2. **Independent weekly technical read, per instrument, from the 1W chart** — same §3 checklist
   rigor as `/sod` applies to D1/H4/M15, just at weekly resolution: swing structure, the nearest
   validated levels, volume where it confirms/contradicts. This is a real technical score, not a
   verdict — no thesis is asked for, no entry/stop/target gets discussed. Then look at the 1D chart
   for context only: has anything shifted since last week's overview (Step 3)? Name the **next**
   level above and below current price, not just the nearest one, so the week's R:R arithmetic has
   something to work with once a daily session finds a setup.
3. **Weekly fundamental digest, per active currency** (§4, timeframe `1W`) — deeper research than a
   daily digest affords: this week's actual data/speaker calendar (Step 4.1) plus the broader
   policy/growth picture. §19 sources only, same as every other fundamental digest in this practice.
4. Note any event-risk windows (§6) to be aware of early in the week, and which sessions are
   actually unobstructed by them.
5. Flag which days carry a red-folder release, so `/sod`/`/eod` know to capture M15 on those
   days regardless of position status (§6's measurement-method requirement).

## Step 5 — write through MCP (the only write path)

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: "1W"`, from Step 4.2's
   independent weekly read. Never call this with `timeframe: "1D"` — that upserts into `/sod`'s own
   cell and isn't this session's write to make.
3. **`write_level` at `timeframe: "1W"` — 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
   weekly read that clears §3.3's validation bar: named prior turns, each with a date and a wick,
   not just "resistance around X."
   - The date must be exact, obtained by counting bars from the nearest labeled gridline — never
     "approx" or rounded to the nearest label, 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 (levels for some pairs, prose-only for others) 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 mentioned in the technical read but without nameable turns stays prose-only in
     `write_technical_score`'s `technicalBasis` — do not force a `write_level` call just to cover
     every level named informally.
4. **`write_level` at `timeframe: "1D"` — 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 1D
   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 (validated prior turns), not a forward
   call, so unlike `write_technical_score` this one isn't restricted to `/sod`'s own timeframe —
   but it only ever supplements step 3, it does not replace it. A pair+timeframe can hold several
   levels at once, and `write_level` upserts by overlapping price range, so re-confirming a level
   already on file merges evidence rather than duplicating it.
5. **`write_fundamental_digest`** — once per **non-metal** active currency only, `timeframe:
   "1W"`, 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, not
   just a documented "don't"); it forces a 0-10 currency-strength scale onto something CLAUDE.md
   §4 explicitly wants read on a different -10..+10 risk-sentiment scale instead.
   - **`write_risk_sentiment`, once per metal active currency, `timeframe: "1W"`, from Step
     4.3 — as of 2026-09-03 this is the correct write for metals, not a prose-only fallback.**
     It now takes the same `timeframe` parameter as `write_fundamental_digest` (same enum, same
     default), so a weekly call here no longer collides with `/sod`'s daily call for the same
     currency — they're distinct rows. It also auto-populates the metal's heatmap cell the same
     way `write_fundamental_digest` does for non-metal pairs, once the paired currency has a
     score on file at this exact date+timeframe.
6. **`write_journal_rollup`** — `period: "weekly"`, this week's `periodKey`, **`weekAheadScanMd`
   only** (the Step 4 scan content). Do not set `overviewMd`/`reflectionMd`/compliance fields here
   — those belong to `week-end`, and setting them now with placeholder content would corrupt what
   `week-end` writes later (the upsert merges by field, so leaving them unset here is what keeps
   `week-end`'s later write clean, not a limitation to work around).

If either call fails, stop and report exactly what succeeded and what didn't, rather than
silently treating the scan as fully recorded.