This is my real playbook, built from my real git history.

The map of this whole course: one shared Trunk plus three selectable branches. Until the primary track is adjudicated (§0.4), the weekly budget goes only to Trunk nodes and Chapter 06 assessments. Intel baseline (checked 2026-07-12): Anthropic Academy now lists 20 public courses; the official engineering blog has a context-engineering trilogy; Agent SDK / Agent Skills / MCP docs are mature. Curation discipline carries over from Ch02: primary sources only, links re-checked quarterly.

0.1 The Trunk (mandatory for every branch, in order)

0.2 Branch A · Applied LLM Engineering (new in v3.0)

Why this branch exists: your S2 (token engineering) is already semi-professional — but entirely self-taught folk practice. This branch formalizes it into the market-recognized 2026 "AI Engineer" stack, fully aligned with Anthropic's official courses, and is the fastest of the three branches to cash in. ~12 weeks @ 5h/week. All Academy courses are free and award certificates.

0.3 Branch B / Branch C (pointers — no duplicated content)

0.4 Primary-track adjudication record

0.5 Official materials hub (checked 2026-07, quarterly refresh)

• Anthropic Academy — full catalog (20 courses, free, certificates) ↗
• Anthropic Engineering blog — incl. the context-engineering trilogy ↗
• Agent Skills — overview & authoring best practices ↗
• Claude Agent SDK docs ↗
• Claude Cookbook — evals & context-engineering recipes ↗
• Anthropic Learn hub ↗

Written in the first person, objectively, by Fable 5, addressing you directly. Judged on evidence, not on politeness.

1.1 Data snapshot (as of 2026-07-12; monthly refresh appended 2026-07-13, see rows above)

1.2 Strengths (keep these, and know why they work)

1.3 Weaknesses (this course's actual target)

1.4 Your coding philosophy (observed, not self-reported)

1.5 Playbook rules (current version, revised on evidence)

• R1 · The one law never changes: never merge code you can't explain yourself.
• R2 · The token three-question test (carried over from your prompts spec, extended to interactive sessions): Can this data be pre-digested? Can this context go in system to hit the cache? Can this output be length-capped?
• R3 · A WIP cap on review once the "pending real-device review" list exceeds 5 items, new visual work is frozen until the backlog clears. Review backlog = unexploded bug inventory (evidence: .fld-manual).
• R4 · Late night is write-only output is allowed after 23:00; merging/pushing to main is not. No irreversible action during a judgment-decay window.
• R5 · Workspace hygiene git status must be clean at the end of any session — either commit, or stash and log the destination in Urgent.md.
• R6 · One architecture review a week (hedges W1): have the AI report this week's new duplicate definitions / dead code / end-of-file overrides; you only decide "clean up or log it," capped at 10 minutes.

1.6 Playbook changelog

Core pivot: you no longer need to learn how to prompt (S2 already proves you can). This chapter teaches how to judge whether what the AI hands you is correct, good, and worth merging. Curation discipline: no material is authored here — every lesson points to a primary source and tells you what to watch, what to skip, and how to grade yourself. External links get a quarterly check. Format: every lesson ends with "So you can tell AI this…" — converting the concept into a sharper instruction.

Philosophy: learn to think, do not just paste answers. This is the fix for W3 — every algorithm in your project was AI-written; that option doesn't exist in an interview room. Pace: 3 problems a week, no more. The data (W4) shows you sprint, and algorithmic intuition only grows through spaced repetition — sprinting doesn't work here.

3.1 The four-stage ladder (deliberately anti-grind)

One Virtual Contest a month (Div.3/Div.4 to start) — the 4th week's 3-problem quota is spent on it instead. The VC score curve is the only progress metric: no improvement means step back a stage, no shame, just data. Banned: chasing streaks, leaderboard-watching, "I feel good today so I'll do two extra" — the surplus gets repaid tomorrow as burnout (the Jul 5 50-commit day already proved this once).

3.2 The SPAR framework (four mandatory steps per problem)

1. S — Solve alone (25-minute timer, no AI):

   Write down your reasoning, even if it's wrong. Skip this step and everything after is void — AI may only appear in P/A/R.

2. P — Probe (staged hints):

   I'm working on this problem: [statement]. My current approach: [approach]. Don't give me the solution. Give staged hints: first point out only the single most critical flaw in my approach; when I say 'next level' give the next one; ≤2 sentences per level.

3. A — Analyze (post-solve review):

   Here's my AC code: [code]. Three things: ① report time/space complexity and the bottleneck (ties to Lesson 2.5); ② show me what you consider the most elegant solution and compare the difference; ③ what reusable pattern does this problem belong to — one sentence on how to recognize it.

4. R — Riff (a variant to re-practice):

   Based on this problem, write a variant with the same pattern but a different shell (change the narrative, change the constraint scale) — no solution. I'll self-test with it in three days.

SPAR records go into the training/ directory, archived weekly (reusing your S1 state-externalization discipline) — these records double as the interview material for 3.4.

3.3 The 2026 interview reality (your job-search strategy)

In 2026 technical interviews, pure whiteboard-algorithm rounds are shrinking; two newer rounds now carry equal weight:

3.4 Portfolio > resume

You already have 9 pages with real URLs plus a full data pipeline — ahead of most candidates. What's missing: a short "how I split work with AI" write-up for each of Arena (data pipeline + prompt engineering), Horoscope (complex domain modeling + 518 tests), and the combat HUD (performance and scope adjudication) — pull the material straight from RELEASE_NOTES.md, and turn SPAR review notes directly into STAR stories.

Division-of-labor law: AI writes 100% of the pandas/SQL syntax; you own only the business logic and the data narrative. Every minute you spend on syntax is wasted — you already run this split in your own project (S2's data pre-digestion is exactly this), this chapter just systematizes it for the DA domain.

4.1 A 12-week path (business frameworks first)

4.2 Human/AI division of labor for the three case studies

4.3 The core advanced skill: building an Eval Set for AI's data work

This is exactly where the line falls between a 2026 DA and "an intern who can use AI." The process is a fixed five steps:

1. Sample:

   draw 100 stratified random rows from AI-processed data — you don't get to cherry-pick the easy ones.

2. Hand-label ground truth:

   you label it yourself. These 100 rows are your gold set — the labor cost is the moat.

3. Define the metric:

   field-level accuracy/precision/recall for extraction tasks; a written 1–5 rubric for narrative outputs.

4. Set the bar:

   run once to get a baseline; the passing bar is a business-meaningful threshold above it (e.g. "field accuracy ≥95% before it's allowed into the warehouse").

5. Run it as a regression:

   rerun the gold set on every prompt/model change — your own prompts/README.md discipline of "retry once on parse failure, then give up and log it" carries straight over.

Bridging practice: run a mini eval (20 rows is enough) on your own Arena recap copy or sectors data pipeline first, before taking on the formal W10 case.

4.4 Cross-cutting discipline (mirrors the Ch01 Playbook)

Requirements go into a file before work starts (R5); AI output must pass a sanity-check list every time; every week's output must have a URL or a one-pager — "I learned something" is not an output; every analysis conclusion passes Lesson 2.3's three significance questions.

Positioning: push technical ability toward the hiring bar of top AI labs (Anthropic / OpenAI) and top quant firms. Designed by Fable 5 from a Principal Engineering Mentor's perspective, treating career progression as a strictly engineered system — with a baseline, a metric, and an automatic 4-week recalibration (see §5.6).

5.0 Baseline calibration: the target profile vs. your current position

Anthropic engineering's verified team profile (this chapter's design input):

The two-gates argument (this chapter's single most important strategic call)

There are two doors into companies like this.

Every resource in this chapter is staked on Gate B; the upgraded algorithm training in §5.2 only serves as a signal-booster for Gate B (clearing interview algorithm rounds + a quant-logic base), not the door itself. This call is re-examined at every gap analysis, but overturning it requires anomalous evidence from the VC score curve.

5.1 Pillar 1 · Distributed Systems & Cluster Infra (initial weight 50%)

Modern AI's real bottleneck is compute clusters and data pipelines, not model ideas. Curation discipline carries over from Ch02: no homemade material, only primary sources.

AI-collaboration red line (specific to this pillar): lab code for 6.824/15-445 must be written by hand — this is Ch03's SPAR discipline carried over to systems courses. AI may only appear for (a) concept Q&A, (b) reviewing your code after it's already AC'd, (c) discussing design variants. Letting AI write Raft burns the entire course.

Connecting to what you already have: your arena/sectors data pipeline is the practice ground. After finishing I1's replication chapter, you should be able to answer "under which failure modes does my data pipeline double-write or lose writes" — a past double-run incident is already a live case study.

5.2 Pillar 2 · Elite Algorithmic & Mathematical Logic (initial weight 25%)

Ch03's P1–P4 (800→1600) don't change and remain the prerequisite. This section adds two more stages plus a quant-logic track on top.

Pace unchanged: still 3 problems a week + 1 VC a month — P5/P6 problems are heavier, so per-problem time naturally rises to 60–90 minutes, with total time held constant by problem count (the W4 red line). SPAR's four steps remain mandatory.

Quant-logic track (new, 1 problem a week, replacing rather than adding to the original 3rd problem): Jane Street/Citadel-style probability and expectation puzzles — source: "Fifty Challenging Problems in Probability" (Mosteller) + the MIT 18.05 problem sets. Exit standard: mentally solve a two-step conditional-probability-and-expectation derivation on a whiteboard, no scratch paper. This track also serves Ch02 Lesson 2.3 and quant-firm interviews.

Honest ceiling disclosure: exiting P6 (2100) is already the realistic ceiling signal for amateur training at a sustainable pace, and is more than enough to clear Gate B's algorithm round. 2900 is not in any plan — see the two-gates argument in §5.0.

5.3 Pillar 3 · End-to-End System Ownership (initial weight 25%)

MTS is defined by: no PM writing your requirements, no TL breaking down your tasks, no SRE catching your fall. This skill can be trained entirely live on your own site — treat feida.au as a production service you're responsible for running.

5.4 MTS baseline scorecard (the gap-analysis metric)

Scored every 4 weeks by the automatic loop (§5.6); scores are logged in this section's history table. Every score must cite evidence — impression-based scoring is banned.

Score history:

5.5 Relationship to Ch03/Ch04 (a fork that must be faced directly)

• Ch03: absorbed by this chapter as Pillar 2's prerequisite (P1–P4 → P5–P6 form one continuous ladder); SPAR and the monthly VC carry over entirely. No conflict.
• Ch04 (DA Playbook) and Ch05 (MTS Track) are two different career tracks that cannot run in parallel within a ≤10-hour weekly budget. This is a data conclusion, not an attitude: Ch04 needs its full 12-week budget, Ch05's I1–I4 need a full 12–18 months. My recommendation: with MTS as the primary track, downgrade Ch04 to "an available hedge" — its W1–2 business-framework and 4.3 Eval Set methodology are already mostly covered by Ch02/your prompts spec, and can be cashed in within 12 weeks whenever a DA offer is actually needed. This fork is yours to decide — log the decision in the next §1.6 entry. (Superseded 2026-07-12 v3.0: the primary track is now pending the Chapter 06 placement test — see §0.4.)
• Time-budget reallocation (under Ch05 as primary track): ≤10 hours/week = Pillar 1 ~5h + Pillar 2 ~3h (including the quant problem) + Pillar 3 ~2h (RFC/retro/writing). The appendix's pace-control clause is updated to match.

5.6 · The 4-week automatic assessment loop

Executed by the scheduled task mts-gap-analysis. Mechanism:

1. Trigger:

   every 4 weeks (approximated monthly given cron's expressive limits), offset half a month from the Ch01 review task to form a biweekly self-review rhythm.

2. Assess:

   collect this period's git output, SPAR/VC records, lab test pass counts, and RFC/postmortem output, and score against the §5.4 scorecard (citing evidence).

3. Gap analysis:

   identify the weakest of the three pillars, and check whether the two-gates argument still holds.

4. Rewrite dynamically:

   update course.md's §5.4 score history and next-period task difficulty (weight the weakest link higher, raise difficulty on dimensions already met); sync course.html's Chapter 05 card highlights; commit and push (these two files only), so https://feida.au/course.html stays in sync with actual progress.

5. Circuit breaker:

   if scores stall for two consecutive periods and time logs show over-budget hours, the loop must lower difficulty rather than push for more work — the course adapts to the person, not the other way around (the W4 law).

Nature change: from v3.0, within course scope Fable is no longer an answer vendor — it's a mentor. This isn't a tone preference, it's the training mechanism: W3 exists precisely because "AI writes it + behavior-only review" bypassed your own thinking loop.

6.1 The mentorship protocol (in effect now)

• Two-mode boundary: production site work (bug fixes, pushes, scheduled tasks) stays in executor mode, untouched by this protocol. Any question inside a Chapter 00 tech-tree node defaults to mentor mode.
• Mentor-mode rules (SPAR-P generalized): no complete answers. Level 1 names only the single most critical flaw in your approach, or asks one counter-question; say "next level" to continue; ≤2 sentences per level; still stuck after 3 levels → directional pseudocode, never finished code.
• Exemption clause: saying "just give me the answer" grants a one-time exemption — logged in the §6.5 notes column. Exemption frequency is itself assessment data (frequent exemptions = the node is ahead of you; lower the node, not the discipline).

6.2 The three-dimension scorecard (0–10, every score must cite evidence)

6.3 Assessment cadence

Micro-test: once a week, ≤30 min, rotating across the three dimensions (small coding task / CF-style problem / architecture thought experiment / eval-design exercise), scored on the spot into §6.5. Weekly auto-review: every Monday 20:00 the scheduled task course-weekly-review posts the week's data analysis, week-over-week comparison and an objective vibe-coding assessment to the Weekly Review section below. Monthly: merged into the 12th's course-ch01-monthly-review — reviewing the three-dimension curve. Circuit breaker: two consecutive missed micro-tests → lower that week's other course load instead of making up tests (the W4 law: the course adapts to the person).

6.4 Placement Test #1 (issued 2026-07-12 — status: awaiting submission)

Rules: Q2 must be done alone — 25-minute timer, no AI of any kind (SPAR-S discipline). Q1/Q3 may use references but AI may not answer for you. Report actual time spent per question when submitting. Scores go into §6.5 and the primary-track call goes into §0.4.

6.5 Score history

Auto-published every Monday 20:00 by the scheduled task course-weekly-review: the week's repo data (commits, hour distribution, tests, chunk size, review backlog), a comparison against previous weeks, and an objective three-dimension vibe-coding assessment (evidence-cited, per §6.2). Newest first.