OpenSpec Agent Guide
Use this file for OpenSpec-specific behavior in this repository. Generic project rules live in the root AGENTS.md.
Stable Capabilities
The stable authoritative specs are:
openspec/specs/kernel/spec.mdopenspec/specs/architecture/spec.mdopenspec/specs/testing/spec.mdopenspec/specs/repository-governance/spec.mdopenspec/specs/project-presentation/spec.md
Do not treat archived changes or old root-level spec references as normative.
Change Lifecycle
1
explore -> propose -> apply -> review -> archive
- Use
/opsx:explorewhen scope, cleanup aggressiveness, or trade-offs are unclear. - Use
/opsx:proposefor any repo-wide change affecting structure, docs, workflow, or quality gates. - Use
/opsx:applyto work tasks in dependency order. - Use
/reviewbefore major deletions, workflow simplification, or archive. - Use
/opsx:archiveonly after tasks, docs, specs, and validation are aligned.
Authoring Rules for This Repository
Proposal
- Frame the change around repository outcomes, not generic process language.
- Be explicit when the goal is consolidation, deletion, or archive-readiness.
Design
- Capture why one authoritative source is chosen when duplicate systems exist.
- Call out validation boundaries between local GPU checks and CI-safe checks.
Specs
- Stable capability specs belong under
openspec/specs/<capability>/spec.md. - Change deltas belong under
openspec/changes/<change>/specs/<capability>/spec.md. - Use
ADDED,MODIFIED,REMOVED, orRENAMEDexactly. - Every requirement needs at least one
#### Scenario.
Tasks
- Group tasks by dependency and cleanup phase.
- Use trackable checkboxes only:
- [ ]. - Prefer tasks that can complete in one focused apply session.
Closeout Bias
- Prefer deleting or merging low-value artifacts over preserving shells.
- Prefer one longer apply session over
/fleetunless the work is naturally parallel. - Keep the stable specs, README, Pages, and automation model synchronized at each major milestone.