Take the method. Change the context.

# Agent task scope card

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/how-to-scope-an-ai-agent-task/

Purpose: turn a loose request into a bounded task before an agent acts, so it can move fast inside the edge and pause at it.

Output: one runnable task brief with an observable outcome, a two-way boundary, explicit authority, chosen evidence and stop conditions.

## Use when

A request such as “fix the page”, “research this” or “make it better and ship it” is about to reach an agent that can read files, call tools or change external state.

## Quick start

1. Write the outcome as a state someone can observe, not as an activity.
2. Answer the five parts in order: outcome, boundary, authority, evidence, stop.
3. Size the brief to the risk, paste the copy-ready brief, and park follow-ups as questions.

# AGENTS.md starter

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/the-toolbench/

Purpose: give every coding agent in a repository the same short, testable house rules from one canonical file.

Output: an AGENTS.md of at most ~150 lines with exact commands, workflows, boundaries and a done check, read by each tool natively or through one pointer.

## Use when

Several agents or tools share one repository, an agent repeats a mistake a teammate would not, or tool instruction files have drifted.

## Quick start

1. Copy the skeleton in section 2 to `AGENTS.md` at the repository root and replace every [bracket].
2. Run one representative task three times with and three times without the file (section 3); keep only what changed the result.
3. Point every other tool at this file (section 5). Copy it only for a tool that can neither read nor import it, and regenerate that copy after every edit.

# Authority line card

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/position-sizing-for-agent-autonomy/

Purpose: size an agent’s authority by reversibility and consequence, not by what it is capable of doing.

Output: an action inventory with one class per action, limits per class, outlier stops, and a prepared action card for each human-only step.

## Use when

An agent can do more than read (edit, run, deploy, delete, message, pay or grant access) and you must decide where its authority ends.

## Quick start

1. List every action the workflow allows, including the ones you hope never happen.
2. Classify each by reversibility and blast radius, then set limits and outlier stops per class.
3. Paste the rule block into the agent’s instructions, and review the line with evidence after real runs.

# Skill contract (SKILL.md starter)

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/designing-skills-and-loops/

Purpose: turn one repeatable job into a skill that any capable agent can run and be judged by the same evidence standard.

Output: a filled contract, a SKILL.md that validates, and a trigger-test record.

## Use when

You keep giving agents the same instructions for the same class of work, or a skill only works when the agent guesses what its author meant.

## Quick start

1. Fill the contract in section 1 before writing any instructions.
2. Turn it into SKILL.md with the skeleton in section 2, in a directory named after the skill.
3. Run the validation checklist and the trigger test, and record what actually loaded.

# Loop contract

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/designing-skills-and-loops/

Purpose: bound a repeating agent loop so it ends on evidence, a budget or a human decision, never on the agent’s own confidence.

Output: a one-page loop spec with its class, exit rule, caps, gates and a record of every iteration.

## Use when

You want an agent to repeat work until something is true (fix until checks pass, draft until good enough, watch until a threshold is crossed) and must know how it stops.

## Quick start

1. Classify the loop with the test in section 1.
2. Write the exit rule before the first iteration: an exact predicate, or a rubric scored by an independent reviewer within a budget.
3. Set caps and gates, paste the spec from section 8 into the agent’s brief, and keep one record per iteration.

# Quiet monitor contract

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/the-quiet-monitor/

Purpose: build a monitor that stays quiet without going blind, and interrupts a person only when a decision is due.

Output: a one-page contract covering one monitor’s decision, record, states, routing, liveness, heartbeat and retirement.

## Use when

You are building or reviewing a scheduled check or feed watcher, or one has been green so long nobody knows what turns it red.

## Quick start

1. Name the decision the monitor serves and the threshold that justifies interrupting someone.
2. Give every source an honest state, and assert the subject exists before asserting it is healthy.
3. Wrap the job in a heartbeat so silence from the monitor itself raises an alert.

# Voice shorthand cheat sheet

Version: 1.3
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/voice-driven-development/

Purpose: turn short spoken phrases into consistent workflows without losing scope or authority.

Output: a copy-ready context rule and a personal phrase glossary.

## Use when

You dictate recurring instructions to an agent and want short phrases to expand into the same bounded procedure every time.

## Quick start

1. Copy the starter context block into the agent instructions you actually use.
2. Keep only phrases you invoke repeatedly; edit each expansion to match your tools and approval rules.
3. Test one phrase in a low-risk task and confirm the returned evidence is sufficient.

# Lean AI agent profile checklist

Version: 1.1
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/ai-agent-prompt-bloat/

Purpose: reduce fixed context and capability sprawl without removing the tools, evidence, or safety boundaries an agent needs for its actual job.

Output: one before-and-after profile record with a justified capability set and three comparable latency checks.

## Use when

An agent feels slow, overcomplicated, too eager to use tools, or loaded with capabilities unrelated to its job.

## Quick start

1. Write the profile’s one-sentence job (section 1) before removing anything.
2. Capture the fixed-context report and the three latency checks, then change one capability group at a time.
3. Repeat the same report and checks, prove the core task and the approval gates still work after a restart, and record the decision.

# Verification checklist

Version: 1.3
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/the-verification-loop/

Purpose: prove that a change produced the intended result on the real surface.

Output: one evidence record that another person can reproduce.

## Use when

A result looks complete, but you still need evidence that the user outcome works and nearby behaviour did not regress.

## Quick start

1. Replace the claim below with one sentence that can be proven false.
2. Record one before-state, test the changed path, one neighbouring path, and one failure path.
3. Attach evidence from the released artifact—not only the implementation or its success message.

# Live-truth curl checklist

Version: 1.3
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/live-truth-before-local-assumptions/

Purpose: establish what a public host serves before trusting a local checkout.

Output: a response report plus the deploy, revision, and editable source that own it.

## Use when

You need to identify the real response, redirect path, canonical host, visible build markers, and likely source owner before editing or releasing.

## Quick start

1. Set `HOST`, `PATH_TO_CHECK`, and an optional `EXPECTED_MARKER` in the script.
2. Save it as `live-truth.sh` and run `bash live-truth.sh` (do not paste it into an open shell: it calls `exit`). It only performs read-only network requests and cleans up its temporary files.
3. Compare the report with the hosting provider’s active deploy and the candidate repository revision.

# Worktree freshness preflight

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/stale-worktree-that-passed/

Purpose: prove which tree a check ran against before its green result counts as evidence.

Output: a preflight record for each check: tree, revision, freshness against the base, other worktrees and a served-bytes match.

## Use when

Several agents or people work in parallel worktrees, and a passing build, test suite or browser check is about to be accepted as proof that a change is safe to release.

## Quick start

1. Run the preflight (section 1) with `--fetch` in the tree you are about to test. Clear every STOP line.
2. Prove the server your checks hit serves this tree’s bytes, and that untouched files and routes match production (section 2).
3. Record both next to the check’s result (section 3) before anyone reads it as a pass.

# Observer-first triage card

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/diagnose-the-observer-first/

Purpose: locate the layer that owns a failure before anyone changes a system that may not be broken.

Output: a short incident note with the observer, sideways results, failing layer, evidence window and an ownership decision.

## Use when

Someone reports “it’s down”, “it’s slow” or “the job failed”, and all you have is one viewpoint’s symptom.

## Quick start

1. Rewrite the report as one observation: who saw what, where, when, with the exact result.
2. Move sideways once (another device, network, account, region or client) before probing deeper.
3. Climb the read-only ladder and change nothing until one layer clearly owns the failure.

# Provenance ledger

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/provenance-before-conclusions/

Purpose: let every conclusion travel backwards—from claim, to transformation, to the exact bytes it came from.

Output: an archive with untouched raw files, a hashed manifest, a claim ledger, a rerun recipe and a written rejection test.

## Use when

You are about to analyse downloaded or agent-collected data, and someone will later ask where a number came from, whether it still holds, or why the work stopped.

## Quick start

1. Create the layout in section 1; fetch every source with the section 3 script so each file gets its manifest line on arrival.
2. Record failures, blocks and empty responses as observations, never as “no data”.
3. Write each claim with its files, derivation, period and caveat, plus the result that would make you drop it.

# Agent eval set starter

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/tool-calling-at-250k-context/

Purpose: measure whether an agent still does its job after a change, with graders you have tested and results you can repeat.

Output: a small task set with validated graders, a results record with pass rates, and a ship or hold decision.

## Use when

Before you change the model, prompt, tools, skills, context size or harness behind an agent that does real work, or after an incident you never want to repeat.

## Quick start

1. Define the job, then write tasks from real work and real failures, including tasks where the agent should not act.
2. Run every grader on a known-good and a known-bad output before trusting any score.
3. Run several trials per task, read the failed transcripts, and apply the decision rule in section 8.

# Policy-as-a-test kit

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/policy-as-a-test/

Purpose: turn a written decision into a check that fails at the moment a person or an agent undoes it.

Output: a rules file and check script wired into pre-commit, CI and the release gate, plus a blind-spots list and a named reviewer.

## Use when

A decision lives only in a brief or context file (a retired endpoint, a removed flag, a renamed feature) and new sessions keep reintroducing it.

## Quick start

1. Write each decision as an invariant that a file or build output can visibly violate.
2. Put exact strings in the rules file and run the check where changes land: pre-commit, CI and the release gate.
3. List what the check cannot see and name who reviews that part.

# Context disclosure gate

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/context-without-oversharing/

Purpose: give each audience the minimum context it needs to act correctly, and nothing that identifies, exposes or leaks.

Output: a classified context list, a public-safe task packet and a Pass or Hold verdict from the disclosure gate.

## Use when

You are about to put working context into an agent prompt, a rule file, an issue, a screenshot or a public page.

## Quick start

1. Name the audience, the artifact’s lifetime and the action it enables.
2. Sort every fact into one of four classes, then keep, transform or remove it by class.
3. Run the scan and the gate on the source and on the rendered result.

# Tool and prompt-injection review

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/insights/ai-agents-in-production/

Purpose: decide whether an agent may use a tool or MCP server, and with which limits, before untrusted content can steer it.

Output: intake records, a trifecta check per configuration, canary results and a decision: approve, approve with limits, or reject.

## Use when

Before an agent gains a tool, MCP server, skill or plugin; when one updates; or when an agent reading untrusted content gains a way to write, send or fetch.

## Quick start

1. Fill an intake record per tool from its code, configuration and live tool list, not its README.
2. Run the trifecta check on every configuration that will load it; break any full trifecta.
3. Plant harmless canaries, run the test plan, and record the decision with its limits.

# Page removal checklist

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/the-page-you-deleted-is-still-being-served/

Purpose: retire a URL everywhere it is still claimed, not only at your origin.

Output: one removal record per URL, closed by a dated check from outside your infrastructure.

## Use when

You are deleting, merging or redirecting a page, and search results, feeds, previews or caches may keep its old claim alive.

## Quick start

1. Pick one end state per URL (section 1).
2. Clear the surfaces you own, then report the old URL as well as the new one (sections 2–3).
3. Run the outside check, then recheck the result page until the old claim is gone (section 4).

# Brief to page brief

Version: 1.3
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/from-brief-to-published-page/

Purpose: turn a loose topic into a page where every section earns its place.

Output: a page sequence, evidence plan, interaction contract, and release test.

## Use when

A note, spoken request, or broad topic needs to become one coherent page rather than a pile of sections.

## Quick start

1. Write the reader promise and truth boundary before proposing sections.
2. Give each section one reader question, one job, and one proof point.
3. Remove repeated jobs, then define the next action and release conditions.

# Multi-agent routing card

Version: 1.3
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/parallel-agents-without-collisions/

Purpose: parallelise independent work without creating file, decision, or release collisions.

Output: bounded lane assignments and one serial integration plan.

## Use when

Two or more agents can produce independent artifacts from the same stable inputs.

## Quick start

1. Apply the split test. If lanes share an unresolved decision, keep the work serial.
2. Give every write surface one owner and every lane an acceptance check.
3. Freeze lane outputs, then integrate and release from one named owner.

# Adversarial review brief

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/the-agent-never-touches-the-button/

Purpose: hand a change to an independent reviewer whose only job is to find where it is wrong.

Output: a findings table, evidence-checked responses and one verdict that names what would change it.

## Use when

A wrong “looks good” would be costly: the change is hard to undo, brings its own tests, touches security or release state, or only its author has checked it.

## Quick start

1. Bundle the artifact, the original request, the claim, the acceptance criteria and the evidence offered — not the author’s narrative.
2. Give the bundle and the brief in section 3 to a fresh reviewer, ideally a different model or tool.
3. Verify every finding before acting on it, then record one verdict.

# Agent handoff packet

Version: 1.3
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/handoff-packets/

Purpose: let a new operator continue safely without replaying the previous conversation.

Output: a standalone state packet with one bounded next action.

## Use when

Ownership is changing, work is pausing, or another person or agent must continue from the current state.

## Quick start

1. Complete the one-screen handoff first. If that is insufficient, fill the expanded evidence sections.
2. Record observable state and exact artifacts; do not narrate every action taken.
3. Give the recipient one safe next action and the conditions that must stop it.

# Long-running progress file

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/handoff-packets/

Purpose: let an agent that starts every session blank resume multi-session work from recorded state, not guesswork.

Output: a progress log, a JSON feature list and an init script that a fresh session can read and run in minutes.

## Use when

Work will span many sessions or context windows, and each session must start where the last one stopped — without rebuilding the state or declaring the job done early.

## Quick start

1. In the first session, create the three files in section 1 and commit them.
2. Open every later session with the start ritual and close it with the end ritual.
3. Mark a feature passing only after its end-to-end steps were run and observed.

# Durable memory entry

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/the-cookbook/

Purpose: capture one durable, non-obvious fact so the next session starts from it instead of rediscovering it.

Output: one small memory file with the fact, its reason and how to apply it, plus one index line that makes it findable.

## Use when

A task surfaced something worth knowing next time — a root cause, a false alarm, a rejected approach, a preference and its reason — and nothing already records it.

## Quick start

1. Run the test in section 1. Most task notes fail it, and that is correct.
2. Search the index for an entry that already covers it; if one does, update that entry.
3. Otherwise write one fact per file in the format of section 2, with why it is true and how to apply it, and add one index line.

# Decision ledger

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/decision-ledgers/

Purpose: keep every inherited rule together with its reason, its evidence and the event that should reopen it.

Output: a compact, append-only ledger whose rules can explain themselves after the original conversation is gone.

## Use when

Long-running agent work keeps inheriting rules, and someone is about to obey an old rule blindly or drop a sound one because its reason is invisible.

## Quick start

1. List the rules a new agent would be tempted to question, and write one entry for each (section 1).
2. Give each entry a status and an observable review trigger (sections 1 and 2).
3. From then on, append evidence before changing any rule, and record every review outcome (sections 3 and 4).

# Pre-merge contamination sweep

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/the-branch-that-predates-the-decision/

Purpose: stop a branch cut before a decision from quietly restoring the facts the decision retired.

Output: a sweep verdict for every branch older than the decision, and a check that fails such merges on its own.

## Use when

A decision retired names, routes, identifiers or claims while branches were open, especially agent branches that will merge without conflicts.

## Quick start

1. Record the decision with its literal search list (section 1).
2. List the branches that predate it (section 2) and sweep each one (sections 3–4).
3. Classify every hit and fix forward (sections 5–6), then make CI enforce the list (section 7).

# Agent incident review

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/when-success-is-still-broken/

Purpose: turn an agent failure into fixes aimed at the layer that failed, without blaming a person or “the AI”.

Output: a blameless review with a UTC timeline, the agent’s quoted inference, root-cause classes and verifiable action items.

## Use when

An agent reported a success that was not true, or took or skipped an action it should not have, and the result reached users, data or a release.

## Quick start

1. Contain first, then preserve the transcript, tool-call log, configuration and permissions as they were.
2. Fill sections 1–6 from those records, quoting the agent verbatim; never reconstruct from memory.
3. Classify the root cause, then give every action item an owner, a due date and a verification.

# Local-or-cloud routing card

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/local-uncensored-models/

Purpose: decide, job by job, whether work runs on a local model, a cloud model, either, or stays with a person, before data or authority moves.

Output: a dated routing table with a verdict and reason per job, an escalation rule and the triggers that force a re-test.

## Use when

You are adding a local model beside cloud models, or a new job, data class, model, price or policy raises the question of where work should run.

## Quick start

1. List the recurring jobs and the most sensitive data each one touches.
2. Mark the steps that need authority, then answer the data question (may this leave the machine?), then score the rest from your own measurements.
3. Write one verdict per job (Local, Cloud, Either or Human), the escalation rule and the date.

# Local model memory worksheet

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/insights/local-model-quantization-guide/

Purpose: work out whether a model, quantization and context fit your memory before you download, launch or blame the model.

Output: a filled worksheet with weights, KV cache per token, the total at your context and concurrency, and a chosen weight precision, KV precision and context.

## Use when

You are choosing a quantization or context length for local inference, or a set-up runs out of memory or slows sharply as context grows.

## Quick start

1. Take the weights figure from the model files on disk.
2. Compute KV bytes per token from the model’s `config.json`, then multiply by context and concurrent sequences.
3. Add measured overhead and headroom. If it does not fit, cut context or weight precision; test any KV precision change before trusting it.

# Local model test contract

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/local-model-field-notes/

Purpose: turn a local model trial into a dated record that another person can rerun and trust.

Output: one contract with an identity record, separate prefill, decode and end-to-end numbers, pass rates, usable context and an Adopt / Test / Drop verdict.

## Use when

You are about to rely on a local model, quantization, runtime or machine for real work, or to compare two local set-ups.

## Quick start

1. Name the job, its category and its pass condition before running anything.
2. Fill the identity record from files and logs, not memory, and hash the model file.
3. Measure prefill and decode separately at stated depths, with repeats, then grade your own tasks several times.

# Long-context instruction test

Version: 1.0
Updated: 2026-10-02
Method: https://suhailmohebi.com/notes/tool-calling-at-250k-context/

Purpose: find out whether rules stated at the top of a long window still govern answers and tool calls made at the bottom.

Output: a graded results table per depth, with pass rates and cache state, and a decision on the depth you may rely on.

## Use when

You plan to run an agent or long-document job deep into a local model’s window, or a model, quantization, runtime or KV-cache change touches long-context behaviour.

## Quick start

1. Write 3–5 standing rules and 6–10 cases whose checks are graded in code.
2. Prove the grader on known-good and known-bad outputs before any model run.
3. Build prompts at several fractions of the configured window, run each depth several times and record every run’s cache state.