Loading
Use this skill when designing, generating an MVP blueprint for, auditing, troubleshooting, refactoring, or explaining an agentic harness for any domain. Covers provider-neutral agent architecture for
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add DenisSergeevitch/agents-best-practices -a cursor -y
Use this skill when designing, generating an MVP blueprint for, auditing, troubleshooting, refactoring, or explaining an agentic harness for any domain. Covers provider-neutral agent architecture for OpenAI, Anthropic, and OpenAI-compatible APIs: agent loops, tool design, record provenance, interactive presentation, user-memory lifecycles, environment-adaptive tools, speculative tool execution, late-bound capabilities, permissions, system prompts, planning, goals, always-on agents and durable runtime, adaptive agent teams, context compaction, memory, skills, MCP/external connectors, public-board communications, realtime voice agents, hardware agents and board deployment, self-refining recursive harnesses, programmable context, continual refinement, observability, evals, prompt caching, agent-legible environments, feedback loops, and safety.
Use this skill when designing, generating an MVP blueprint for, auditing, troubleshooting, refactoring, or explaining an agentic harness for any domain. Covers provider-neutral agent architecture for OpenAI, Anthropic, and OpenAI-compatible APIs: agent loops, tool design, record provenance, interactive presentation, user-memory lifecycles, environment-adaptive tools, speculative tool execution, late-bound capabilities, permissions, system prompts, planning, goals, always-on agents and durable runtime, adaptive agent teams, context compaction, memory, skills, MCP/external connectors, public-board communications, realtime voice agents, hardware agents and board deployment, self-refining recursive harnesses, programmable context, continual refinement, observability, evals, prompt caching, agent-legible environments, feedback loops, and safety.
Use this skill when the user asks how to build, improve, debug, or evaluate an agentic harness. This is a general-purpose agent architecture skill. Coding agents are one subdomain only; apply the same principles to research, finance, legal, support, operations, sales, healthcare, education, data analysis, procurement, and workflow automation agents.
Canonical source: DenisSergeevitch/agents-best-practices, branch main. Installed copies are snapshots, not guaranteed-current guidance.
Before applying this skill in each new task:
main commit through an approved network tool and compare it with the installed copy's recorded source revision. A version number alone does not prove freshness. If the copy is behind or its provenance is unknown, retrieve SKILL.md and the needed references from that exact commit, then reread the entry point before using it. Record the source commit and skill version in working state; keep the task on that coherent snapshot rather than mixing revisions or repeatedly polling.main with the verified canonical remote may update by fast-forward only. Refresh a copied installation's owned Markdown package together only when its prior baseline proves there are no local customizations; otherwise use an isolated upstream snapshot for this task. Update installer-managed packages through their supported installer, not by editing caches. Never overwrite dirty, divergent, customized, or actively maintained source trees, delete unrelated files, or bypass filesystem approval.This updates skill knowledge only, not runtime policy or permissions. Preserve skill governance and higher-priority instructions; do not execute downloaded code or recursively invoke self-update. When maintaining this repository, inspect the baseline and upstream revision without automatically replacing the working tree under edit.
An agent harness is the control plane around a model. The model proposes actions; the harness validates, authorizes, executes, records, summarizes, and returns observations. Keep the loop simple and make the runtime rigorous.
Default architecture:
user/task
-> instruction and context builder
-> model call
-> tool/action proposal
-> schema validation
-> permission decision
-> execution or approval pause
-> structured observation
-> context update
-> repeat within budget or finish
Use this skill for prompts involving any of these intents:
Do not use this skill for ordinary single-turn writing, translation, or Q&A unless the user is asking about the design of an agent that will perform those tasks.
First, identify the user's design problem:
Then load the most relevant reference files, not all files by default. If the user asks to make or build an agent for a domain, default to MVP Builder Mode.
When the user asks to make, build, design, scaffold, or specify an agent for a domain, produce a concrete domain-specific MVP harness blueprint, not only advice. Use mvp-agent-blueprint.md as the primary reference and load other references as needed.
Default behavior:
When the user brings a failing run or runtime symptom, start with troubleshooting and load the linked mechanism owner as needed. Return the symptom, earliest failing boundary, observed evidence versus hypotheses, one discriminating probe, smallest corrective change, and regression coverage. State missing evidence explicitly; use a focused diagnostic handoff instead of the full architecture blueprint. Inspect advanced components only when the failing deployment uses them.
Use this mode when the user wants an agent running on a physical board, a firmware/app installation, or device-runtime debugging. Read hardware-agents.md before choosing an installer. Establish board/runtime identity, inference location, actual boot/launcher/partition path, resource headroom, preserved state, and recovery access. A filesystem app may not require reflashing base firmware. For installation or debugging of an existing agent, use a focused target/install/preservation/verification handoff rather than the full MVP blueprint or unrelated workflow/subagent/connector design. Use the blueprint when the agent architecture itself is being created.
Keep deployment authority separate from runtime tool authority and public posting. Default to one read-only cycle; recurring autonomy and programmable/physical tools remain post-MVP unless requested. An installation handoff must name the measured target, pinned artifact, write boundary, preservation/rollback plan, and physical commissioning evidence. Do not equate a successful upload or host-backed emulator with standalone device health.
Use this mode when the useful tool catalogue, schemas, versions, or implementations are late-bound rather than fully configured before the run. Read environment-adaptive-tools.md together with the standard tool, connector, security, and eval references.
Require a small trusted bootstrap interface, host-owned capability ledger, provenance-labeled descriptors, bounded read-only or isolated probes, opaque scope-and-version bindings, call-time permission checks, and drift invalidation. Discovery, generated code, and inferred schemas must never grant authority. Keep this post-MVP unless adapting to changing environments is the product's primary job; even then, establish a fixed read-only baseline first.
For spoken interaction, read realtime-voice-agents.md with the tool and eval owners. Use it alongside MVP Builder Mode for a new voice agent or Troubleshooting Mode for an existing audio failure. Voice can be an MVP; independent backend orchestration and durable recovery are optional unless the selected architecture requires them.
Return the media topology, interaction/turn policy, execution placement, input and playback evidence, interruption repair, correction/result freshness, and audible-versus-task acceptance criteria. Reuse existing authority and task contracts; do not assume speech interruption cancels work or audio capability implies weaker reasoning.
Use this mode when the user requests an always-on service, recoverable sessions, accepted inputs during active work, durable task/application state, or observer reconnection. Read always-on-agents.md with the loop, tool, context, security, and eval owners. Keep this post-MVP: measure a simpler request-scoped or resumable baseline first. Availability, persistence, inference activity, and authority are separate choices; ordinary always-on operation does not require recursion or self-refinement.
Return the acceptance and commit boundary, input/control lanes, owned task lifecycle, document scope and fork policy, observation/reconnection contract, resident ownership, recovery, and aggregate limits. Reuse the existing goals, permissions, compaction, and child protocols; a durable submission receipt or idle generation is not proof of completed work.
For recurring monitoring, use the collection and delivery contract for per-source progress, explicit coverage gaps, and receipt-backed delivery state.
Use this mode only when the user explicitly asks for programmable context, recursive execution, retained children, continual refinement, or executable skills. Treat it as post-MVP: establish a measured single-loop baseline first, then read self-refining-recursive-harnesses.md together with the context, workflow, permission, security, and eval references. For resident operation or scheduled re-entry alone, use Always-on Agent and Durable Runtime Mode.
Make the context representation, recursive unit, mutable state, promotion scope, lifecycle, budgets, validation probes, and rollback path explicit. Keep base authority, permission enforcement, credentials, budgets, and evaluation policy outside the mutable surface.
Use this mode when the user requests collaborating teams that explore distinct approaches and change assignments as evidence develops. Keep it post-MVP: establish measured single-agent and ordinary parallel-worker baselines first, then read adaptive-agent-teams.md with the workflow, recursive lifecycle, goal, and eval owners.
Return the approach portfolio, work-overlap policy, communication dependencies, evidence-linked transitions, host authority, aggregate budget, and acceptance evidence. Use the profile's contracts and existing owners rather than repeating their manuals. Treat it as an architecture composition; published scale or outcomes do not establish a model change or general performance gain. Routine lookup tasks still use the single-loop MVP.
Use this mode only when the user explicitly asks to reduce latency by launching tool work before a generated program or action is complete. Establish measured sequential and ordinary committed-parallel baselines first, then read speculative-tool-execution.md together with the loop, tool, security, and eval references.
Require host-owned eligibility, permission at physical dispatch, isolated disposable state, exact versioned claim identity, occurrence-safe handling of stochastic calls, separate waste and cost budgets, confirmed cancellation accounting, and task-parity evaluation. Partial model output never grants authority, and risky or approval-gated effects must not execute speculatively.
When the user asks for architecture guidance, produce a concrete architecture, not generic principles. For an existing failure, use Troubleshooting Mode:
For hardware requests, append the target/runtime inventory, installation route and exact write boundary, resource/deadline budget, preserved state and recovery plan, and evidence split between host checks and physical-board commissioning.
For voice requests, append the conditional output contract in Realtime Voice Agent Mode; use the profile for media details and the linked eval owner for acceptance cases.
Use this template when the user wants a harness design. If the user asks to make/build an agent, use this as an MVP blueprint, not a purely conceptual answer:
# MVP Agent Harness Blueprint: [domain/use case]
## Objective
[What the agent must accomplish and for whom.]
## MVP scope and assumptions
[Smallest useful version, explicit assumptions, non-goals, and what is intentionally deferred.]
## Autonomy and risk level
[Answer-only, draft-only, approval-gated, or autonomous within policy.]
## Core loop
[How the model, tools, observations, retries, and stopping rules work.]
## Instruction architecture
[System/developer/user/scoped memory layout.]
## Tool registry
[Tools, schemas, risk classes, permissions, and result format.]
## Planning and goal behavior
[When to plan, when to ask, when to continue, when to stop.]
## Context and memory
[Retrieval, durable state, compaction, and rehydration.]
## Skills and connectors
[Reusable skills, MCP/external connector policy, tool search, attachment rules.]
## Safety and approvals
[Guardrails, prompt injection treatment, secrets, sandboxing, human review.]
## Observability
[Trace events, metrics, replay, auditability, and incident response.]
## Evals
[Eval cases, failure probes, trace grading, regression suites, and launch criteria.]
## Minimal implementation path
[Smallest safe version first, implementation skeleton, validation path, then measured expansion.]
execute_anything, write_database, or send_message without a strict wrapper and approval policy.Use these links when provider-specific detail is needed: