Workshop Section: 1 — Right Interface for the Task

Roles

• Work individually, then compare with a neighbor

Starting State

You have the five scenarios below, the interface reference, and a place to record one choice and rationale per scenario. No repository or live Copilot access is required.

Reference — Interface Selection

Steps

For each scenario, decide the single best-fit interface and write a one-sentence reason:

1. Renaming a local variable and its five usages within one file
2. Investigating why a production incident started after last night's deploy, across three services
3. Adding unit tests directly to an existing test file for a function you just finished, using its current tests as the pattern
4. Asking what a regular expression in a legacy file does, with no intention of changing it
5. Running a long, multi-step refactor of a legacy module from your terminal

Answer Key

1. Code completions / Next Edit Suggestions — a same-file, mechanical rename doesn't need a billed conversational interface
2. Agent mode or Copilot CLI with cross-service scope — this needs multi-file/multi-service investigation and likely command execution
3. Edit mode, referencing the existing test file directly — the task is a bounded change in a named file, not merely a question about how to write tests
4. Ask mode — this is a question, not a change; no need for Edit or Agent mode
5. Copilot CLI — a terminal-native, long-running agentic task benefits from CLI's session and tooling model over Chat

Success Criteria

• ✅ You chose code completions/NES (not Chat) for Scenario 1
• ✅ You chose Agent mode or Copilot CLI with cross-service scope for Scenario 2
• ✅ You chose Edit mode for Scenario 3 and can explain why a bounded file change is not Ask mode
• ✅ You chose Ask mode for Scenario 4
• ✅ You chose Copilot CLI for Scenario 5 and can explain why

Workshop Section: 2 — Context, Customization & Instruction Efficiency

Roles

• Work individually, then discuss as a table

Starting State

Use the supplied weak prompt, instruction excerpt, customization inventory, tool list, and memory entries. Do not open or change live repository customizations or memory during the exercise.

Part A — Before/After Prompt Worksheet (4 min)

Before: "Fix the bug in the payment code."

Rewrite this into an After prompt with a clear task, named context, and an explicit stop condition. Use the worksheet below:

Model After Prompt (compare once you've drafted your own):

"In src/payments/charge.ts, the applyDiscount() function returns a negative total when a discount percentage greater than 100 is passed in. Fix it so percentages above 100 are rejected with a validation error before the calculation runs, matching the validation pattern already used in validateAmount() in the same file. Stop once the existing test suite in charge.test.ts passes and you've added one new test for the over-100 case — do not refactor unrelated functions in this file."

Part B — Customization Inventory: Keep / Scope / Retire (8 min)

B1 — Instruction lines. Below is a sample excerpt from a repository's copilot-instructions.md. Mark each line Keep, Scope (move to path-scoped instructions, a prompt file, a custom agent, or a skill), or Retire.

1. Always write clean, maintainable code.
2. This repository uses Node.js 20 and TypeScript 5.4 with strict mode enabled.
3. Be a helpful and thorough assistant.
4. All API handlers must validate input using the `zod` schemas in `src/schemas/`.
5. Follow SOLID principles and general software engineering best practices.
6. Files under `services/billing/` must never log raw credit card numbers — mask
   all but the last 4 digits before writing to any log.
7. Prefer functional programming style where reasonable.
8. Run `npm test` and `npm run lint` before considering any change complete.

B2 — Customization inventory. Use this trigger reference, then classify each inventory item.

Tip: In Copilot CLI, /context shows how the context window is split across instructions, tool definitions, message history, free space, and buffer. Use it to confirm where your recurring cost actually is before trimming.

Part C — Task-Based MCP and Tool Pruning (6 min)

Task in scope: "Triage and fix a failing CI check on an open pull request in this repository."

Classify every enabled tool as Required, Optional, or Remove for that task, then mark whether the tool reads only or can write (change state, comment, merge, deploy, or spend).

Part D — Copilot Memory Triage: Keep / Delete / Never Store (2 min)

Paper exercise — do not edit a live memory store during this lab. Work from the four supplied candidate entries below.

Tip: The 28-day retention default is not a hygiene control. A repository fact that conflicts with the current branch should fail validation and be skipped, but obsolete entries still need review; sensitive content should never sit in the store at all.

Answer Key

Part A: The model After prompt is a strong example — it names the exact file/function (context), states the wrong behavior and the fix (task), and gives a concrete stop condition (tests pass, one new test, no unrelated refactors). If your draft is missing one of these three elements, revise it now.

Part B1:

Part B2:

Key teaching point: only items A, E, and F changed anything about recurring cost. "More customization" is not automatically "more cost per turn" — always-on instruction scope and enabled tool schemas are where the recurring cost concentrates.

Part C:

Read/write boundary: after pruning, the surviving set is four read tools plus one local-execution tool, with one optional write tool that files an issue. Nothing that merges, deploys, or spends money stays enabled for this task.

Part D:

Key teaching point: Delete and Never store are different failures. Delete is a review problem — a legitimate fact went stale. Never store is a boundary problem — the content should not have entered memory at all, and for a credential the deletion is the last step, not the fix.

Success Criteria

• ✅ Your "After" prompt names a specific file/area, describes expected behavior, and states a stop condition
• ✅ You marked lines 1, 3, and 5 as generic filler to retire
• ✅ You marked lines 2, 4, 6, and 8 as specific and grounded — keep
• ✅ You did not retire line 6 (a safety-critical, specific instruction)
• ✅ You scoped item A rather than deleting it, and named the surface you would move it to
• ✅ You kept items B, C, and D and can explain that their full bodies load on demand rather than on every turn
• ✅ Your tool inventory keeps items 1–4, and removes items 5, 7, 8, and 9
• ✅ You can state which surviving tools can write or spend, and justify each one against the named task
• ✅ You can name /context as the place to confirm how much of the window instructions and tool definitions consume
• ✅ Entry 1 is the only memory entry you marked Keep
• ✅ You marked entry 2 Delete and can explain both the current-branch validation safeguard and why obsolete state still needs removal
• ✅ You marked entries 3 and 4 Never store, not merely Delete
• ✅ Your action for entry 4 starts with rotating or revoking the credential, not with deleting the memory entry
• ✅ You can state the difference between Delete (was valid, now stale) and Never store (must never be persisted), and did not treat the 28-day expiry as a hygiene control

Workshop Section: 3 — Session Lifecycle, Handoff, Cache & Session Limits

Roles

• Work individually, then discuss as a table

Starting State

Use the six supplied scenarios and the command reference for Parts A and B. For Part C, assume the investigation is complete, no code has changed, and the listed technical decision has already been approved.

Part A — Session Design & Cache Check (5 min)

Use this command reference, then decide whether to continue the current session, start a new one, compact, inspect, resume, or expand file scope.

1. You just finished debugging an auth issue and now want to ask an unrelated question about a CSS layout bug
2. Your Copilot CLI thread has been open for two hours on the same refactor and is starting to feel sluggish
3. You finished research and a plan for a feature and are about to start implementation
4. You return to yesterday's Chat session to ask one more follow-up question on the same topic. State which cache-expiration window applies and name one change that would invalidate reusable cached context
5. You want to confirm whether tool definitions or message history are consuming most of a long CLI session
6. A task in the current repository needs one sibling directory, but not access to the rest of the parent directory

Part B — Session Limit Worksheet (3 min)

AI-credit session limits are in public preview. Define a soft limit for a Copilot CLI task you run regularly (or a hypothetical one):

Write the interactive command using your amount:

/limits set max-ai-credits NUMBER

If Copilot CLI is installed, you may run that command, confirm that the CLI reports the limit was set, and then remove it:

/limits unset

Do not submit a model prompt for this checkpoint. Setting and unsetting the control demonstrates the configuration without making a paid AI request. If Copilot CLI is unavailable, review the commands on paper and state the expected behavior: an in-progress response may finish slightly over the soft limit; interactive CLI prompts you to reset or raise it; non-interactive CLI ends. If the CLI opens but either command returns an error, stop the live variation, use the same paper fallback, and verify the installed CLI version and current command syntax after the timed exercise.

The Copilot SDK equivalent is sessionLimits.maxAiCredits when creating or resuming a session. See CLI session limits and SDK session limits.

Part C — Clean-Session Handoff (4 min)

Scenario: You have spent 40 minutes in a Copilot CLI session investigating why the nightly job occasionally issues a refund twice. You confirmed the cause is a retry path in src/billing/refund-worker.ts that re-enqueues a refund without an idempotency key. You ruled out the payment provider using its API logs. Your tech lead agreed the fix is an idempotency key derived from the refund ID, stored in refund_attempts, and that changing the provider client is out of scope for this ticket. The existing integration test file is tests/billing/refund-worker.test.ts. You are now starting implementation in a fresh session.

Write the handoff you would paste as the first message of the new session:

Remember: the handoff complements the built-in controls — /compact reshapes the current thread, /resume reopens a saved one, and VS Code /fork branches a session that inherits full history. You write a handoff when you want a clean context rather than an inherited one.

Answer Key

Part A:

1. New session — unrelated problem; carrying the auth debugging history into a CSS question wastes context
2. /context, then /compact if warranted — the thread is still relevant; inspect it first, then compact to replace the large history with a smaller summary. Compaction uses a summarization step and can lose fine detail, so it is not an every-turn habit
3. New session — a phase change (plan → implement); implementation needs only the plan's outcome, not the full research trail. This is the natural place to use the six-field handoff from Part C
4. Depends on elapsed time and configuration stability — if the session is still within its cache-active window and on-topic, continuing may still benefit from cached context. The documented inactivity windows are currently 24 hours for OpenAI models and 1 hour for most others, so yesterday's session requires an elapsed-time check. Switching models; changing reasoning effort, context size, or enabled tools; or exceeding the inactivity window invalidates reusable cached context. Re-verify the windows before delivery
5. /context — it breaks context usage down across instructions, system/MCP tools, messages, free space, and buffer
6. /add-dir — add only the required sibling directory instead of broadening the working root to the entire parent

Part B: There's no single correct number — a good answer names a specific credit amount tied to the task's typical cost (for example, based on past /usage data or Chronicle cost tips), writes a syntactically valid /limits set max-ai-credits NUMBER command, and names a concrete next step (for example, "review what's been done so far, then raise the limit only if the remaining work is clearly scoped"). GitHub recommends a value above 30 credits because most model calls cost more than 20 credits.

Part C — model handoff (compare with your own; wording will differ, the six fields should not):

A weak handoff usually fails in field 4 or 5: it re-states the symptom but not the decisions already made, so the new session re-litigates the design and spends credits re-deriving a settled answer.

Success Criteria

• ✅ You correctly chose "new session" for Scenario 1
• ✅ You correctly chose "/context, then /compact if warranted" for Scenario 2
• ✅ You correctly chose "new session" for Scenario 3
• ✅ For Scenario 4, you checked the applicable cache-expiration window and named at least one cache invalidator
• ✅ You chose /context for Scenario 5 and /add-dir for Scenario 6
• ✅ Your session limit worksheet names a specific credit amount, includes a valid /limits set max-ai-credits NUMBER command, and states a concrete next step
• ✅ You either completed the no-prompt set/unset checkpoint or correctly described its expected confirmation and cleanup
• ✅ You identified sessionLimits.maxAiCredits as the equivalent Copilot SDK setting
• ✅ Your handoff fills all six fields and names specific paths rather than "the repo"
• ✅ Your handoff records at least one decision that must not be relitigated and one explicit out-of-scope constraint
• ✅ Your handoff ends with one next action and a stop condition
• ✅ You can explain why the handoff complements rather than replaces /compact, /resume, and VS Code /fork

Workshop Section: 4 — Model Strategy, Verification & Before/After Evaluation

Roles

• Work individually, then discuss as a table

Starting State

Use the supplied model scenarios, fixed task set, scoring rubric, and before/after results. Do not run the tasks against a live model unless the facilitator has approved that optional variation.

Part A — Model, Verification & False-Economy Scenarios (7 min)

Use this full-cost comparison for Scenario 5:

For each scenario, decide (a) Auto or a manual model choice (and if manual, lightweight or powerful), and (b) one quality-first verification step to pair with it. For Scenarios 4 and 5, also write the false-economy mistake that a token-only decision would make:

Part B — Before/After Evaluation Worksheet (5 min)

A team ran the same frozen set of 6 representative tasks, each with a written acceptance rule, to test one question: does trimming always-on context help? No live calls are needed here — the arms below are supplied.

Stated assumptions: 1 AI credit = $0.01 USD; human review and rework valued at an illustrative blended $100/hour; durable acceptance means the result passed its written acceptance rule without material correction and stayed valid through the team's stabilization period.

Complete the worksheet:

Optional and billable: if you later run this loop for real, capture the numbers with /usage and /context in Copilot CLI, the CLI Chronicle session data and cost tips, and whatever cost or session signals your IDE exposes. That is optional instrumentation, not a requirement of this lab.

Answer Key

Part A:

Part B:

Reading the numbers: AI credits are the small share of full cost in every arm here. That is the point of full cost per durable accepted outcome — a change that saves credits while lowering acceptance moves cost onto people, where it is larger and less visible. With 6 tasks, this is a directional team-level answer, not a statistically robust organization-wide claim.

Success Criteria

• ✅ You chose a lightweight model (or Auto) for Scenario 1 and named a linting/formatting check
• ✅ You chose a powerful/reasoning model for Scenario 2 and can justify why
• ✅ You chose a cheaper, scoped model for the Scenario 3 subagent
• ✅ You correctly diagnosed Scenario 4 as over-provisioning power without justification, and named Auto as the more efficient default
• ✅ You chose the powerful model for Scenario 5 based on full cost per durable accepted outcome and named the evidence required before making it a default
• ✅ You explained why Scenarios 4 and 5 cannot be decided from per-attempt token cost alone
• ✅ Your three per-outcome figures match the answer key ($75.93 / $40.52 / $225.90, ±$0.01 rounding)
• ✅ You decided to keep Arm B on both cost and acceptance grounds, not cost alone
• ✅ You identified that Arm C changed two variables and was cheapest in credits while being worst in full cost
• ✅ Your own loop names one variable, a frozen 5–10 task set, and an acceptance rule written before the run

Workshop Section: 5 — Hands-On Optimization Capstone & Close

Roles

• Work individually or in pairs

Starting State

Bring forward one useful decision from each prior lab, or use the workshop examples if you joined late. Start with the blank four-week worksheet below.

Steps

Draft a one-page 30-Day Habit Plan worksheet. The Description column is verbatim from the workshop guide's capstone list:

Success Criteria

• ✅ Your plan names one specific interface change for Week 1
• ✅ Your plan names one specific instructions/customization trim and one memory review for Week 2
• ✅ Your plan names one specific, testable session-boundary rule for Week 3
• ✅ Your plan names a model choice, a deterministic verification step, and one change you will evaluate with a fixed task set for Week 4