2026 04 20 harness selection tools agents skills prompts instructions

Harness-level selection and use of tools, agents, skills, prompts, and instruction files

Research Question

When should teams choose tools, agent definition files, skills, prompts, instruction files, and AGENTS.md, and what verifiable best practices align with how major harnesses actually select and apply each artifact?

Scope

In scope:

Define common concepts and boundaries: tool, agent definition file, skill, prompt, instruction file, and AGENTS.md
Compare selection and utilisation behavior across GitHub Copilot (issue assignment flow, Copilot Spaces, Visual Studio Code (VS Code) extension, command line interface (CLI)), Claude Code, OpenCode CLI, Codex, and closely related harnesses with public documentation
Identify currently common files, common selection mechanisms, and precedence rules where documented
Distinguish implementation-defined behavior (documented, testable, or source-backed) from opinion-based guidance
Capture current trends and emerging patterns in harness design

Out of scope:

Building or changing any harness implementation
Vendor marketing claims that cannot be tied to documented behavior or code
Proprietary internal harnesses without public, verifiable documentation

Constraints: (time, source types, access) Use publicly verifiable sources only (official documentation, source repositories, standards/specifications, and reproducible behavior notes). Prioritise primary sources and clearly flag unknowns where no authoritative evidence exists.

Context

[inference; source: GitHub custom instructions support matrix, Claude Code features overview, Codex customization] This item is best treated as a decision-support problem about overlapping Markdown control artifacts whose meaning changes by harness, so the useful output is a selection guide that separates durable policy from task-specific workflows and from tool access.

Approach

Build a terminology map for each artifact type, including equivalent names used by each harness.
For each target harness, document the loading and precedence model for tools, agents, skills, prompts, instructions, and AGENTS.md-like files.
Verify each behavior against primary documentation and, where possible, implementation sources or reproducible examples.
Produce a cross-harness comparison matrix showing common files, selection methods, and divergence points.
Synthesize evidence-backed best practices for both general use and harness-specific use.
Extract trend signals and emerging conventions, then list open gaps that need ongoing tracking.

Sources

Starting points, papers, articles, videos, repos, docs.

Research Skill Output

(Full output from running the research skill, retained verbatim in the completed item. Sections 0 to 5 are the investigation; section 6 seeds the Findings section below.)

§0 Initialise

[fact; source: GitHub Copilot CLI feature comparison, Claude Code features overview, OpenCode rules, Codex customization] The research question is: when should teams choose tools, agent definition files, skills, prompts, instruction files, and AGENTS.md, and which best practices are actually supported by the public behavior of GitHub Copilot, Claude Code, OpenCode, Codex, and related harnesses.
[fact; source: GitHub custom instructions support matrix, Anthropic Docs: Claude Code memory, OpenCode rules, Codex AGENTS.md guide] Scope is limited to public, verifiable behavior for GitHub Copilot on GitHub.com, GitHub Copilot in VS Code, GitHub Copilot CLI, Copilot Spaces, Claude Code, OpenCode, Codex, and the open AGENTS.md convention; it excludes private harnesses and marketing claims without file-level or product-level behavior evidence.
[fact; source: GitHub Docs: Configure custom instructions for GitHub Copilot, Anthropic Docs: Claude Code memory, Codex AGENTS.md guide] Constraints require primary sources first, public URLs only, and clear separation between documented behavior and recommendations derived from that behavior.
[fact; source: Prior work: AI coding harnesses agent philosophy, Prior work: agent instruction loading and skills access, Prior work: multi-agent repo setup] Prior work already established that agent harnesses differ materially in instruction discovery and that AGENTS.md is becoming a cross-vendor convention, but the earlier items did not produce a single selection guide that separates tools, prompts, skills, agent definitions, and instruction files by use case.
[inference; source: GitHub Copilot CLI feature comparison, Claude Code features overview, Codex customization] The most decision-useful output format is a two-layer synthesis: first define what each artifact type is for, then map each harness to discovery rules, invocation rules, and precedence rules so teams can choose the smallest artifact that solves the problem.

§1 Question Decomposition

Artifact boundaries
- A1. What is a tool, and how is it different from an instruction artifact?
- A2. What is an instruction file, and when is it always-on rather than on-demand?
- A3. What is a prompt artifact, and when is it manually invoked instead of auto-loaded?
- A4. What is a skill, and how does progressive disclosure differ from always-on context?
- A5. What is an agent definition file, and when does it matter more than a prompt or skill?
- A6. What is AGENTS.md, and is it a portable standard or just one vendor format?
GitHub Copilot
- B1. Which instruction files are supported on GitHub.com cloud agent, VS Code, and CLI?
- B2. How do path-specific instructions differ from AGENTS.md and .github/copilot-instructions.md?
- B3. When should prompt files, agent skills, custom agents, hooks, and Copilot Spaces be used?
Claude Code
- C1. What does Claude load every session?
- C2. What moves from CLAUDE.md into skills, subagents, or hooks?
- C3. How should teams reuse AGENTS.md content with Claude Code?
OpenCode
- D1. What are OpenCode’s native artifacts for rules, agents, skills, commands, and tools?
- D2. How do OpenCode’s compatibility fallbacks for .claude and .agents affect selection?
Codex
- E1. What is Codex’s default instruction layer?
- E2. How do Codex skills, subagents, and Model Context Protocol (MCP) fit around AGENTS.md?
Synthesis
- F1. Which artifacts are portable across harnesses?
- F2. Which choices remain harness-specific?
- F3. What evidence-backed best practices follow from the convergence and divergence patterns?

§2 Investigation

A. Artifact boundaries

[fact; source: GitHub Copilot CLI feature comparison, OpenCode tools, Claude Code features overview] A tool is an ability surface, such as read, edit, shell, web fetch, or a delegated agent call, that lets the harness gather context or take action; it is not an instruction container.
[fact; source: GitHub Copilot CLI feature comparison, VS Code custom instructions, Anthropic Docs: Claude Code memory, Codex AGENTS.md guide] An instruction file is an always-on or automatically discovered context artifact that shapes behavior before work starts, such as .github/copilot-instructions.md, CLAUDE.md, or AGENTS.md.
[fact; source: VS Code prompt files, OpenCode commands, Claude Code commands] A prompt artifact is a manually invoked, task-scoped prompt template, typically surfaced as a slash command, that encodes how to perform one repeatable task without changing the agent’s default behavior for every session.
[fact; source: VS Code agent skills, Claude Code skills, OpenCode skills, Codex skills] A skill is a reusable SKILL.md capability bundle with metadata plus optional supporting files or scripts, and the common documented loading model is progressive disclosure: metadata is visible up front, full instructions load only when selected or triggered.
[fact; source: VS Code custom agents, GitHub Docs: create custom agents for Copilot CLI, Claude Code subagents, OpenCode agents] An agent definition file configures a specialized worker or persona with its own prompt, tool permissions, model preferences, and sometimes handoffs or hooks; this is a different layer from both instructions and skills.
[fact; source: AGENTS.md specification, GitHub Docs: add custom instructions for Copilot CLI, Codex AGENTS.md guide, OpenCode rules] AGENTS.md is an open, portable instruction-file convention for repository-level agent guidance, and major harnesses now document it directly rather than only through community convention.

B. GitHub Copilot surfaces

[fact; source: GitHub custom instructions support matrix] Copilot cloud agent on GitHub.com supports repository-wide instructions, path-specific instructions, agent instructions via AGENTS.md, CLAUDE.md, or GEMINI.md, and organization instructions.
[fact; source: GitHub Docs: Configure custom instructions for GitHub Copilot] On GitHub.com, .github/copilot-instructions.md is the repository-wide always-on file, .github/instructions/**/*.instructions.md adds path-scoped rules, and the nearest AGENTS.md in the directory tree takes precedence for agent instructions.
[fact; source: GitHub Docs: Copilot CLI custom instructions] In Copilot CLI, the root AGENTS.md is treated as primary instructions, .github/copilot-instructions.md is also loaded when present, and additional AGENTS.md files can be discovered from the current working directory and configured custom-instructions directories.
[fact; source: VS Code custom instructions] In VS Code, always-on instructions can come from .github/copilot-instructions.md, one or more AGENTS.md files, organization instructions, and CLAUDE.md; file-based instructions come from *.instructions.md files, and when multiple instruction files apply, VS Code combines them with no guaranteed order.
[fact; source: VS Code prompt files] Copilot prompt files are .prompt.md files stored by default under .github/prompts, invoked manually with /prompt-name, and intended for lightweight, single-task prompt templates rather than always-on conventions.
[fact; source: VS Code agent skills] Copilot agent skills use open-standard SKILL.md directories, can live in .github/skills/, .claude/skills/, or .agents/skills/, and are documented as portable across VS Code, Copilot CLI, and Copilot cloud agent.
[fact; source: VS Code custom agents, GitHub custom agents configuration] Copilot custom agents are .agent.md files, usually in .github/agents/, that define persona, tools, model, available subagents, and handoffs; GitHub and supported clients deduplicate them by file name and let lower-level definitions override higher-level ones.
[fact; source: GitHub Docs: About organizing and sharing context with Copilot Spaces, GitHub Docs: Create Copilot Spaces] Copilot Spaces is a context-grounding product that stores free-text instructions plus attached sources such as repositories, files, issues, and uploads; when a repository is attached, Spaces retrieves relevant content from the latest main branch rather than auto-loading the repository’s instruction files into every answer.
[inference; source: GitHub Docs: Create Copilot Spaces, GitHub custom instructions support matrix] Copilot Spaces should be selected when the problem is retrieval, curation, or shared question answering, not when the goal is to enforce coding policy for every cloud-agent task, because that policy belongs in repository instruction files and agent definitions.
[fact; source: GitHub Docs: Customize the Copilot coding agent development environment] The cloud agent’s runtime environment is not controlled by prompt or instruction files; it is prepared through .github/workflows/copilot-setup-steps.yml, which runs before the agent starts and is the correct place for deterministic setup, dependency installation, or submodule checkout.

C. Claude Code

[fact; source: Anthropic Docs: Claude Code overview, Anthropic Docs: Claude Code memory] Claude Code’s always-on instruction layer is CLAUDE.md, loaded from project, user, local, and managed locations at session start, with subdirectory CLAUDE.md files loading on demand when Claude works in those directories.
[fact; source: Anthropic Docs: Claude Code memory] Anthropic’s current guidance explicitly states that Claude Code reads CLAUDE.md, not AGENTS.md, and recommends creating a CLAUDE.md that imports AGENTS.md when a repository already uses the portable standard.
[fact; source: Claude Code skills, Claude Code features overview] Claude Code skills are the on-demand mechanism for reusable procedures or large reference bodies because only descriptions load initially and full skill content loads when the skill is invoked or auto-selected.
[fact; source: Claude Code skills, Claude Code commands] Claude Code treats many slash-invoked workflows, such as /batch, /debug, /loop, and /simplify, as bundled skills rather than as a separate prompt-file artifact, so the product’s native distinction is closer to instructions versus skills versus subagents than to instructions versus prompts versus skills.
[fact; source: Claude Code subagents] Claude Code subagents are Markdown definitions in .claude/agents/ or ~/.claude/agents/ with frontmatter for description, tools, model, skills, hooks, and isolation behavior, and each subagent runs in its own context window.
[inference; source: Anthropic Docs: Claude Code memory, Claude Code skills] In Claude Code, teams should move facts that must always apply into CLAUDE.md, move repeatable procedures into skills, and introduce subagents only when they need isolation, delegated specialization, or a preloaded skill bundle with different permissions.

D. OpenCode

[fact; source: OpenCode rules] OpenCode uses AGENTS.md as its primary project rule file, supports a global ~/.config/opencode/AGENTS.md, and falls back to CLAUDE.md only when AGENTS.md is absent.
[fact; source: OpenCode rules] OpenCode also supports an instructions array in opencode.json that can merge additional local or remote rule files with AGENTS.md, which makes it more explicit than most harnesses about reusing existing instruction sources without duplicating them.
[fact; source: OpenCode commands] OpenCode commands are prompt templates stored in .opencode/commands/ or config, surfaced as slash commands, and can optionally specify which agent and model should execute the command.
[fact; source: OpenCode skills] OpenCode has a native skill system, discovered from .opencode/skills/ and compatible .claude/skills/ and .agents/skills/ locations, with metadata shown through a native skill tool and full content loaded when the agent chooses or invokes the skill.
[fact; source: OpenCode agents] OpenCode agents can be defined in config or Markdown files under .opencode/agents/, and the platform distinguishes primary agents from subagents while letting tools, permissions, and prompts vary per agent.
[fact; source: OpenCode tools] OpenCode’s tool model is explicit and permission-driven, with built-in tools for bash, edit, write, read, grep, glob, Language Server Protocol (LSP), skill loading, todo management, web fetch, web search, and user questioning.
[fact; source: OpenCode rules, OpenCode skills, OpenCode agents, OpenCode commands] OpenCode documents each artifact type separately and openly: AGENTS.md for policy, commands for prompt templates, skills for reusable workflows, agents for personas and permission bundles, and tools for capabilities.

E. Codex

[fact; source: Codex customization, Codex AGENTS.md guide] Codex positions AGENTS.md as the durable base layer of customization and documents an explicit discovery chain from global scope to repository root to current directory, with deeper files overriding earlier guidance by appearing later in the merged prompt.
[fact; source: Codex skills] Codex skills live in .agents/skills in repository and user scopes, use progressive disclosure, can be invoked explicitly or implicitly, and are available in the Codex Command Line Interface (CLI), Integrated Development Environment (IDE) extension, and app.
[fact; source: Codex customization, Codex MCP] Codex treats skills and Model Context Protocol (MCP) as complementary layers: skills encode reusable workflows, while MCP adds external tools and data access through config.toml.
[fact; source: Codex subagents] Codex subagent workflows are parallel delegated agents intended to keep noisy intermediate work off the main thread, but the consulted concept page says Codex does not spawn them automatically and expects the user to ask explicitly for subagents or parallel agent work.
[inference; source: Codex customization, Codex AGENTS.md guide, Codex skills] Codex’s documented stack is the most opinionated about ordering: start with AGENTS.md, add skills for reusable workflows, add MCP when outside systems are needed, and add subagents only when the task shape justifies the extra coordination and token cost.

F. Cross-harness patterns and contradictions

[fact; source: VS Code agent skills, Claude Code skills, OpenCode skills, Codex skills] SKILL.md has converged fastest across vendors: GitHub Copilot, Claude Code, OpenCode, and Codex all document the open Agent Skills standard and all describe low-cost discovery followed by on-demand full loading.
[fact; source: AGENTS.md specification, GitHub Docs: Copilot CLI custom instructions, OpenCode rules, Codex AGENTS.md guide, Anthropic Docs: Claude Code memory] AGENTS.md has also converged strongly, but not uniformly: Copilot, OpenCode, and Codex read it directly, whereas Claude Code currently wants CLAUDE.md as its entrypoint and uses @AGENTS.md import for compatibility.
[fact; source: VS Code prompt files, OpenCode commands, Claude Code commands] Manual prompt-template artifacts are less standardized than skills: VS Code uses .prompt.md, OpenCode uses command Markdown or config entries, and Claude Code exposes slash-invoked workflows mostly through skills and fixed commands rather than a separate prompt-file format.
[fact; source: GitHub custom instructions support matrix, VS Code custom instructions, Anthropic Docs: Claude Code memory, OpenCode rules, Codex AGENTS.md guide] Instruction-file discovery is still the largest portability gap because each harness has different roots, precedence rules, and compatibility shims even when the underlying content is similar.
[inference; source: GitHub Docs: Create Copilot Spaces, GitHub Docs: Customize the Copilot coding agent development environment, Claude Code features overview, Codex customization] The recurring design pattern is layered control: always-on instruction files define guardrails, skills or prompt artifacts define reusable tasks, agent definitions define specialist workers, and setup files or MCP config define environment and external systems.
[fact; source: GitHub Docs: About organizing and sharing context with Copilot Spaces, GitHub Docs: Create Copilot Spaces] The current official Copilot Spaces overview and creation pages were used as the authoritative primary sources for this item because they document the product behavior and setup flow directly.

§3 Reasoning

[fact; source: GitHub Copilot CLI feature comparison, Claude Code features overview, Codex customization] The primary distinction that remained stable across vendors was functional, not filename-based: tools provide abilities, instruction files provide durable guidance, prompt artifacts start a task manually, skills package reusable workflows, and agent definitions configure specialist workers.
[inference; source: VS Code custom instructions, Anthropic Docs: Claude Code memory, OpenCode rules, Codex AGENTS.md guide] Because instruction files are always-on or automatically discovered, they should hold facts, conventions, and durable constraints, not long procedures, since every platform documents context cost or nondeterminism problems when too much always-on guidance accumulates.
[inference; source: VS Code prompt files, Claude Code skills, OpenCode commands, Codex skills] Procedural content should move into prompt artifacts or skills because all four ecosystems document those mechanisms as on-demand, which keeps repeated workflows reusable without polluting every session.
[inference; source: Anthropic Docs: Claude Code memory, AGENTS.md specification, GitHub custom instructions support matrix, OpenCode rules] A single universal repository file is still not enough in practice because Claude Code’s primary entrypoint is CLAUDE.md while other harnesses increasingly privilege AGENTS.md, so cross-harness teams need a portable core plus thin compatibility wrappers rather than a single magical filename.
[inference; source: GitHub Docs: Create Copilot Spaces, GitHub Docs: Customize the Copilot coding agent development environment] GitHub Copilot surfaces force a second distinction between context and environment: Spaces manage retrieval context, whereas copilot-setup-steps.yml manages runtime determinism, so neither should be used as a substitute for the other.

§4 Consistency Check

[fact; source: GitHub custom instructions support matrix, GitHub Docs: Copilot CLI custom instructions] The Copilot evidence is internally consistent after separating products by surface: GitHub.com cloud agent and CLI both support AGENTS.md, but the exact support matrix differs by client, so claims in the synthesis are scoped by surface rather than by brand alone.
[fact; source: Anthropic Docs: Claude Code memory, Claude Code skills] The Claude Code evidence is internally consistent after distinguishing CLAUDE.md from skills: CLAUDE.md is always-on, while skill descriptions load up front and full skill bodies load only when selected.
[fact; source: OpenCode rules, OpenCode skills, OpenCode commands] The OpenCode evidence is internally consistent because rules, commands, skills, and agents are documented as separate artifact classes with different storage locations and loading behavior.
[fact; source: Codex AGENTS.md guide, Codex skills, Codex subagents] The Codex evidence is internally consistent because AGENTS.md is the durable base layer, skills are reusable workflows, and subagents are explicit parallel workers rather than automatic background behavior.
[inference; source: GitHub custom instructions support matrix, Anthropic Docs: Claude Code memory, OpenCode rules, Codex AGENTS.md guide] No direct contradiction remained after distinguishing four separate questions: what loads every session, what is manually invoked, what is discoverable on demand, and what defines a separate worker with its own permissions and model choice.

§5 Depth and Breadth Expansion

[inference; source: VS Code agent skills, Claude Code features overview, Codex skills] Progressive disclosure is now the dominant answer to context pressure for reusable workflows, which means the selection question is less about "can this artifact hold enough detail" and more about "should this detail be visible before the task is known".
[fact; source: AGENTS.md specification, Anthropic Docs: Claude Code memory] The ecosystem moved from vendor-specific instruction files toward two open-ish standards, AGENTS.md and Agent Skills, but the older vendor roots still matter because compatibility is not symmetrical.
[inference; source: GitHub Docs: Create Copilot Spaces, VS Code prompt files, OpenCode commands] Humans reach for prompts or Spaces when they want to start a task or curate context by hand, whereas harnesses reach for skills and instruction files when they need automatic routing or automatic loading.
[inference; source: Claude Code features overview, Codex subagents, OpenCode agents] Agent definitions and subagents should be introduced only when the coordination savings exceed their extra token and complexity cost, because every vendor documents some form of isolated worker overhead even when they praise specialization.
[inference; source: GitHub Docs: Customize the Copilot coding agent development environment, OpenCode tools, Claude Code subagents] From a control perspective, instruction files tell the agent what policy to follow, but permission systems, hooks, and setup files are the enforceable control layer; teams should not mistake descriptive guidance for hard governance.

§6 Synthesis

Executive summary:

[inference; source: GitHub Copilot CLI feature comparison, Claude Code features overview, Codex customization] Teams should choose instruction files for durable policy, prompt artifacts for manually started one-off tasks, skills for reusable on-demand workflows, agent definition files for specialist workers with distinct tools or model settings, and tools or MCP only for capabilities, not for policy.
[inference; source: AGENTS.md specification, Anthropic Docs: Claude Code memory, GitHub custom instructions support matrix, OpenCode rules, Codex AGENTS.md guide] AGENTS.md is the most portable repository-level core across modern harnesses, but it is not yet a complete universal answer because Claude Code still expects CLAUDE.md as its primary always-on entrypoint and recommends importing AGENTS.md from there.
[inference; source: VS Code agent skills, Claude Code skills, OpenCode skills, Codex skills] SKILL.md is a mature cross-harness answer for reusable multi-step workflows because all four major ecosystems document progressive disclosure and explicit or implicit invocation.
[inference; source: GitHub custom instructions support matrix, Anthropic Docs: Claude Code memory, OpenCode rules, Codex AGENTS.md guide] The practical best practice is layered: keep always-on files short and factual, put reusable procedures into skills, use prompt files or commands only for human-invoked task launchers, and add custom agents or subagents only when isolation, tool restriction, or model specialization is materially useful.

Key findings:

[inference; source: GitHub Copilot CLI feature comparison, Claude Code features overview, Codex customization] High confidence: The decisive selection rule is artifact function rather than filename, because the surveyed harnesses consistently separate abilities, durable policy, reusable workflows, and specialist worker definitions into different layers.
[fact; source: AGENTS.md specification, GitHub custom instructions support matrix, OpenCode rules, Codex AGENTS.md guide, Anthropic Docs: Claude Code memory] High confidence: AGENTS.md is the most portable repository-level instruction artifact across the surveyed harnesses, but Claude Code still requires a CLAUDE.md wrapper or import pattern for full always-on compatibility.
[fact; source: GitHub custom instructions support matrix, VS Code custom instructions, GitHub Docs: Copilot CLI custom instructions, GitHub Docs: Create Copilot Spaces] High confidence: GitHub Copilot documents repository instructions, path-specific instructions, prompt files, skills, custom agents, and Copilot Spaces across its public surfaces, so teams still need to choose by surface because GitHub.com cloud agent, VS Code, CLI, and Spaces load different files and apply different precedence rules.
[inference; source: GitHub Docs: About organizing and sharing context with Copilot Spaces, GitHub Docs: Create Copilot Spaces] Medium confidence: Copilot Spaces should be selected for shared retrieval context and curated question answering, while repository instruction files should still hold coding policy for cloud-agent or integrated development workflows.
[inference; source: Anthropic Docs: Claude Code memory, Claude Code skills, Claude Code subagents] Medium confidence: A practical Claude Code operating model is CLAUDE.md for always-on facts, skills for reusable procedures or reference bundles, and subagents for isolated specialist work, so long procedural guidance should not remain in CLAUDE.md.
[inference; source: OpenCode rules, OpenCode commands, OpenCode skills, OpenCode agents, OpenCode tools] High confidence: OpenCode documents separate native artifacts for rules, commands, skills, agents, and tools, which makes it a useful public example of the layered selection framework this item recommends.
[inference; source: Codex customization, Codex AGENTS.md guide, Codex skills, Codex subagents] Medium confidence: Codex documents a disciplined order of adoption, AGENTS.md first, then skills, then external connectivity through MCP, then subagents only when explicit parallel specialist work is justified.
[inference; source: AGENTS.md specification, Anthropic Docs: Claude Code memory, GitHub custom instructions support matrix, VS Code agent skills, Codex AGENTS.md guide] High confidence: The strongest cross-harness best practice is a short portable core in AGENTS.md, plus harness-native compatibility shims only where required, rather than trying to overload prompts, commands, or agent files with permanent repository policy.

Evidence map:

Claim	Source	Confidence	Notes
[inference] Artifact selection is about function, not filename, across the surveyed harnesses.	GitHub Copilot CLI feature comparison; Claude Code features overview; Codex customization	high	The three vendors use nearly identical boundary language.
[fact] `AGENTS.md` is portable, but Claude Code still needs `CLAUDE.md` as the entrypoint.	AGENTS.md specification; GitHub custom instructions support matrix; OpenCode rules; Codex AGENTS.md guide; Anthropic Docs: Claude Code memory	high	Cross-vendor convergence with one explicit exception.
[fact] GitHub Copilot documents repository instructions, path-specific instructions, prompt files, skills, custom agents, and Copilot Spaces across its public surfaces, so teams still need to choose by surface.	GitHub custom instructions support matrix; VS Code custom instructions; GitHub Docs: Copilot CLI custom instructions; GitHub Docs: Create Copilot Spaces	high	The public docs enumerate these artifact types and make the surface differences explicit.
[inference] Copilot Spaces should be used for shared retrieval context and curated question answering, not as a substitute for repository policy files.	GitHub Docs: About organizing and sharing context with Copilot Spaces; GitHub Docs: Create Copilot Spaces	medium	The product shape is documented directly, but the selection guidance is synthesized.
[inference] A practical Claude Code operating model is `CLAUDE.md` for always-on facts, skills for reusable procedures, and subagents for isolated specialist work.	Anthropic Docs: Claude Code memory; Claude Code skills; Claude Code subagents	medium	The docs define the pieces directly; the operating model is the recommended composition.
[inference] OpenCode documents separate native artifacts for rules, commands, skills, agents, and tools, which makes it a useful public example of the layered selection framework recommended here.	OpenCode rules; OpenCode commands; OpenCode skills; OpenCode agents; OpenCode tools	high	The docs define each artifact explicitly, and the recommendation uses that documented separation.
[inference] Codex documents an order of adoption that starts with `AGENTS.md`, then skills, then MCP, then subagents only when parallel specialist work is justified.	Codex customization; Codex AGENTS.md guide; Codex skills; Codex subagents	medium	OpenAI documents the components directly; the sequence is a synthesized operating order.
[inference] Portable core plus thin shims is safer than forcing one filename to play every role.	AGENTS.md specification; Anthropic Docs: Claude Code memory; GitHub custom instructions support matrix; Codex AGENTS.md guide	high	Best-fit synthesis of documented convergence and divergence.

Assumptions:

[assumption; source: GitHub Docs: Create Copilot Spaces, GitHub custom instructions support matrix] The synthesis assumes that the absence of documented automatic repository instruction loading in Copilot Spaces means teams should not rely on that behavior; this is justified because the current official docs describe Space instructions and attached sources, not inherited repo instruction files.

Analysis:

[inference; source: VS Code custom instructions, Anthropic Docs: Claude Code memory, Codex AGENTS.md guide] I weighted always-on file behavior most heavily when vendors documented startup loading explicitly, because that is the part of the system teams rely on for baseline policy and because those statements were primary-source, not community extrapolation.
[inference; source: VS Code agent skills, Claude Code skills, OpenCode skills, Codex skills] I treated the convergence on SKILL.md as stronger evidence than any single vendor’s workflow marketing, because four independent ecosystems describe the same authoring unit and the same progressive-disclosure loading model.
[inference; source: Anthropic Docs: Claude Code memory, GitHub custom instructions support matrix, OpenCode rules, Codex AGENTS.md guide] I resolved the portability tension by privileging documented discovery rules over convenience, which is why the recommendation is a portable AGENTS.md core plus shims instead of pretending that every harness discovers the same path natively.
[inference; source: GitHub Docs: Customize the Copilot coding agent development environment, Codex MCP, OpenCode tools] I kept runtime setup and external connectivity outside the prompt-selection framework because the official docs consistently place those concerns in setup workflows, configuration, permissions, or MCP, not in instruction bodies.

Risks, gaps, uncertainties:

[fact; source: GitHub Docs: About organizing and sharing context with Copilot Spaces, GitHub Docs: Create Copilot Spaces] Current Copilot Spaces docs describe Space instructions and source retrieval but do not explicitly say "repository instruction files are ignored," so the negative conclusion is based on documented model shape rather than on a direct denial statement.
[fact; source: Anthropic Docs: Claude Code memory] Claude Code’s CLAUDE.md requirement is explicit today, but Anthropic could still add native AGENTS.md loading later without invalidating the broader layered-selection model.
[fact; source: Codex subagents] The consulted Codex subagent evidence is strongest on workflow concepts and weaker on repository file-path mechanics for agent definitions, because the retrieved primary pages focused more on concepts than on local file layout for subagent profiles.
[inference; source: GitHub Copilot CLI feature comparison, Claude Code features overview, OpenCode rules, Codex customization] None of these uncertainties undermines the core conclusion that teams should separate durable policy, reusable workflows, manual task launchers, and specialist worker definitions rather than collapsing them into a single Markdown artifact.

Open questions:

[inference; source: GitHub Docs: About organizing and sharing context with Copilot Spaces, GitHub Docs: Create Copilot Spaces] Will GitHub add automatic repository instruction inheritance to Copilot Spaces, or will Spaces remain intentionally separate from repository-level coding policy?
[inference; source: Anthropic Docs: Claude Code memory, AGENTS.md specification] Will Claude Code eventually read AGENTS.md natively, or will CLAUDE.md remain the required compatibility entrypoint even as the open standard spreads?
[inference; source: Codex skills, OpenCode skills, VS Code agent skills] Will the current convergence on Agent Skills produce stronger cross-tool packaging interoperability, or will plugins and dependency metadata keep skills only partially portable across harnesses?

§7 Recursive Review

[fact; source: this document] Every claim in sections 0, 2, 3, 4, 5, and 6 is now labeled as fact, inference, or assumption, and section 1 is limited to decomposition structure rather than unsupported claims.
[fact; source: this document] The synthesis does not introduce any conclusion that lacks support in section 2, and every key finding appears again in the Evidence Map.
[fact; source: this document] The prior-work check was completed against related completed items, and this item’s contribution is differentiated from those earlier notes.
[inference; source: GitHub custom instructions support matrix, Anthropic Docs: Claude Code memory, OpenCode rules, Codex AGENTS.md guide] The remaining uncertainty is not about the core selection model, which is well-supported, but about whether current vendor compatibility gaps narrow further over time.

Findings

(Populated from section 6 Synthesis above.)

Executive Summary

[inference; source: GitHub Copilot CLI feature comparison, Claude Code features overview, Codex customization] Teams should use instruction files for durable project policy, prompt artifacts for manually launched one-off tasks, skills for reusable on-demand workflows, agent definition files for specialist workers, and tools or Model Context Protocol (MCP) only for capabilities.
[inference; source: AGENTS.md specification, Anthropic Docs: Claude Code memory, GitHub custom instructions support matrix] AGENTS.md is the strongest portable repository-level core across the surveyed harnesses, but Claude Code still needs a CLAUDE.md entrypoint or import shim for first-class always-on behavior.
[inference; source: VS Code agent skills, Claude Code skills, OpenCode skills, Codex skills] SKILL.md is the clearest cross-harness answer for reusable multi-step procedures because the major ecosystems all document low-cost discovery plus on-demand full loading.
[inference; source: GitHub custom instructions support matrix, Anthropic Docs: Claude Code memory, OpenCode rules, Codex AGENTS.md guide] The safest adoption pattern is layered and minimal: keep always-on files short and factual, move procedures into skills, use prompt files or commands only for human-triggered task launchers, and add custom agents or subagents only when isolation, tool restriction, or model specialization is worth the extra complexity.

Key Findings

[inference; source: GitHub Copilot CLI feature comparison, Claude Code features overview, Codex customization] High confidence: The decisive selection rule is artifact function rather than filename, because the surveyed harnesses consistently separate abilities, durable policy, reusable workflows, and specialist worker definitions into different layers.
[fact; source: AGENTS.md specification, GitHub custom instructions support matrix, OpenCode rules, Codex AGENTS.md guide, Anthropic Docs: Claude Code memory] High confidence: AGENTS.md is the most portable repository-level instruction artifact across the surveyed harnesses, but Claude Code still requires a CLAUDE.md wrapper or import pattern for full always-on compatibility.
[fact; source: GitHub custom instructions support matrix, VS Code custom instructions, GitHub Docs: Copilot CLI custom instructions, GitHub Docs: Create Copilot Spaces] High confidence: GitHub Copilot documents repository instructions, path-specific instructions, prompt files, skills, custom agents, and Copilot Spaces across its public surfaces, so teams still need to choose by surface because GitHub.com cloud agent, VS Code, CLI, and Spaces each load different files and apply different precedence rules.
[inference; source: GitHub Docs: About organizing and sharing context with Copilot Spaces, GitHub Docs: Create Copilot Spaces] Medium confidence: Copilot Spaces should be selected for shared retrieval context and curated question answering, while repository instruction files should still hold coding policy for cloud-agent or integrated development workflows.
[inference; source: Anthropic Docs: Claude Code memory, Claude Code skills, Claude Code subagents] Medium confidence: A practical Claude Code operating model is CLAUDE.md for always-on facts, skills for reusable procedures or reference bundles, and subagents for isolated specialist work, so long procedural guidance should not remain in CLAUDE.md.
[inference; source: OpenCode rules, OpenCode commands, OpenCode skills, OpenCode agents, OpenCode tools] High confidence: OpenCode documents separate native artifacts for rules, commands, skills, agents, and tools, which makes it a useful public example of the layered selection framework this item recommends.
[inference; source: Codex customization, Codex AGENTS.md guide, Codex skills, Codex subagents] Medium confidence: Codex documents a disciplined order of adoption, AGENTS.md first, then skills, then external connectivity through MCP, then subagents only when explicit parallel specialist work is justified.
[inference; source: AGENTS.md specification, Anthropic Docs: Claude Code memory, GitHub custom instructions support matrix, VS Code agent skills, Codex AGENTS.md guide] High confidence: The strongest cross-harness best practice is a short portable core in AGENTS.md, plus harness-native compatibility shims only where required, rather than trying to overload prompts, commands, or agent files with permanent repository policy.

Evidence Map

Claim	Source	Confidence	Notes
[inference] Artifact selection is about function, not filename, across the surveyed harnesses.	GitHub Copilot CLI feature comparison; Claude Code features overview; Codex customization	high	The three vendors use nearly identical boundary language.
[fact] `AGENTS.md` is portable, but Claude Code still needs `CLAUDE.md` as the entrypoint.	AGENTS.md specification; GitHub custom instructions support matrix; OpenCode rules; Codex AGENTS.md guide; Anthropic Docs: Claude Code memory	high	Cross-vendor convergence with one explicit exception.
[fact] GitHub Copilot documents repository instructions, path-specific instructions, prompt files, skills, custom agents, and Copilot Spaces across its public surfaces, so teams still need to choose by surface.	GitHub custom instructions support matrix; VS Code custom instructions; GitHub Docs: Copilot CLI custom instructions; GitHub Docs: Create Copilot Spaces	high	The public docs enumerate these artifact types and make the surface differences explicit.
[inference] Copilot Spaces should be used for shared retrieval context and curated question answering, not as a substitute for repository policy files.	GitHub Docs: About organizing and sharing context with Copilot Spaces; GitHub Docs: Create Copilot Spaces	medium	The product shape is documented directly, but the selection guidance is synthesized.
[inference] A practical Claude Code operating model is `CLAUDE.md` for always-on facts, skills for reusable procedures, and subagents for isolated specialist work.	Anthropic Docs: Claude Code memory; Claude Code skills; Claude Code subagents	medium	The docs define the pieces directly; the operating model is the recommended composition.
[inference] OpenCode documents separate native artifacts for rules, commands, skills, agents, and tools, which makes it a useful public example of the layered selection framework recommended here.	OpenCode rules; OpenCode commands; OpenCode skills; OpenCode agents; OpenCode tools	high	The docs define each artifact explicitly, and the recommendation uses that documented separation.
[inference] Codex documents an order of adoption that starts with `AGENTS.md`, then skills, then MCP, then subagents only when parallel specialist work is justified.	Codex customization; Codex AGENTS.md guide; Codex skills; Codex subagents	medium	OpenAI documents the components directly; the sequence is a synthesized operating order.
[inference] Portable core plus thin shims is safer than forcing one filename to play every role.	AGENTS.md specification; Anthropic Docs: Claude Code memory; GitHub custom instructions support matrix; Codex AGENTS.md guide	high	Best-fit synthesis of documented convergence and divergence.

Assumptions

[assumption; source: GitHub Docs: Create Copilot Spaces, GitHub custom instructions support matrix] Assumption: Copilot Spaces should be treated as separate from repository instruction inheritance until GitHub documents otherwise. Justification: The current official docs explain Space instructions and attached sources, but do not document automatic loading of repository instruction files into Space chat behavior.

Analysis

[inference; source: VS Code custom instructions, Anthropic Docs: Claude Code memory, Codex AGENTS.md guide] I weighted always-on file behavior most heavily when vendors documented startup loading explicitly, because that is the part of the system teams rely on for baseline policy and because those statements were primary-source, not community extrapolation.
[inference; source: VS Code agent skills, Claude Code skills, OpenCode skills, Codex skills] I treated the convergence on SKILL.md as stronger evidence than any single vendor’s workflow marketing, because four independent ecosystems describe the same authoring unit and the same progressive-disclosure loading model.
[inference; source: Anthropic Docs: Claude Code memory, GitHub custom instructions support matrix, OpenCode rules, Codex AGENTS.md guide] I resolved the portability tension by privileging documented discovery rules over convenience, which is why the recommendation is a portable AGENTS.md core plus shims instead of pretending that every harness discovers the same path natively.
[inference; source: GitHub Docs: Customize the Copilot coding agent development environment, Codex MCP, OpenCode tools] I kept runtime setup and external connectivity outside the prompt-selection framework because the official docs consistently place those concerns in setup workflows, configuration, permissions, or MCP, not in instruction bodies.

Risks, Gaps, and Uncertainties

[fact; source: GitHub Docs: About organizing and sharing context with Copilot Spaces, GitHub Docs: Create Copilot Spaces] Current Copilot Spaces docs describe Space instructions and source retrieval but do not explicitly say "repository instruction files are ignored," so the negative conclusion is based on documented model shape rather than on a direct denial statement.
[fact; source: Anthropic Docs: Claude Code memory] Claude Code’s CLAUDE.md requirement is explicit today, but Anthropic could still add native AGENTS.md loading later without invalidating the broader layered-selection model.
[fact; source: Codex subagents] The consulted Codex subagent evidence is strongest on workflow concepts and weaker on repository file-path mechanics for agent definitions, because the retrieved primary pages focused more on concepts than on local file layout for subagent profiles.
[inference; source: GitHub Copilot CLI feature comparison, Claude Code features overview, OpenCode rules, Codex customization] None of these uncertainties undermines the core conclusion that teams should separate durable policy, reusable workflows, manual task launchers, and specialist worker definitions rather than collapsing them into a single Markdown artifact.

Open Questions

[inference; source: GitHub Docs: About organizing and sharing context with Copilot Spaces, GitHub Docs: Create Copilot Spaces] Will GitHub add automatic repository instruction inheritance to Copilot Spaces, or will Spaces remain intentionally separate from repository-level coding policy?
[inference; source: Anthropic Docs: Claude Code memory, AGENTS.md specification] Will Claude Code eventually read AGENTS.md natively, or will CLAUDE.md remain the required compatibility entrypoint even as the open standard spreads?
[inference; source: Codex skills, OpenCode skills, VS Code agent skills] Will the current convergence on Agent Skills produce stronger cross-tool packaging interoperability, or will plugins and dependency metadata keep skills only partially portable across harnesses?

Output

[fact; source: this completed research item] Type: knowledge
[fact; source: this completed research item] Description: A cross-harness selection guide that distinguishes tools, instruction files, prompt artifacts, skills, agent definition files, and AGENTS.md, then maps those artifact classes onto GitHub Copilot, Claude Code, OpenCode, Codex, and Copilot Spaces.
[fact; source: GitHub custom instructions support matrix, Claude Code skills, Codex customization] Links: GitHub custom instructions support matrix; Claude Code skills; Codex customization