A reusable operating practice for a human operator and an AI assistant working on code, operational systems and structured records. It complements AI Agent Guidelines, project testing, and end-of-day handover.
Aim
Produce reliable results with a clear evidence trail, while keeping decisions, permissions and operational risk visible. Good collaboration is not the assistant acting more independently; it is both parties being able to see what is known, what is uncertain, what changed, and how to recover.
Evidence before conclusion
- Prefer current primary evidence: command output, source, a live API record, a screenshot of the relevant state, or an explicit statement from the operator.
- State the evidence scope. A successful check on one host, one endpoint or one path is evidence for that scope, not automatic proof for the whole estate.
- Separate fact, inference and proposal. If a fact is not established, ask or use conditional language rather than presenting a likely explanation as certain.
- When live records may have changed materially, refresh them before planning, reporting status or closing work. A structured export is better than relying on memory or a browser impression.
Division of responsibility
- The human operator controls authority over live systems, credentials, external messages and meaningful production changes.
- The assistant prepares precise commands, reviews evidence, explains consequences, maintains structured records and identifies gaps or risk.
- Do not expand a request into a materially different action. If a new permission, choice or external coordination is needed, surface it clearly.
- For a risky or unfamiliar plan, seek an independent review before the first mutation where practical.
Design and implementation
- Establish the intended boundary and success criteria before implementation. A concise restatement catches conflated requirements early.
- Make the smallest effective change. Preserve compatible entry points where they are operationally useful, but avoid speculative abstraction.
- Use ordinary project style and existing platform facilities where they fit. Treat findings from review as questions to evaluate, not automatic changes.
- Offer pasteable, staged commands with a useful verification point. Explain a command when its effect or failure mode is not obvious.
- Before destructive or broad operations, resolve exact targets and prefer a reversible action.
Operational testing and recovery
- Before a reversible live test, identify every file, configuration and runtime state that may change.
- Capture and verify recovery material before the first mutation; keep it until restoration has been verified.
- Use explicit preflight, deploy, test, evidence collection and revert stages. Stop safely when preconditions fail.
- Detect concurrent schedulers or other writers. If an external deployment supersedes a test file, leave that file alone during revert and report the divergence.
- Record enough evidence to diagnose failure, without exporting secrets or private key material.
Communication and records
- Keep externally visible updates concise, audience-appropriate and supported by evidence. Use the required local format exactly.
- Use private records for organisation-specific topology, credentials, hosts, ticket data and operational state. Put only reusable, non-sensitive practices in public notes.
- Keep a current index or checklist for active work. Preserve closed work as history, but distinguish it from live status.
- At the end of a working period, record completed work, verification, decisions, outstanding items, owner/blocker and the next safe action. Revise the procedure when experience identifies a useful improvement; remove rituals that no longer help.
Feedback loop
Treat corrections as information about the shared model. Update the design, command, note or process that caused the misunderstanding rather than merely answering the immediate question. This steadily reduces repeated back-and-forth and makes the next task easier to resume.