This file contains development guidelines and commands for agentic coding agents working in this repository.
This is an OpenSpec project - a specification-driven development workflow using the experimental artifact-driven approach. The project uses OpenSpec skills for managing changes through a structured workflow.
.opencode/- OpenCode plugin configuration and skillsopenspec/- OpenSpec configuration and changes directoryopenspec/config.yaml- OpenSpec project configurationopenspec/changes/- Active change directories (created dynamically)
This project uses uv for Python package management.
# Add dependencies
uv add <package-name>
# Install dependencies
uv sync
# Run commands
uv run <command>
uv run python <script.py>
# Create virtual environment
uv venv
# Install specific Python version
uv python install 3.14# List available schemas/workflows
openspec schemas --json
# List active changes
openspec list --json
# Create new change (using default schema)
openspec new change "<change-name>"
# Create change with specific schema
openspec new change "<change-name>" --schema <schema-name>
# Check change status
openspec status --change "<change-name>"
openspec status --change "<change-name>" --json
# Get artifact creation instructions
openspec instructions <artifact-id> --change "<change-name>"
# Get implementation instructions
openspec instructions apply --change "<change-name>" --json
# Archive completed change
openspec archive --change "<change-name>"Since this is a spec-driven workflow, "testing" typically involves:
- Verifying change status with
openspec status --change "<name>" - Running implementation with
/opsx-apply <change-name> - Verifying completion with status check
- Use kebab-case for change names (e.g.,
add-user-auth,fix-login-bug) - Names should be descriptive but concise
- Focus on the action or feature being implemented
- Default to the spec-driven schema unless explicitly requested
- The spec-driven workflow follows this artifact sequence:
proposal- High-level change descriptionspecs- Technical specificationsdesign- Design documents/decisionstasks- Implementation checklist
- Use
--schemaparameter only when user explicitly requests a different workflow
- Proposals: Keep under 500 words, always include "Non-goals" section
- Tasks: Break into chunks of max 2 hours of work
- Specs: Include technical requirements and API contracts
- Design: Document architectural decisions and trade-offs
- Changes are organized under
openspec/changes/<change-name>/ - Each change contains its artifacts as separate files
- Follow the artifact sequence specified by the schema
- Use standard Markdown formatting
- Include front matter with description for command files
- Use task lists (
- [ ]and- [x]) for tracking progress - Use code blocks with appropriate language identifiers
- Always validate change names (kebab-case required)
- Check for existing changes before creating new ones
- Verify artifact dependencies before proceeding
- Pause and ask for clarification when requirements are unclear
- Don't proceed with implementation if prerequisites are missing
- Exploration: Use
/opsx-explorefor thinking through requirements - Creation: Use
/opsx-newto start structured changes - Continuation: Use
/opsx-continueto create subsequent artifacts - Implementation: Use
/opsx-applyto execute tasks - Verification: Use
/opsx-verifyto validate implementation - Archival: Use
/opsx-archiveto complete changes
- Use the AskUserQuestion tool for open-ended user input
- Always announce which change is being worked on
- Show progress clearly (e.g., "3/7 tasks complete")
- Provide clear options when pausing due to issues
- Support fluid workflow - can interleave different actions
The openspec/config.yaml allows for project-specific context. Currently uses the default schema-driven workflow. Add your tech stack, conventions, and domain knowledge to the context section for AI assistance.
@opencode-ai/plugin(v1.1.50) - Main plugin functionality@opencode-ai/sdk(v1.1.50) - SDK integrationzod(v4.1.8) - Schema validation
- No Cursor or Copilot rules found in this repository
- No traditional build/test commands - this is a specification-driven project
- uv is the preferred package manager
- OpenSpec skills provide the primary development workflow
- Artifact-driven approach - changes progress through structured artifacts
- Fluid workflow - can move between creation and implementation phases
- Status-driven development - always check status before proceeding
After implementing changes:
- Run
openspec status --change "<name>"to verify all artifacts are complete - Use the implementation verification process with
/opsx-verify - Archive completed changes with
/opsx-archive
This ensures a clean, tracked development workflow with full traceability from specification to implementation.