Adoption checklist

Use this checklist when adding agent support to a repository or promoting a workflow into EOS. Start with the smallest useful slice and add complexity only when evidence calls for it.

Use the repository setup guide for the exact file layout and surface decision table before completing this checklist.

Repository readiness

• The root instructions are a short map, not a comprehensive manual.
• Architecture, product, security, reliability, and workflow knowledge has a versioned source of truth and an owner.
• Design documents, product specifications, generated references, active and completed plans, technical debt, and measured quality state are indexed or explicitly out of scope.
• Large or generated documents identify how they are produced and updated.
• Subsystem knowledge is scoped by path and discoverable from a parent index.
• Generated, built, vendored, secret, and irrelevant paths are excluded from routine agent discovery where the client supports it.
• Canonical install, build, lint, type-check, test, and change-summary commands exist and have concise output modes.
• The application and relevant UI, logs, metrics, or traces are observable from an isolated change environment where applicable.

Workflow candidate

• The workflow recurs often enough to justify maintenance.
• Its trigger, exclusions, inputs, outputs, and success criteria are clear.
• Deterministic mechanics are implemented in scripts or existing tooling.
• Judgement and mutation are separated where a report-first flow is safer.
• Side effects and required approvals are explicit.
• Templates, examples, and large references load only on demand.
• Local and CI execution use the same underlying checks.
• Verification preserves commands, results, skipped checks, and reviewable before/after evidence rather than only an exit code.
• Published libraries or CLIs are tested through a consumer-realistic install path where repository-local tests cannot cover packaging.

Distribution and safety

• Repository-local knowledge stays near the code; cross-repository practice has a central owner and versioned distribution path.
• The skill or plugin has positive, negative, and ambiguous routing tests.
• Third-party instructions, scripts, and updates receive code review.
• Hooks match the narrowest event and validate untrusted input.
• Project hooks have explicit trust/review behavior and a re-review path after changes.
• Hard command and filesystem boundaries use native rules, permissions, or sandboxing rather than relying on hook interception alone.
• Codex .rules entries include match/non-match cases and pass codex execpolicy check.
• Shell, filesystem, external tools, and network access each have explicit boundaries.
• Secrets are injected without exposing raw values to the model.
• Network destinations are restricted to those required for the task.
• Every MCP server documents tool authority, authentication, data class, approval, timeout, idempotency, and revocation.

Client setup

• Root and representative subtree launches load the intended instruction, skill, settings, and hook layers in every supported client.
• AGENTS.md and CLAUDE.md route to one canonical knowledge system rather than maintaining divergent standards.
• A CLAUDE.md symlink is verified in every supported environment, or a small routing file is used where symlinks are not portable.
• Repo-wide and subtree skills are in the correct discovery locations.
• Project .codex/config.toml contains no user-only settings or secrets and behaves correctly in trusted and untrusted checkouts.
• Claude package settings are self-contained where required; no parent settings inheritance is assumed.
• Plugin manifests, component paths, marketplace entries, install, upgrade, disable, and uninstall behavior pass in a clean environment.
• Plugin reload or new-task requirements and any connector authentication boundary are tested independently of installation.
• Portable skills and scripts have an explicit mirroring or packaging source of truth; client-specific metadata remains separate.

Long-running operation

• Objectives, decisions, artifacts, validation, and pending work survive compaction or reconnection.
• Invoked-skill truncation or eviction during compaction is tested for long workflows; critical state does not exist only in the skill message.
• Progress and results are represented as structured events or artifacts.
• Cancellation, retry, timeout, approval, and resume semantics are defined.
• The UI, logs, metrics, and test results needed to judge success are available to the agent in a concise form.
• Autonomous change flows validate the baseline, reproduce failure, record the fix, handle build/review failures, and escalate judgement calls.

Evaluation and maintenance

• Routing accuracy and output quality are measured separately.
• Baselines compare the workflow with and without the skill or automation.
• Cost, duration, tool calls, failures, and human corrections are tracked.
• Recurring feedback becomes a doc, skill, check, or tool improvement.
• Owners periodically retire stale rules and unused workflows.
• Documentation freshness, quality grades, architecture deviations, and targeted cleanup run on an owned cadence.
• Merge gates are based on impact and demonstrated recovery, not expected agent throughput.