* feat: add npm package support for @openagents/control
- Convert package to publishable npm package with scoped name @openagents/control
- Add CLI entry point bin/oac.js for global installation
- Create .npmignore to exclude dev files and node_modules
- Configure package.json with proper files, bin, and metadata
- Add comprehensive NPM_PUBLISHING_GUIDE.md with publishing instructions
- Package size: 610KB (2.4MB unpacked) with 353 files
- Includes .opencode/tool/ directory without node_modules
- CLI command: oac (e.g., 'oac developer' or 'oac --help')
Users can install with: npm install -g @openagents/control
* chore: remove telegram bot files from package
- Delete .opencode/_lib/telegram-bot.ts (unused)
- Delete .opencode/plugin/telegram-notify.ts (depends on deleted file)
- Remove _lib directory reference from package.json files field
- Reduces package size from 610KB to 607KB
- Total files: 351 (down from 353)
* chore: remove all telegram references from registry and docs
- Remove telegram-bot and telegram-notify plugin entries from registry.json
- Remove telegram plugin references from all profiles (developer, business, full, advanced)
- Update profile-validation.md to remove telegram from business profile documentation
- Clean package with no telegram dependencies
* docs: enhance README clarity and add configuration examples
- Add Core Philosophy section with 4 key principles
- Add Quick Concepts for First-Time Users (scannable format)
- Add prominent Oh My OpenCode comparison link
- Add comprehensive Model Configuration section
- Add Customizing Agents section with practical examples
- Streamline model selection recommendations
- Add emoji headers for visual consistency
- Remove redundant FAQ entry
Addresses user feedback about documentation clarity and first-time user experience.
* refactor: remove OpenImplementer agent
- Delete OpenImplementer agent file (redundant with OpenAgent)
- Remove from registry.json and all profiles
- Update OpenCoder delegation rules (now handles 1-4 files directly)
- Clean up all context file references
- Remove from commands and documentation
Rationale: OpenImplementer only added 1 file to OpenAgent's capability (3→4 files), creating unnecessary complexity. OpenAgent and OpenCoder provide clearer separation: OpenAgent for general + focused tasks (1-4 files), OpenCoder for complex architecture (4+ files).
* fix: remove stale OpenImplementer reference from OpenCoder
- Remove OpenImplementer from Available Subagents list
- Clarify CoderAgent is used via TaskManager for complex tasks
- Keep delegation rules as-is (execute 1-4 files directly, delegate complex to CoderAgent)
* docs: remove remaining OpenImplementer references
- Update developer profile description (OpenAgent vs OpenCoder)
- Update registry.json profile description
- Update docs/README.md to remove OpenImplementer
- Update CHANGELOG.md to reflect simplified architecture
All OpenImplementer references now removed. Registry validation passes.
* docs: enhance README with first-time user improvements
- Add 'your secret weapon!' to Context System in Quick Concepts
- Add First-Time User Checklist after Get Started section
- Add visual comparison table for AOC vs Oh My OpenCode in FAQ
- Improve scannability and clarity for new users
Based on DocWriter review recommendations.
* docs: clarify project-context.md is created during installation
Minor enhancement to First-Time User Checklist step 2 for extra clarity.
* docs: change 'I' to 'we' for collaborative tone
- Update 'Why I Built This' to 'Why We Built This'
- Change 'I've spent' to 'We've spent'
- Change 'I use this' to 'We use this'
- Makes the project feel more collaborative and team-oriented
* docs: make intro more neutral and objective
- Change 'Why We Built This' to 'Why This Exists'
- Remove personal perspective ('We've spent 14+ years')
- Change 'We use this' to 'It's built for shipping'
- More professional and objective tone
* docs: major README rewrite based on user feedback
Key improvements based on real user confusion:
1. **Clear 'What Is AOC?' section** - Explains scaffold vs plugin approach upfront
2. **Model configuration prominently featured** - Addresses #1 user question
3. **Hook with quantified paradox** - Grabs attention in 15 seconds
4. **Context System promoted** - Moved to top, explains the differentiator
5. **Comparison table** - AOC vs Oh My OpenCode side-by-side
6. **Eliminated 60% redundancy** - Merged overlapping sections
7. **Simplified deep dives** - Model config and customization tightened
Based on user feedback: 'I just expected that behaviour because it was not
documented properly... the only thing really lacking was a clear explanation
of its purpose and how to configure models and adjust agents.'
Addresses: Confusion about scaffold vs plugin, model configuration, and
first-time user expectations.
* chore: publish package as @nextsystems/oac v0.7.0
- Changed package name from @openagents/control to @nextsystems/oac
- Successfully published to npm registry
- Users can install with: npm install -g @nextsystems/oac
- CLI command: oac
* feat: add context path configuration and reorganize documentation
- Add configurable context root via paths.json (@reference support)
- Add /add-context command for interactive context setup
- Move NPM_PUBLISHING_GUIDE.md to context system (guides/npm-publishing.md)
- Add GitHub issues workflow guide
- Update agents to support custom context directories
- Update navigation with new guides and file counts
This enables projects to use custom context directories (e.g., .context, .ai/context)
while maintaining backward compatibility with default .opencode/context/ structure.
10 KiB
Core Concept: Registry System
Purpose: Understanding how component tracking and distribution works
Priority: CRITICAL - Load this before working with registry
What Is the Registry?
The registry is a centralized catalog (registry.json) that tracks all components in OpenAgents Control:
- Agents - AI agent prompts
- Subagents - Delegated specialists
- Commands - Slash commands
- Tools - Custom tools
- Contexts - Context files
Location: registry.json (root directory)
Registry Schema
Top-Level Structure
{
"version": "0.5.0",
"schema_version": "2.0.0",
"components": {
"agents": [...],
"subagents": [...],
"commands": [...],
"tools": [...],
"contexts": [...]
},
"profiles": {
"essential": {...},
"developer": {...},
"business": {...}
}
}
Component Entry
{
"id": "frontend-specialist",
"name": "Frontend Specialist",
"type": "agent",
"path": ".opencode/agent/development/frontend-specialist.md",
"description": "Expert in React, Vue, and modern CSS",
"category": "development",
"tags": ["react", "vue", "css", "frontend"],
"dependencies": ["subagent:tester"],
"version": "0.5.0"
}
Fields:
id: Unique identifier (kebab-case)name: Display nametype: Component type (agent, subagent, command, tool, context)path: File path relative to repo rootdescription: Brief descriptioncategory: Category name (for agents)tags: Optional tags for discoverydependencies: Optional dependenciesversion: Version when added/updated
Auto-Detect System
The auto-detect system scans .opencode/ and automatically updates the registry.
How It Works
1. Scan .opencode/ directory
2. Find all .md files with frontmatter
3. Extract metadata (description, category, type, tags)
4. Validate paths exist
5. Generate component entries
6. Update registry.json
Running Auto-Detect
# Dry run (see what would be added)
./scripts/registry/auto-detect-components.sh --dry-run
# Actually add components
./scripts/registry/auto-detect-components.sh --auto-add
# Force update existing entries
./scripts/registry/auto-detect-components.sh --auto-add --force
What Gets Detected
✅ Agents - .opencode/agent/{category}/*.md
✅ Subagents - .opencode/agent/subagents/**/*.md
✅ Commands - .opencode/command/**/*.md
✅ Tools - .opencode/tool/**/index.ts
✅ Contexts - .opencode/context/**/*.md
Frontmatter Requirements
For auto-detect to work, files must have frontmatter:
---
description: "Brief description"
category: "category-name" # For agents
type: "agent" # Or subagent, command, tool, context
tags: ["tag1", "tag2"] # Optional
---
Validation
Registry Validation
# Validate registry
./scripts/registry/validate-registry.sh
# Verbose output
./scripts/registry/validate-registry.sh -v
What Gets Validated
✅ Schema - Correct JSON structure
✅ Paths - All paths exist
✅ IDs - Unique IDs
✅ Categories - Valid categories
✅ Dependencies - Dependencies exist
✅ Versions - Version consistency
Validation Errors
# Example errors
ERROR: Path does not exist: .opencode/agent/core/missing.md
ERROR: Duplicate ID: frontend-specialist
ERROR: Invalid category: invalid-category
ERROR: Missing dependency: subagent:nonexistent
Agents vs Subagents
Main Agents (2 in Developer profile):
- openagent: Universal coordination agent
- opencoder: Complex coding and architecture
Specialist Subagents (8 in Developer profile):
-
frontend-specialist: React, Vue, CSS architecture
-
devops-specialist: CI/CD, infrastructure, deployment
-
task-manager: Feature breakdown and planning
-
documentation: Create and update docs
-
coder-agent: Execute coding subtasks
-
reviewer: Code review and security
-
tester: Write unit and integration tests
-
build-agent: Type checking and validation
-
image-specialist: Generate and edit images
Commands (7 in Developer profile):
- analyze-patterns: Analyze codebase for patterns
- commit, test, context, clean, optimize, validate-repo
Component Profiles
Profiles are pre-configured component bundles for quick installation.
Available Profiles
Essential Profile
Purpose: Minimal setup for basic usage
Includes:
- Core agents (openagent, opencoder)
- Essential commands (commit, test)
- Core context files
"essential": {
"description": "Minimal setup for basic usage",
"components": [
"agent:openagent",
"agent:opencoder",
"command:commit",
"command:test"
]
}
Developer Profile
Purpose: Full development setup
Includes:
- All core agents
- Development specialists
- All subagents
- Dev commands
- Dev context files
"developer": {
"description": "Full development setup",
"components": [
"agent:*",
"subagent:*",
"command:*",
"context:core/*",
"context:development/*"
]
}
Business Profile
Purpose: Content and product focus
Includes:
- Core agents
- Content specialists
- Product specialists
- Content context files
"business": {
"description": "Content and product focus",
"components": [
"agent:openagent",
"agent:copywriter",
"agent:technical-writer",
"context:core/*",
"context:content/*"
]
}
Install System
The install system uses the registry to distribute components.
Installation Flow
1. User runs install.sh
2. Check for local registry.json (development mode)
3. If not local, fetch from GitHub (production mode)
4. Parse registry.json
5. Show component selection UI
6. Resolve dependencies
7. Download components from GitHub
8. Install to .opencode/
9. Handle collisions (skip/overwrite/backup)
Local Registry (Development)
# Test with local registry
REGISTRY_URL="file://$(pwd)/registry.json" ./install.sh --list
# Install with local registry
REGISTRY_URL="file://$(pwd)/registry.json" ./install.sh developer
Remote Registry (Production)
# Install from GitHub
./install.sh developer
# List available components
./install.sh --list
Dependency Resolution
Dependency Format
"dependencies": [
"subagent:tester",
"context:core/standards/code"
]
Resolution Rules
- Parse dependency string (
type:id) - Find component in registry
- Check if already installed
- Add to install queue
- Recursively resolve dependencies
- Install in dependency order
Example
User installs: frontend-specialist
↓
Depends on: subagent:tester
↓
Depends on: context:core/standards/tests
↓
Install order:
1. context:core/standards/tests
2. subagent:tester
3. frontend-specialist
Collision Handling
When installing components that already exist:
Collision Strategies
- Skip - Keep existing file
- Overwrite - Replace with new file
- Backup - Backup existing, install new
Interactive Mode
File exists: .opencode/agent/core/openagent.md
[S]kip, [O]verwrite, [B]ackup, [A]ll skip, [F]orce all?
Non-Interactive Mode
# Skip all collisions
./install.sh developer --skip-existing
# Overwrite all collisions
./install.sh developer --force
# Backup all collisions
./install.sh developer --backup
Version Management
Version Fields
- Registry version: Overall registry version (e.g., "0.5.0")
- Schema version: Registry schema version (e.g., "2.0.0")
- Component version: When component was added/updated
Version Consistency
# Check version consistency
cat VERSION
cat package.json | jq '.version'
cat registry.json | jq '.version'
# All should match
Updating Versions
# Bump version
echo "0.X.Y" > VERSION
jq '.version = "0.X.Y"' package.json > tmp && mv tmp package.json
jq '.version = "0.X.Y"' registry.json > tmp && mv tmp registry.json
CI/CD Integration
GitHub Workflows
Validate Registry (PR Checks)
# .github/workflows/validate-registry.yml
- name: Validate Registry
run: ./scripts/registry/validate-registry.sh
Auto-Update Registry (Post-Merge)
# .github/workflows/update-registry.yml
- name: Update Registry
run: ./scripts/registry/auto-detect-components.sh --auto-add
Version Bump (On Release)
# .github/workflows/version-bump.yml
- name: Bump Version
run: ./scripts/versioning/bump-version.sh
Best Practices
Adding Components
✅ Add frontmatter - Required for auto-detect
✅ Run auto-detect - Don't manually edit registry
✅ Validate - Always validate after changes
✅ Test locally - Use local registry for testing
Maintaining Registry
✅ Auto-detect first - Let scripts handle updates
✅ Validate often - Catch issues early
✅ Version consistency - Keep versions in sync
✅ CI validation - Automate validation in CI
Dependencies
✅ Explicit dependencies - List all dependencies
✅ Test resolution - Verify dependencies resolve
✅ Avoid cycles - No circular dependencies
Common Issues
Path Not Found
Problem: Registry references non-existent path
Solution: Run auto-detect or fix path manually
Duplicate ID
Problem: Two components with same ID
Solution: Rename one component
Invalid Category
Problem: Agent has invalid category
Solution: Use valid category (core, development, content, data, product, learning)
Missing Dependency
Problem: Dependency doesn't exist in registry
Solution: Add dependency or remove reference
Version Mismatch
Problem: VERSION, package.json, registry.json don't match
Solution: Update all version files to match
Related Files
- Updating registry:
guides/updating-registry.md - Adding agents:
guides/adding-agent.md - Categories:
core-concepts/categories.md
Last Updated: 2025-01-28
Version: 0.5.2