Chapter BYour weekly AI habitPage 7 of 8

Your weekly AI habit

Work a full example

A worked project proves the method by showing decisions, failures, corrections, and evidence.

~12 minWorked example

Before you start

Why this matters

Without opening an AI tool, write the acceptance test for this job: run a thirty-minute weekly practice loop that improves one real workflow. Name one fact that must be exact, one judgment a person must make, and one condition that should stop the workflow. Compare your answer with the professional standard below; the gap is what you should practice.

1Learn the idea

Read

Project brief

The project is to complete four weekly cycles on one follow-up workflow and publish a before/after playbook with evidence. The user is a busy learner who wants durable skill rather than tool chasing. Definition of done: the intended action is clear, the candidate uses approved evidence, blocking safety checks pass, and another person can reproduce the key result.

Stage 1: prepare

Create the job card and collect one recurring task, baseline time/quality, a small prompt change, saved output, verification note, and retrospective. Remove or replace prohibited material: practice with synthetic or redacted material; keep a standing list of data that must never enter consumer tools and review vendor settings. Add one ordinary case, one boundary case, and one hostile or misleading case. Record unknowns instead of filling them with plausible guesses.

Stage 2: draft

This week I want to improve meeting-note follow-up. Baseline: 25 minutes and occasional missed owners. Design one 30-minute practice: a sanitized sample, one constrained prompt, a checklist for owner/date/source accuracy, and a five-minute retrospective. Keep the tool fixed and change only one prompting variable.

The first candidate should be A bounded weekly experiment with a baseline, one controlled change, an output check, and a decision to keep, revise, or discard the technique. In this worked run, imagine it also exhibits one realistic defect from this set: collecting prompts without testing; changing tool and task simultaneously; counting speed while quality falls; skipping reflection; automating before understanding. Do not hide the defect. Mark the exact criterion it violates and decide whether the cause belongs to context, instruction, model capability, or the surrounding process.

Stage 3: repair narrowly

Issue a targeted revision:

Revise only the failed criterion identified below.
Preserve all verified content and the original output contract.
Do not add facts or assets.
Return the corrected artifact plus a one-line change note.
Failed criterion: [paste criterion and evidence]

A narrow repair keeps the review surface understandable. If the model cannot repair without new authoritative information, pause and obtain that information.

Stage 4: verify and release

Now compare against the baseline, verify every owner and due date against source notes, record failure cases, and repeat on a second sanitized example before adopting. Record pass/fail evidence for each criterion and have the named reviewer make the release decision. Consistency beats novelty. One checked experiment each week produces transferable judgment; browsing new tools without measuring work does not. Save limitations in language the audience can understand.

Read

Retrospective

The durable deliverable is not only the final result. It is a four-week practice log containing baseline, prompt versions, checked outputs, time/quality measures, failures, and adoption decision. Write what surprised you, which check found it, what you changed, and which control should become the default. A clean retrospective distinguishes a prompt improvement from a data, tool, or policy change.

Checking tutor…

Continue learning · glossary & guides
  • Can the reviewer see the failed first attempt and why the correction was justified?
  • Does the release packet contain evidence, ownership, and known limitations?
  • Reference · Related concept
  • Previous
  • Next