session-start — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited session-start (Agent Skill) and scored it 92/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 2 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 2 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Every session begins with a conversation. Not a checklist -- a real discussion where coach and student align on where we are, what we can do, and how to spend the time.
/checkin or "start session" or session opensBefore anything else -- before reading progress, before greeting the student -- verify system integration. If any check fails, fix it immediately. Do NOT proceed to Step 1 until all checks pass.
Checks (run silently, report only failures):
If all pass: Proceed silently to Step 1. Do not mention the check. If any fail: Report what's broken, fix it, then re-verify. Only proceed when GREEN.
This gate is non-negotiable. One broken session corrupts the cumulative data the entire system depends on.
Read these before saying anything:
memory/user_domain.md: the student's background and domain (if missing, this is a first-session situation — trigger Step 1a)Do NOT ask the student what they did last session. You already know. Show them you know.
If there's a time gap (several days or weeks since last session): Don't judge. Check what concepts might have faded — suggest /review-deck early in the session to test retention before building on top of rusty knowledge.
If memory/user_domain.md does NOT exist, this is the student's very first session. Before anything else, discover their domain, target, and — critically — what shaped their expectations.
Ask in one natural message (not a questionnaire):
Save the answers to memory/user_domain.md immediately:
---
name: Student domain and target
description: Background, analogies, primary target role, what shaped the target, time budget
type: user
---
- Background: {answer 1}
- Analogies that resonate: {answer 2}
- Primary target role: {answer 3 — exactly one of: ML Engineer / Data Scientist / GenAI Engineer / MLOps Engineer / AI Research Engineer / Other}
- Target company + timeline: {answer 4}
- Source of target + what excited them: {answer 5}
- Time budget: {answer 6}
- First session: {date}This file drives every future explanation, metaphor, and pacing decision. Never ask these questions again.
#### Narrative calibration (do this in the same first session, right after saving the file)
Now that you know what shaped their expectations, calibrate honestly. This is not negotiable — the coach runs the calibration because marketing narratives shape beliefs that silently break learning six months later.
If the source was a bootcamp video, influencer content, or "AI is hot right now" framing:
Surface and test the beliefs that those sources typically install. Pick the 2–3 that are likely present based on their answer to Q5, and ask each as a direct question:
The goal is not to demoralize. The goal is to replace the marketing story with the real one on day one, so we don't fight it every week. Use their exact answers to adjust — if they don't hold a belief, skip that question.
End the calibration with: "Here's the deal: we will do the things those videos promised. You will build models, deploy systems, ship projects. But you will also do the work those videos skipped — the math, the theory, the from-scratch implementations. That work is the reason 80% of candidates fail FAANG ML first rounds. Agreed?"
Wait for explicit agreement. Save a follow-up line in memory/user_domain.md:
- Narrative calibration (first session): {which beliefs surfaced, which they accepted, any they pushed back on}If they mentioned specific projects (TB classifier, song ID, content moderation, etc.), immediately add them to FUTURE-BUILDS.md with the related topic and a "unlocked at" marker. The student sees their excitement preserved, not dismissed.
Why this step exists: The system was previously hardcoded to accountant/SaaS examples. That failed for every student outside those domains. The coach now ADAPTS. And because many students arrive with marketing-video-shaped beliefs, the coach also calibrates expectations on day one so the math wall at Topic 3 and the brain-metaphor confrontation at Topic 4 don't feel like bait-and-switches.
Start with a three-part status and one question:
"Here's where we are:
DONE: [what you've completed so far -- exercises, concepts, milestones]
NOW: [what you're currently working on or about to start]
NEXT: [what comes after this -- the upcoming exercises, topics, milestones]
You're on track for [topic result]. How much time do you have today?"If the last session ended mid-flow (e.g., theory done but exercise not started), say that:
"Yesterday we discussed [topic] and you understood [X].
The exercise is ready to build. How much time do you have?"Shape the session around available time:
15-30 min: Pick ONE thing. Theory discussion, brainstorm a wiki page, review-deck recall, or a quick code task. Not all of them.
1-2 hours: Prep discussion + build exercise + review. Or deep theory session with brainstorming if the topic demands it.
3+ hours: Full cycle -- prep, build, review, grilling, brainstorm, preview next topic. Or tackle a larger project chunk.
5+ hours: Multiple exercises or a mini-project session. Plan checkpoints so progress isn't lost if energy dips.
Propose a plan. Discuss. Adjust. Both must agree before moving forward.
Guardrail: The plan must align with the ROADMAP. If the student wants to do something off-roadmap, discuss it openly -- is this a detour or a course correction? If we agree to diverge, update the ROADMAP to reflect the new direction. Whatever we decide, we follow. No silent drift.
Before the student writes anything, run the three-phase session design. See .claude/rules/session-design.md for the full protocol.
Phase 1 — Story: Coach describes what we're building in natural language. Project context. Mathematical root. No code, no function names.
Phase 2 — Mental Model (Socratic Q&A): Coach asks questions. Student finds answers. Coach never gives the answer directly — asks a different question that leads the student there. Gate: student can describe every piece of what they're about to write, in their own words, without prompting.
Phase 3 — Dynamic Exercise: Coach creates the exercise file in the relevant folder, calibrated to what Phase 2 revealed. TDD stubs first. Student writes RED tests, then GREEN code.
If the concept is foundational (will break everything downstream if not understood), slow down Phase 2 as much as needed. Never rush to Phase 3.
#### Step 4b: Problem-First Gate (Topics 6-8 only)
If the current exercise is a Topic 6, 7, or 8 applied exercise (one that produces an end-to-end artifact a user could interact with -- RAG system, agent workflow, MCP server, deployed service), the problem-first rule fires before architecting. See .claude/rules/problem-first.md.
Run the Four Questions:
The student writes problem.md in the exercise folder. The coach runs the four binary audit checks. If any fail, the coach does NOT review the architecture or allow the exercise to start. Rewrite problem.md first. This is non-negotiable, same severity as TDD and the math whiteboard gate.
Skip the gate ONLY if: the exercise is purely mechanical (benchmarking retrievers on a fixed dataset, etc.) or the student is in Build Mode / Exploration Mode. Topics 0-5 are exempt -- the concept IS the problem at the fundamentals stage.
Why this lives in the check-in: the most common failure mode in applied AI projects is technology-first thinking. Eugene Yan, Chip Huyen, Hamel Husain, and Shreya Shankar have all independently named it as the top reason applied AI projects fail. Catching it at the check-in -- before architecture, before code, before tests -- is 10x cheaper than catching it at review.
Once aligned, clearly state what's happening:
"OK, here's the plan: [what we'll do]. Let's go."If it's a coding session → Story → Mental Model → Dynamic Exercise (see Step 4 above and .claude/rules/session-design.md). If it's a theory/research session → start the discussion or point to resources. If it's a brainstorm → invoke the brainstorm skill.
If concepts are due, mention them during Step 2:
"You also have 3 concepts due for recall. Want to do those first
(5 min) or after the main work?"Let the student decide placement. Don't force it at the start if they'd rather warm up with building.
Throughout the session, the coach maintains awareness of three things:
If at any point the session drifts from the agreed plan, the coach flags it:
"We planned to [X] but we've been discussing [Y] for 20 minutes.
Is this more important, or should we get back on track?"If we agree the drift is valuable → update the plan explicitly. If not → get back to what we agreed.
No silent divergence. Every change to the plan is a conscious decision by both.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.