* 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.
176 lines
4.5 KiB
Markdown
176 lines
4.5 KiB
Markdown
# Clean Code Principles
|
|
|
|
**Category**: development
|
|
**Purpose**: Core coding standards and best practices for writing clean, maintainable code
|
|
**Used by**: frontend-specialist, devops-specialist, opencoder
|
|
|
|
---
|
|
|
|
## Overview
|
|
|
|
Clean code is code that is easy to read, understand, and maintain. It follows consistent patterns, uses meaningful names, and is well-organized. This guide provides principles and patterns for writing clean code across all languages.
|
|
|
|
## Core Principles
|
|
|
|
### 1. Meaningful Names
|
|
|
|
**Use intention-revealing names**:
|
|
- Variable names should reveal intent
|
|
- Function names should describe what they do
|
|
- Class names should describe what they represent
|
|
|
|
**Examples**:
|
|
```javascript
|
|
// Bad
|
|
const d = new Date();
|
|
const x = getUserData();
|
|
|
|
// Good
|
|
const currentDate = new Date();
|
|
const activeUserProfile = getUserData();
|
|
```
|
|
|
|
### 2. Functions Should Do One Thing
|
|
|
|
**Single Responsibility**:
|
|
- Each function should have one clear purpose
|
|
- Functions should be small (ideally < 20 lines)
|
|
- Extract complex logic into separate functions
|
|
|
|
**Example**:
|
|
```javascript
|
|
// Bad
|
|
function processUser(user) {
|
|
validateUser(user);
|
|
saveToDatabase(user);
|
|
sendEmail(user);
|
|
logActivity(user);
|
|
}
|
|
|
|
// Good
|
|
function processUser(user) {
|
|
const validatedUser = validateUser(user);
|
|
const savedUser = saveUserToDatabase(validatedUser);
|
|
notifyUser(savedUser);
|
|
return savedUser;
|
|
}
|
|
```
|
|
|
|
### 3. Avoid Deep Nesting
|
|
|
|
**Keep nesting shallow**:
|
|
- Use early returns
|
|
- Extract nested logic into functions
|
|
- Prefer guard clauses
|
|
|
|
**Example**:
|
|
```javascript
|
|
// Bad
|
|
function processOrder(order) {
|
|
if (order) {
|
|
if (order.items.length > 0) {
|
|
if (order.total > 0) {
|
|
// process order
|
|
}
|
|
}
|
|
}
|
|
}
|
|
|
|
// Good
|
|
function processOrder(order) {
|
|
if (!order) return;
|
|
if (order.items.length === 0) return;
|
|
if (order.total <= 0) return;
|
|
|
|
// process order
|
|
}
|
|
```
|
|
|
|
### 4. DRY (Don't Repeat Yourself)
|
|
|
|
**Eliminate duplication**:
|
|
- Extract common logic into reusable functions
|
|
- Use composition over inheritance
|
|
- Create utility functions for repeated patterns
|
|
|
|
### 5. Error Handling
|
|
|
|
**Handle errors explicitly**:
|
|
- Use try-catch for expected errors
|
|
- Provide meaningful error messages
|
|
- Don't ignore errors silently
|
|
|
|
**Example**:
|
|
```javascript
|
|
// Bad
|
|
function fetchData() {
|
|
try {
|
|
return api.getData();
|
|
} catch (e) {
|
|
return null;
|
|
}
|
|
}
|
|
|
|
// Good
|
|
async function fetchData() {
|
|
try {
|
|
return await api.getData();
|
|
} catch (error) {
|
|
logger.error('Failed to fetch data', { error });
|
|
throw new DataFetchError('Unable to retrieve data', { cause: error });
|
|
}
|
|
}
|
|
```
|
|
|
|
## Best Practices
|
|
|
|
1. **Write self-documenting code** - Code should explain itself through clear naming and structure
|
|
2. **Keep functions pure when possible** - Avoid side effects, return new values instead of mutating
|
|
3. **Use consistent formatting** - Follow language-specific style guides (Prettier, ESLint, etc.)
|
|
4. **Write tests first** - TDD helps design better APIs and catch issues early
|
|
5. **Refactor regularly** - Improve code structure as you learn more about the domain
|
|
6. **Comment why, not what** - Code shows what, comments explain why
|
|
7. **Use type systems** - TypeScript, type hints, or static analysis tools
|
|
8. **Favor composition** - Build complex behavior from simple, reusable pieces
|
|
|
|
## Anti-Patterns
|
|
|
|
- ❌ **Magic numbers** - Use named constants instead of hardcoded values
|
|
- ❌ **God objects** - Classes that do too much or know too much
|
|
- ❌ **Premature optimization** - Optimize for readability first, performance second
|
|
- ❌ **Clever code** - Simple and clear beats clever and complex
|
|
- ❌ **Long parameter lists** - Use objects or configuration patterns instead
|
|
- ❌ **Boolean flags** - Often indicate a function doing multiple things
|
|
- ❌ **Mutable global state** - Leads to unpredictable behavior and bugs
|
|
|
|
## Language-Specific Guidelines
|
|
|
|
### JavaScript/TypeScript
|
|
- Use `const` by default, `let` when needed, never `var`
|
|
- Prefer arrow functions for callbacks
|
|
- Use async/await over raw promises
|
|
- Destructure objects and arrays for clarity
|
|
|
|
### Python
|
|
- Follow PEP 8 style guide
|
|
- Use list comprehensions for simple transformations
|
|
- Prefer context managers (`with` statements)
|
|
- Use type hints for function signatures
|
|
|
|
### Go
|
|
- Follow effective Go guidelines
|
|
- Use defer for cleanup
|
|
- Handle errors explicitly
|
|
- Keep interfaces small
|
|
|
|
### Rust
|
|
- Embrace ownership and borrowing
|
|
- Use pattern matching
|
|
- Prefer iterators over loops
|
|
- Handle errors with Result types
|
|
|
|
## References
|
|
|
|
- Clean Code by Robert C. Martin
|
|
- The Pragmatic Programmer by Hunt & Thomas
|
|
- Refactoring by Martin Fowler
|