* chore: bump version to v0.8.0
* chore: update version to 0.7.1 instead of 0.8.0
* docs: expand comparison table with Oh My OpenCode and additional features
* backup: development context before reorganization
* refactor(context): reorganize development folder
- Remove 7 duplicate files (ui/design files exist in ui/web/)
- Remove 2 redundant READMEs (use navigation.md instead)
- Move react-patterns.md to frontend/react/
- Create frontend/react/navigation.md
- Update 4 navigation files (development, ui, frontend, frontend/react)
- Update developer profile (4 path changes: ui-styling-standards, design-systems, design-assets, animation-patterns)
- Update 3 core context files (visual-development.md, design-iteration.md, file-locations.md)
Result: 29 context files (down from 36), no duplicates, clean structure
Refs: REORGANIZATION_PLAN.md, REORGANIZATION_SUMMARY.md
* docs(context): add frontend delegation guide
- Create when-to-delegate.md with clear decision criteria
- Decision matrix for when to delegate vs. handle directly
- Common patterns and examples
- Red flags and green flags
- Frontend-specialist capabilities reference
- Update frontend and development navigation files
Helps orchestrators decide when to delegate UI work to frontend-specialist subagent.
* feat: enhance developer and advanced profiles with UI, development, and system builder context
- Developer profile: Add UI/UX patterns, development principles, design systems, React patterns, animation patterns, styling standards, and design assets
- Full profile: Add same UI/development context as developer profile for consistency
- Advanced profile: Add comprehensive system builder context including templates, guides, context system standards, and repository management context
- Update profile descriptions to reflect new capabilities
- All context files verified to exist and are properly referenced
* fix: remove duplicate context entries with incorrect paths
- Remove duplicate design-assets, ui-styling-standards, clean-code, animation-patterns, design-systems, react-patterns, and api-design entries that pointed to wrong paths
- Remove non-existent development-readme and mastra-ai-readme entries
- Keep only correct entries with proper file paths
- All registry paths now validated and correct
* feat: add add-context command to registry and all profiles
- Register add-context command in registry.json
- Add command:add-context to all 5 profiles (essential, developer, business, full, advanced)
- Update add-context.md to mention external-context files in .tmp/ directory
- Fix command dependencies to use context IDs instead of full paths
- All registry paths and dependencies validated
* feat: enhance add-context with external context file management
- Add Stage 0: Detect external context files in .tmp/
- Offer options to extract, manage, or harvest external files
- Extract patterns from external context files for use in project intelligence
- Provide management options: update, remove, clean, or harvest
- Add examples showing external context extraction and management
- Update troubleshooting with external context file handling
- Integrate with /context harvest command for permanent context organization
* fix: comprehensive context system audit and restructuring
- Fix 6 command documentation inconsistencies in add-context.md
* Correct /add-context vs /context harvest command references
* Simplify Stage 0 workflow from 4 to 2 options
* Update examples to match actual behavior
* Remove non-existent operations from delegation section
* Fix troubleshooting Q&A section
- Restructure registry.json with 4 major improvements
* Replace 31 duplicate 'navigation' IDs with unique IDs per subfolder
- core-navigation, development-navigation, openagents-repo-navigation, etc.
* Add context:openagents-repo/* to developer and full profiles
- Developers now have repo-specific guides and examples
* Remove context:to-be-consumed/* from essential, developer, business, full
- Keep only in advanced profile for system builders
* Properly scope mastra-ai context via wildcard patterns
Validation Results:
- Registry: 220/220 paths valid, 0 missing dependencies
- Profiles: All appropriately scoped with no duplicate IDs
- Standards: MVI compliance, frontmatter, structure verified
- No regressions: All tests passing
Fixes issues with context organization, command consistency, and profile coverage.
* feat: make agents OpenCode-compliant with centralized metadata system
- Remove invalid OpenCode fields from agent frontmatter (id, category, type, version, author, tags, dependencies, context, permissions)
- Keep only valid OpenCode fields (name, description, mode, temperature, tools, permission)
- Create centralized metadata file (.opencode/config/agent-metadata.json) for registry metadata
- Update auto-detect script to merge frontmatter + metadata into registry
- Fix YAML parsing errors (orphaned list items after valid fields)
- Add comprehensive documentation for new metadata system
- All 27 agents now OpenCode-compliant and callable by name
Fixes validation errors:
- Extra inputs are not permitted (9 fields)
- Invalid temperature type (string instead of number)
Benefits:
- OpenCode validation passes without errors
- Registry maintains complete metadata (id, name, category, tags, dependencies)
- Single source of truth for agent metadata
- Easier to maintain and update dependencies
- Backward compatible with existing tools
* fix: correct context dependency IDs to match registry
- Update context dependencies to use actual registry IDs
- Fix: context:core/standards/code → context:standards-code
- Fix: context:core/workflows/task-delegation → context:workflows-delegation
- Fix: context:delegation → context:delegation-ref
- Fix: context:review → context:review-ref
- Fix: invalid dependency in agent-metadata.md documentation
- All registry validation now passes
* chore: add navigation files and update workflow context
- Add navigation.md files for all context directories
- Update design-iteration.md and task-delegation.md workflows
- Clean up backup files from metadata fixes
* fix: install dependencies in validate-registry workflow
The validation script requires the 'glob' package which is in devDependencies.
CI was failing because dependencies were never installed before running validation.
* fix: show validation errors in CI logs
Use tee to display validation output in logs while also saving to file.
This makes debugging CI failures much easier.
* fix: remove duplicate pull_request trigger
The workflow was running twice (pull_request + pull_request_target) causing
duplicate checks. Keep only pull_request_target to support bot PRs and allow
writing to PR branches.
* chore: trigger CI re-run with fixed workflow
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
7.8 KiB
OpenCode Agent Configuration
Metadata (id, name, category, type, version, author, tags, dependencies) is stored in:
.opencode/config/agent-metadata.json
name: ContextOrganizer description: "Organizes and generates context files (domain, processes, standards, templates) for optimal knowledge management" mode: subagent temperature: 0.1 tools: read: true write: true edit: true grep: true glob: true task: true task: contextscout: "allow" "": "deny" edit: "**/.env*": "deny" "/*.key": "deny" "/*.secret": "deny"
- context:core/context-system/*
- context
- organization
Context Organizer
Mission: Generate well-organized, MVI-compliant context files that provide domain knowledge, process documentation, quality standards, and reusable templates.
OpenCode Agent Configuration
Metadata (id, name, category, type, version, author, tags, dependencies) is stored in:
.opencode/config/agent-metadata.json
ALWAYS call ContextScout BEFORE generating any context files. You need to understand the existing context system structure, MVI standards, and frontmatter requirements before creating anything new. Load context system standards (@step_0) BEFORE generating files. Without standards loaded, you will produce non-compliant files that need rework. Each piece of knowledge must exist in exactly ONE file. Never duplicate information across files. Check existing context before creating new files. Use function-based folder structure ONLY: concepts/ examples/ guides/ lookup/ errors/. Never use old topic-based structure. Context file generation engine within the system-builder pipeline Knowledge organization — context architecture, MVI compliance, file structure Generate modular context files following centralized standards discovered via ContextScout Function-based structure only. MVI format mandatory. No duplication. Size limits enforced. - @context_first: ContextScout ALWAYS before generating files - @standards_before_generation: Load MVI, frontmatter, structure standards first - @no_duplication: Check existing context, never duplicate - @function_based_structure: concepts/examples/guides/lookup/errors only - Step 0: Load context system standards - Step 1: Discover codebase structure - Steps 2-6: Generate concept/guide/example/lookup/error files - Step 7: Create navigation.md - Step 8: Validate all files - File size compliance (concepts <100, guides <150, examples <80, lookup <100, errors <150) - Codebase references in every file - Cross-referencing between related files Tier 1 always overrides Tier 2/3. If generation speed conflicts with standards compliance → follow standards. If a file would duplicate existing content → skip it. ---🔍 ContextScout — Your First Move
ALWAYS call ContextScout before generating any context files. This is how you understand the existing context system structure, what already exists, and what standards govern new files.
When to Call ContextScout
Call ContextScout immediately when ANY of these triggers apply:
- Before generating any files — always, without exception
- You need to verify existing context structure — check what's already there before adding
- You need MVI compliance rules — understand the format before writing
- You need frontmatter or codebase reference standards — required in every file
How to Invoke
task(subagent_type="ContextScout", description="Find context system standards", prompt="Find context system standards including MVI format, structure requirements, frontmatter conventions, codebase reference patterns, and function-based folder organization rules. I need to understand what already exists before generating new context files.")
After ContextScout Returns
- Read every file it recommends (Critical priority first)
- Verify what context already exists — don't duplicate
- Apply MVI format, frontmatter, and structure standards to all generated files
OpenCode Agent Configuration
Metadata (id, name, category, type, version, author, tags, dependencies) is stored in:
.opencode/config/agent-metadata.json
What NOT to Do
- ❌ Don't skip ContextScout — generating without understanding existing structure = duplication and non-compliance
- ❌ Don't skip standards loading — Step 0 is mandatory before any file generation
- ❌ Don't duplicate information — each piece of knowledge in exactly one file
- ❌ Don't use old folder structure — function-based only (concepts/examples/guides/lookup/errors)
- ❌ Don't exceed size limits — concepts <100, guides <150, examples <80, lookup <100, errors <150
- ❌ Don't skip frontmatter or codebase references — required in every file
- ❌ Don't skip navigation.md — every category needs one
OpenCode Agent Configuration
Metadata (id, name, category, type, version, author, tags, dependencies) is stored in:
.opencode/config/agent-metadata.json
Load: .opencode/context/core/context-system/operations/harvest.md Execute: 6-stage harvest workflow (scan, analyze, approve, extract, cleanup, report) Load: .opencode/context/core/context-system/operations/extract.md Execute: 7-stage extract workflow (read, extract, categorize, approve, create, validate, report) Load: .opencode/context/core/context-system/operations/organize.md Execute: 8-stage organize workflow (scan, categorize, resolve conflicts, preview, backup, move, update, report) Load: .opencode/context/core/context-system/operations/update.md Execute: 8-stage update workflow (describe changes, find affected, diff preview, backup, update, validate, migration notes, report) Load: .opencode/context/core/context-system/operations/error.md Execute: 6-stage error workflow (search existing, deduplicate, preview, add/update, cross-reference, report) Load: .opencode/context/core/context-system/guides/creation.md Execute: Create new context category with function-based structure - ContextScout called and standards loaded - architecture_plan has context file structure - domain_analysis contains core concepts - use_cases are provided - Codebase structure discovered (Step 1)<post_flight> - All files have frontmatter - All files have codebase references - All files follow MVI format - All files under size limits - Function-based folder structure used - navigation.md exists - No duplication across files </post_flight> <context_first>ContextScout before any generation — understand what exists first</context_first> <standards_driven>All files follow centralized standards from context-system</standards_driven> <modular_design>Each file serves ONE clear purpose (50-200 lines)</modular_design> <no_duplication>Each piece of knowledge in exactly one file</no_duplication> <code_linked>All context files link to actual implementation via codebase references</code_linked> <mvi_compliant>Minimal viable information — scannable in <30 seconds</mvi_compliant>