* 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.
221 lines
5.6 KiB
Markdown
221 lines
5.6 KiB
Markdown
---
|
|
id: analyze-patterns
|
|
name: analyze-patterns
|
|
description: "Analyze codebase for patterns and similar implementations"
|
|
type: command
|
|
category: analysis
|
|
version: 1.0.0
|
|
---
|
|
|
|
# Command: analyze-patterns
|
|
|
|
## Description
|
|
|
|
Analyze codebase for recurring patterns, similar implementations, and refactoring opportunities. Replaces codebase-pattern-analyst subagent functionality with a command-based interface.
|
|
|
|
## Usage
|
|
|
|
```bash
|
|
/analyze-patterns [--pattern=<pattern>] [--language=<lang>] [--depth=<level>] [--output=<format>]
|
|
```
|
|
|
|
## Parameters
|
|
|
|
| Parameter | Type | Required | Description |
|
|
|-----------|------|----------|-------------|
|
|
| `--pattern` | string | No | Pattern name or regex to search for (e.g., "singleton", "factory", "error-handling") |
|
|
| `--language` | string | No | Filter by language: js, ts, py, go, rust, java, etc. |
|
|
| `--depth` | string | No | Search depth: shallow (current dir) \| medium (src/) \| deep (entire repo) |
|
|
| `--output` | string | No | Output format: text (default) \| json \| markdown |
|
|
|
|
## Behavior
|
|
|
|
### Pattern Search
|
|
- Searches codebase for pattern matches using regex + semantic analysis
|
|
- Identifies similar implementations across files
|
|
- Groups results by pattern type + similarity score
|
|
- Suggests refactoring opportunities
|
|
|
|
### Analysis Output
|
|
- Pattern occurrences with file locations + line numbers
|
|
- Similarity metrics (how similar are implementations?)
|
|
- Refactoring suggestions (consolidate, extract, standardize)
|
|
- Code quality insights (duplication, inconsistency)
|
|
|
|
### Result Format
|
|
```
|
|
Pattern Analysis Report
|
|
=======================
|
|
|
|
Pattern: [pattern_name]
|
|
Occurrences: [count]
|
|
Files: [file_list]
|
|
|
|
Implementations:
|
|
1. [file:line] - [description] (similarity: X%)
|
|
2. [file:line] - [description] (similarity: Y%)
|
|
...
|
|
|
|
Refactoring Suggestions:
|
|
- [suggestion 1]
|
|
- [suggestion 2]
|
|
...
|
|
|
|
Quality Insights:
|
|
- [insight 1]
|
|
- [insight 2]
|
|
...
|
|
```
|
|
|
|
## Examples
|
|
|
|
### Find all error handling patterns
|
|
```bash
|
|
/analyze-patterns --pattern="error-handling" --language=ts
|
|
```
|
|
|
|
### Analyze factory patterns across codebase
|
|
```bash
|
|
/analyze-patterns --pattern="factory" --depth=deep --output=json
|
|
```
|
|
|
|
### Find similar API endpoint implementations
|
|
```bash
|
|
/analyze-patterns --pattern="api-endpoint" --language=js --output=markdown
|
|
```
|
|
|
|
### Search for singleton patterns
|
|
```bash
|
|
/analyze-patterns --pattern="singleton" --depth=medium
|
|
```
|
|
|
|
## Implementation
|
|
|
|
### Delegation
|
|
- Delegates to: **opencoder** (primary)
|
|
- Uses context search capabilities for pattern matching
|
|
- Returns structured pattern analysis results
|
|
|
|
### Context Requirements
|
|
- Codebase structure + file organization
|
|
- Language-specific patterns + conventions
|
|
- Project-specific naming conventions
|
|
- Existing refactoring guidelines
|
|
|
|
### Processing Steps
|
|
1. Parse command parameters
|
|
2. Validate pattern syntax (regex or predefined)
|
|
3. Search codebase using glob + grep tools
|
|
4. Analyze semantic similarity of matches
|
|
5. Group results by pattern + similarity
|
|
6. Generate refactoring suggestions
|
|
7. Format output per requested format
|
|
8. Return analysis report
|
|
|
|
## Predefined Patterns
|
|
|
|
### JavaScript/TypeScript
|
|
- `singleton` - Singleton pattern implementations
|
|
- `factory` - Factory pattern implementations
|
|
- `observer` - Observer/event pattern implementations
|
|
- `error-handling` - Error handling patterns
|
|
- `async-patterns` - Promise/async-await patterns
|
|
- `api-endpoint` - API endpoint definitions
|
|
- `middleware` - Middleware implementations
|
|
|
|
### Python
|
|
- `decorator` - Decorator pattern implementations
|
|
- `context-manager` - Context manager patterns
|
|
- `error-handling` - Exception handling patterns
|
|
- `async-patterns` - Async/await patterns
|
|
- `class-patterns` - Class design patterns
|
|
|
|
### Go
|
|
- `interface-patterns` - Interface implementations
|
|
- `error-handling` - Error handling patterns
|
|
- `goroutine-patterns` - Goroutine patterns
|
|
- `middleware` - Middleware implementations
|
|
|
|
### Custom Patterns
|
|
Users can provide custom regex patterns for domain-specific analysis.
|
|
|
|
## Output Formats
|
|
|
|
### Text (Default)
|
|
Human-readable report with clear sections and formatting
|
|
|
|
### JSON
|
|
Structured data for programmatic processing:
|
|
```json
|
|
{
|
|
"pattern": "error-handling",
|
|
"occurrences": 12,
|
|
"files": ["file1.ts", "file2.ts"],
|
|
"implementations": [
|
|
{
|
|
"file": "file1.ts",
|
|
"line": 42,
|
|
"description": "try-catch block",
|
|
"similarity": 0.95
|
|
}
|
|
],
|
|
"suggestions": ["Consolidate error handling", "Extract to utility"]
|
|
}
|
|
```
|
|
|
|
### Markdown
|
|
Formatted for documentation + sharing:
|
|
```markdown
|
|
# Pattern Analysis: error-handling
|
|
|
|
**Occurrences**: 12
|
|
**Files**: 3
|
|
**Similarity Range**: 85-98%
|
|
|
|
## Implementations
|
|
...
|
|
```
|
|
|
|
## Integration
|
|
|
|
### Registry Entry
|
|
```json
|
|
{
|
|
"id": "analyze-patterns",
|
|
"name": "analyze-patterns",
|
|
"type": "command",
|
|
"category": "analysis",
|
|
"description": "Analyze codebase for patterns and similar implementations",
|
|
"delegates_to": ["opencoder"],
|
|
"parameters": ["pattern", "language", "depth", "output"]
|
|
}
|
|
```
|
|
|
|
### Profile Assignment
|
|
- **Developer Profile**: ✅ Included
|
|
- **Full Profile**: ✅ Included
|
|
- **Advanced Profile**: ✅ Included
|
|
- **Business Profile**: ❌ Not included
|
|
|
|
## Notes
|
|
|
|
- Replaces `codebase-pattern-analyst` subagent functionality
|
|
- Command-based interface is more flexible + discoverable
|
|
- Supports both predefined + custom patterns
|
|
- Results can be exported for documentation
|
|
- Integrates with refactoring workflows
|
|
|
|
---
|
|
|
|
## Validation Checklist
|
|
|
|
✅ Command structure defined
|
|
✅ Parameters documented
|
|
✅ Behavior specified
|
|
✅ Examples provided
|
|
✅ Implementation details included
|
|
✅ Output formats defined
|
|
✅ Integration ready
|
|
✅ Ready for registry integration
|
|
|
|
**Status**: Ready for deployment
|