--- name: "ab-100" description: "Interactive AB-100 (Agentic AI Business Solutions Architect) exam drill. Serves blueprint-weighted multiple-choice questions one at a time, grounded in live Microsoft Learn docs, with full explanations and open Q&A after each answer. Tracks per-objective accuracy across days and reweights toward weak areas. First run asks for your target exam date. Use when the user says /ab-100, \"quiz me\", \"exam drill\", \"AB-100 practice\", \"test my readiness\", or asks for their AB-100 readiness report." --- # AB-100 Interactive Exam Drill Exam: **AB-100 — Agentic AI Business Solutions Architect**. Pass score 700/1000. Engine directory (`$AB` below) is **this skill's own folder**: - Windows: `%USERPROFILE%\.scout\m-skills\ab-100` - macOS/Linux: `~/.scout/m-skills/ab-100` Contents: - `drill.py` — onboarding, session planner, answer recorder, readiness reporter - `blueprint.json` — all 74 exam objectives with domain weights - `config.json` — created on first run; holds the user's target exam date - `progress.db` — SQLite history, created on first run (never edit by hand) Always run commands with `cd "$AB"; python drill.py `. Use `python3` if `python` is not on PATH. --- ## Step 0 — Onboarding (first run only) Before anything else in a session, check whether the skill is configured: ``` cd "$AB"; python drill.py status ``` If the output has `"configured": true`, skip straight to Modes below and never mention onboarding. If it returns `"needs_onboarding": true`, this is a new user. Do this: 1. Greet briefly and explain in one line what the skill does: a daily interactive drill that tracks accuracy per objective and reweights toward weak areas. 2. Ask for their **target exam date** using `m_ask_user` in free-text mode (`inputHint: "YYYY-MM-DD or e.g. Nov 4"`). Do not offer canned date options — this is a value only they know. 3. **Stop and wait for their reply.** Do not proceed on an assumption. 4. Normalise whatever they give you ("Nov 4", "the 4th of November", "in three weeks") to an ISO date. If it is ambiguous, ask once more rather than guessing the year. 5. Optionally ask for their first name so the readiness report is personalised — or take it from the profile if you already know it. This is optional; do not block on it. 6. Write the config: ``` cd "$AB"; python drill.py setup --exam-date YYYY-MM-DD --name "First Last" ``` 7. Confirm back: exam date, days remaining, and a one-line suggestion on cadence (one 20-question session a day is the intended rhythm; under 7 days out, suggest two). Then offer to start the first drill immediately. `setup` rejects past dates and refuses to overwrite an existing date unless `--force` is passed. If the user later says "my exam moved" or "change my exam date", re-run `setup` with the new date and `--force`. --- ## Modes | User says | Do this | |---|---| | `/ab-100`, "quiz me", "drill me", "practice" | **Run a full drill session** (below) | | "readiness", "how am I doing", "score", "report" | Run `python drill.py report` and present it (see Reporting) | | "history" | Run `python drill.py history` and show the trend | | "just N questions" | Full drill flow with `--count N` | | "my exam date changed", "reschedule" | `python drill.py setup --exam-date YYYY-MM-DD --force` | | "start over", "wipe my progress" | Confirm first, then `python drill.py reset --confirm` | --- ## Running a drill session ### Step 1 — Plan ``` cd "$AB"; python drill.py start --count 20 ``` Returns `session_id`, `day_number`, `days_until_exam`, `domain_allocation`, a list of 20 `questions` (each an objective to write a question on, with `qnum`, `objective_id`, `domain`, `group`, `objective`, `prior_attempts`, `prior_accuracy`), and `avoid_repeating_these_recent_stems`. If `start` exits with `"needs_onboarding": true`, go back to Step 0. The objective selection is already blueprint-weighted and biased toward weak/uncovered areas. **Do not second-guess the allocation.** Write exactly one question per listed objective. ### Step 2 — Ground in current documentation Before authoring, batch **3–6** `microsoft_docs_search` calls from the Microsoft Learn MCP server covering the clustered themes in today's objective list (e.g. Copilot Studio orchestration, Foundry Agents ALM, agent governance, D365 F&SCM AI features). Use `microsoft_docs_fetch` when a specific page matters. This exam covers fast-moving products. Do not rely on recall — **verify product names, capability boundaries, and licensing/feature facts against Learn.** If Learn contradicts your prior assumption, Learn wins. ### Step 3 — Author all 20 questions up front Write the full set internally before serving question 1, so the session flows without pauses. **Question style — match real AB-100 items:** - **Scenario-based and architect-level.** 2–4 sentences of business context, then the ask. Not trivia. Test judgment: *when* to use a thing, *which* option fits a constraint, *what* the tradeoff is. - **Single best answer**, four options (A–D). Occasionally use a "select the best sequence/order" framing. - **Plausible distractors.** Every wrong option must be a real Microsoft capability that a reasonable architect might pick. No joke options, no obviously wrong answers. - **Vary the verb** across the set: *recommend, design, determine, evaluate, validate, orchestrate, minimize cost, minimize admin effort*. - Include constraint clauses that drive the answer — "with the least administrative effort", "without writing custom code", "while meeting data residency requirements". - Do **not** reuse any stem in `avoid_repeating_these_recent_stems`. Fresh scenarios every day. - Roughly one in five should be a **negative or exception** item ("Which approach would NOT meet...") — but no more. ### Step 4 — Serve one question at a time This is the whole point of the session — **it is interactive**. Never dump multiple questions at once, and never reveal the answer in the same message as the question. Present each as: ``` **Question 7 of 20** · DEPLOY · X.C.2 **A.** ... **B.** ... **C.** ... **D.** ... ``` Then **stop and wait**. Do not call any tool. Do not continue. Present the question as markdown text (not `m_ask_user`) so the user can reply freeform — "B", or "B, but why not C?", or "explain the difference first". ### Step 5 — Grade and explain When the user answers: 1. State **Correct** or **Incorrect** plainly, and name the right answer. 2. Explain **why the correct answer is correct**. 3. Explain **why each distractor is wrong** — one line each. This is where the learning happens; do not skip it. 4. Add a **Learn anchor**: the specific doc/concept to review, with the Learn URL when you have it. 5. If they got it wrong, add one **memory hook** — a short rule of thumb that makes the distinction stick. Keep it tight. Six to ten lines total unless they ask for more. ### Step 6 — Record it ``` cd "$AB"; python drill.py record --session --qnum --objective --correct <1|0> --stem "" ``` Record **immediately after grading each question**, not in a batch at the end. If the session is interrupted, the data survives. Judgment on grading: if the user gives a defensible answer with sound architect reasoning that the item didn't anticipate, say so, and grade the item on the option they actually selected. ### Step 7 — Handle follow-ups **Auto-advance is the default.** After grading, explaining, and recording, serve the next question in the same message. Do not stop to ask "ready?" or wait for "next" — keep the session moving. The only exception: if the reply contains a follow-up question alongside (or instead of) the answer — "B, but why not C?", "explain the difference first", "give me another one like that" — answer it fully, searching Learn if needed, and **hold on the current question** until that thread is closed. Then resume auto-advancing. ### Step 8 — Close out the session After question 20: ``` cd "$AB"; python drill.py finish --session cd "$AB"; python drill.py report ``` Then deliver the wrap-up (see Reporting). --- ## Reporting Present `report` output as prose plus a compact table — never raw JSON. Cover: - **Today's score** (x/20) and the trend versus prior sessions - **Per-domain accuracy** against the exam weights, in a table - **Readiness band** — quote the band verbatim, do not inflate it - **Top 3 weak objectives** with a specific study action for each (name the Learn module or doc page) - **Days until exam** and a one-line call on whether they're tracking to pass Be straight with them. If the numbers say borderline, say borderline. A falsely reassuring readout is worse than useless before a real exam. **Report table format:** | Domain | Exam weight | Answered | Accuracy | |---|---|---|---| | Plan | 25-30% | 24 | 79% | --- ## Rules - **Run `status` first.** Never assume an exam date; if unconfigured, onboard before drilling. - **Never reveal the answer before they respond.** No hints in the option ordering, no tells in the phrasing. - **One question per message.** Full stop. - Ground in Learn; this exam's skills-measured list is dated 2026-07-22 and the products move monthly. - The blueprint is authoritative — if `blueprint.json` and your memory disagree on weights, the file wins. - If `progress.db` is missing, run `python drill.py init` and carry on. - Keep momentum. They're drilling, not reading an essay.