Problem
openspec init currently asks users to pick specific tool integrations, but there should also be a generic installer target for the shared .agents convention.
.agents has become the common project-local location understood by nearly all modern agentic coding tools. Teams that use more than one agent, or tools that do not have a first-class OpenSpec integration yet, should not have to pick a vendor-specific target or maintain several duplicated prompt/skill trees.
Right now the closest options/issues are adjacent but not the same:
This issue is specifically for a generic OpenSpec installer option that writes OpenSpec agent assets into .agents.
Proposed solution
Add a generic .agents option to the installer/update flow, for example in openspec init and openspec update:
The generated output should use the .agents directory as the stable, vendor-neutral integration point for tools that support that standard. Exact subpaths can follow whatever OpenSpec already uses for commands, skills, rules, and prompts, but the important part is that users can choose .agents directly without pretending to use a specific vendor integration.
This should work for both interactive and non-interactive usage, for example via a documented flag or tool/profile identifier, so automation can install the generic integration consistently.
Expected behavior
A user should be able to run OpenSpec setup and select a generic .agents target. After that, agentic tools that understand .agents can discover the OpenSpec instructions/skills without requiring duplicate setup for each individual tool.
Acceptance criteria
openspec init offers a generic .agents option.openspec update can update the generated .agents assets.- Non-interactive install/update supports the same target through a documented option.
- Generated files use
.agents, not .agent, and are not tied to a single vendor tool.
- Documentation explains when to choose the generic
.agents target versus a tool-specific integration.
Why this matters
This lowers adoption friction for mixed-agent teams and for new agentic tools. OpenSpec should be able to install once into the standard shared agent directory instead of forcing users to choose one vendor-specific layout as a proxy for generic agent support.
Problem
openspec initcurrently asks users to pick specific tool integrations, but there should also be a generic installer target for the shared.agentsconvention..agentshas become the common project-local location understood by nearly all modern agentic coding tools. Teams that use more than one agent, or tools that do not have a first-class OpenSpec integration yet, should not have to pick a vendor-specific target or maintain several duplicated prompt/skill trees.Right now the closest options/issues are adjacent but not the same:
Other toolsoption disappeared, but frames it aroundAGENTS.md/generic system prompts..agent/skillsfolder for all agents that support it #689 proposes.agent/skillssingular, which is a different path and narrower than a generic.agentsinstaller target.This issue is specifically for a generic OpenSpec installer option that writes OpenSpec agent assets into
.agents.Proposed solution
Add a generic
.agentsoption to the installer/update flow, for example inopenspec initandopenspec update:The generated output should use the
.agentsdirectory as the stable, vendor-neutral integration point for tools that support that standard. Exact subpaths can follow whatever OpenSpec already uses for commands, skills, rules, and prompts, but the important part is that users can choose.agentsdirectly without pretending to use a specific vendor integration.This should work for both interactive and non-interactive usage, for example via a documented flag or tool/profile identifier, so automation can install the generic integration consistently.
Expected behavior
A user should be able to run OpenSpec setup and select a generic
.agentstarget. After that, agentic tools that understand.agentscan discover the OpenSpec instructions/skills without requiring duplicate setup for each individual tool.Acceptance criteria
openspec initoffers a generic.agentsoption.openspec updatecan update the generated.agentsassets..agents, not.agent, and are not tied to a single vendor tool..agentstarget versus a tool-specific integration.Why this matters
This lowers adoption friction for mixed-agent teams and for new agentic tools. OpenSpec should be able to install once into the standard shared agent directory instead of forcing users to choose one vendor-specific layout as a proxy for generic agent support.