The Practitioner Toolkit

The operating loop

The Move Card

The Move Card is the primary operating artifact of Extreme Contexting. Use it before asking AI to do meaningful work.

The Sufficiency Check

The Sufficiency Check produces the Context Packet. Before generating, ask:

• What is the job?
• What must the AI know?
• What must the AI not do?
• What examples define good output?
• What proves success?
• What context can be removed?
• What should be captured afterward?

The Context Packet

A Context Packet is the bounded set of material given to the AI for a specific move. It may include: Move Card, relevant files, examples, constraints, source material, tests, acceptance criteria, architecture notes, prior decisions, known gotchas, style rules, validation rules.

The Verification Contract

A Verification Contract defines what must be true before the AI output is accepted. Examples:

• All tests pass.
• No new dependencies are introduced.
• The patch changes only the requested files.
• The generated function matches the existing interface.
• The draft cites only approved sources.
• The article includes a decision table.
• The output does not recommend vendors.
• The migration is reversible.
• The summary preserves the original argument.

Verification can be automated or human-reviewed. The form matters less than the discipline. AI output is not accepted because it sounds right. It is accepted because it passes a defined check.

Verifying subjective work

Subjective work still needs pre-declared verification. The trick is not to eliminate judgment. The trick is to translate taste into observable features, exclusions, examples, and failure conditions before generation begins.

Verification Contract — editorial example

Move: Draft a homepage introduction for a technical methodology site.

Voice:

• Uses direct, declarative sentences.
• Avoids hype, metaphor stacking, and motivational language.
• Sounds like a practitioner explaining a hard-won operating rule.
• Does not use corporate phrases like "unlock value," "drive transformation," or "seamless innovation."

Structure:

• Opens with the practical problem, not a definition.
• Introduces one governing distinction in the first 150 words.
• Includes one concrete operational example.
• Ends with a decision or action, not a summary.

Failure conditions:

• Reads like generic thought leadership.
• Uses AI hype language.
• Makes claims without an example.
• Adds concepts not present in the brief.
• Sounds polished but does not clarify the work.

The "Do Only This Move" prompt frame

This is the most reusable prompt pattern in the toolkit.

That final sentence matters. It prevents the model from combining discovery, implementation, refactoring, documentation, and strategy into one uncontrolled pass.

The Agentic Sequence Contract

A Move Card governs one bounded step. An Agentic Sequence Contract governs a bounded run. The sequence contract does not replace Move Cards; it declares which moves may be created or executed, where the agent must stop, and what verification gates must pass before continuing.

Three practitioner stances

Model fit and sufficiency

Model choice runs in two directions:

• Move → Model: What kind of model behavior does this move require?
• Model → Context: Given this model's behavior, what must the context packet make more explicit?

Calibration examples

Exploratory draft model:

• Give a sharper output boundary.
• Include stronger exclusions.
• Expect useful variation.
• Verify against direction, structure, and failure conditions.

Strict instruction-following model:

• Make the desired structure explicit.
• Avoid ambiguous tradeoff language.
• Provide examples of acceptable output.
• Verify completeness and constraint adherence.

Long-context model:

• Use indexes and routing anyway.
• Do not load everything by default.
• Watch for stale or contradictory context.

Code-editing model:

• Include exact files, tests, commands, and protected paths.
• Require diff-level verification.
• Prefer smaller blast radius.

Decomposing large work

1. Name the outcome. What should be true when the work is done?
2. Identify the seams. Where can the work be divided safely?
3. Identify the risky unknowns. What could make this fail?
4. Convert unknowns into discovery moves. What must be understood before implementation?
5. Convert behavior into verification contracts. What must be proven before acceptance?
6. Implement in thin slices. What is the smallest useful change that can be inspected?
7. Refactor after behavior is locked. What structure can be improved once correctness is proven?

Software example

Bad move

Build the authentication system.

Better sequence

1. Summarize the current authentication flow.
2. Identify where permissions are enforced.
3. List existing tests related to roles.
4. Write failing tests for the missing permission behavior.
5. Implement the smallest change that passes those tests.
6. Refactor duplicated permission logic.
7. Update the auth notes with the new invariant.

Move Card example

Editorial production example

Bad move

Write the article.

Better sequence

1. Define the article's job in the portfolio.
2. Identify the reader and decision the article should support.
3. Gather only the approved source material needed.
4. Draft the opening claim and section structure.
5. Generate the article from the brief and source constraints.
6. Validate citations, audience fit, structure, and boundary drift.
7. Revise only the failed sections.
8. Convert the final draft into the delivery artifact.
9. Capture any recurring failure as a rule, gotcha, or validator update.

Move Card example

Decision-support analysis example

Bad move

Analyze the vendor options.

Better sequence

1. Define the decision the analysis must support.
2. Identify the decision maker and acceptance criteria.
3. Gather only the relevant source material.
4. Separate facts, assumptions, risks, and unknowns.
5. Draft a comparison matrix.
6. Verify claims against source material.
7. Identify unresolved questions.
8. Produce the recommendation only after evidence is checked.
9. Capture any recurring ambiguity as a better evaluation rule.

Move Card example

Failure diagnostics

When AI output fails, inspect the context before simply asking again.

• Was the move too large?
• Was the intent ambiguous?
• Was the wrong file included?
• Was a necessary file missing?
• Were examples contradictory?
• Were exclusions missing?
• Was verification undefined?
• Did the model have to infer the sequence?
• Did the context contain stale instructions?
• Was the output accepted for plausibility instead of proof?

Repeated failure is a context design signal.

The Context Ledger

Use a Context Ledger to preserve durable lessons.

Lifecycle

• Capture: Record the failure, correction, or discovery.
• Review: Decide whether the entry is recurring, still relevant, and specific enough to act on.
• Promote: Move repeated lessons into rules, tests, validators, examples, architecture notes, or workspace conventions.
• Prune: Remove duplicate, stale, low-signal, or overly broad entries.
• Archive: Preserve history without keeping it in active context.

Entry template

Example entry

Anti-patterns

The cure is usually: smaller move, sharper context, clearer verification, durable capture.

Monday-morning checklist

Use this when starting real work.

1. 01Write the desired outcome in one sentence.
2. 02Choose the next verifiable move.
3. 03Fill out a Move Card.
4. 04Run the Sufficiency Check.
5. 05Assemble the Context Packet.
6. 06Define the Verification Contract.
7. 07Ask the AI to complete only that move.
8. 08Review the result against the contract.
9. 09Refactor the output or the context.
10. 10Capture anything that should persist.
11. 11Choose the next move.

Not a giant prompt. Not a magic workflow. A disciplined loop.