oh-my-customcode 0.1.3 → 0.2.0

package/templates/agents/sw-engineer/language/python-expert/index.yaml

@@ -1,27 +0,0 @@
-# Python Expert Agent
-
-metadata:
-  name: python-expert
-  type: sw-engineer/language
-  description: Expert Python developer following PEP 8 and Pythonic principles
-
-source:
-  type: internal
-
-capabilities:
-  - Write idiomatic Python code
-  - Review and refactor Python code
-  - Design clean APIs
-  - Implement exception handling
-  - Optimize Python performance
-  - Apply Zen of Python
-
-skills:
-  - name: python-best-practices
-    path: ../../../../skills/development/python-best-practices/
-    required: true
-
-guides:
-  - name: python
-    path: ../../../../guides/python/
-    required: true

package/templates/agents/sw-engineer/language/python-expert/refs/python/index.yaml

@@ -1,26 +0,0 @@
-# Python Guide
-
-metadata:
-  name: python
-  description: Python language reference documentation
-
-source:
-  type: external
-  origin: python.org
-  urls:
-    - https://peps.python.org/pep-0008/
-    - https://peps.python.org/pep-0020/
-    - https://google.github.io/styleguide/pyguide.html
-  last_fetched: "2026-01-22"
-
-documents:
-  - name: pep8-style-guide
-    path: ./pep8-style-guide.md
-    description: PEP 8 - Official Python Style Guide
-
-  - name: zen-of-python
-    path: ./zen-of-python.md
-    description: PEP 20 - The Zen of Python
-
-used_by:
-  - python-expert

package/templates/agents/sw-engineer/language/python-expert/refs/python/pep8-style-guide.md

@@ -1,202 +0,0 @@
-# PEP 8 - Style Guide for Python Code
-
-> Source: https://peps.python.org/pep-0008/
-
-## Introduction
-
-This document gives coding conventions for the Python code comprising the standard library. The key insight is that code is read much more often than it is written. Prioritize readability.
-
-## Code Layout
-
-### Indentation
-
-Use 4 spaces per indentation level.
-
-```python
-# Aligned with opening delimiter
-foo = long_function_name(var_one, var_two,
-                         var_three, var_four)
-
-# Hanging indent with additional level
-def long_function_name(
-        var_one, var_two, var_three,
-        var_four):
-    print(var_one)
-```
-
-### Maximum Line Length
-
-- Limit all lines to 79 characters
-- Docstrings/comments: limit to 72 characters
-- Teams may agree on longer lines (up to 99)
-
-### Binary Operators
-
-Break before binary operators:
-
-```python
-# Correct:
-income = (gross_wages
-          + taxable_interest
-          + (dividends - qualified_dividends))
-```
-
-### Blank Lines
-
-- Two blank lines around top-level definitions
-- One blank line between method definitions
-- Extra blank lines sparingly to separate logical sections
-
-## Imports
-
-```python
-# Standard library
-import os
-import sys
-
-# Third party
-import numpy as np
-
-# Local
-from myproject import mymodule
-```
-
-Rules:
-- One import per line
-- Absolute imports preferred
-- Avoid wildcard imports
-
-## Whitespace
-
-```python
-# Correct:
-spam(ham[1], {eggs: 2})
-x = 1
-y = 2
-long_variable = 3
-
-# Wrong:
-spam( ham[ 1 ], { eggs: 2 } )
-x             = 1
-y             = 2
-long_variable = 3
-```
-
-## Comments
-
-### Block Comments
-
-```python
-# This is a block comment that
-# spans multiple lines and describes
-# the following code block.
-```
-
-### Inline Comments
-
-```python
-x = x + 1  # Increment x
-```
-
-### Docstrings
-
-```python
-def complex(real=0.0, imag=0.0):
-    """Form a complex number.
-
-    Keyword arguments:
-    real -- the real part (default 0.0)
-    imag -- the imaginary part (default 0.0)
-    """
-    pass
-```
-
-## Naming Conventions
-
-| Type | Convention | Example |
-|------|------------|---------|
-| Module | lowercase_underscore | `my_module` |
-| Package | lowercase | `mypackage` |
-| Class | CapWords | `MyClass` |
-| Exception | CapWords + Error | `CustomError` |
-| Function | lowercase_underscore | `my_function` |
-| Variable | lowercase_underscore | `my_var` |
-| Constant | UPPER_UNDERSCORE | `MAX_SIZE` |
-| Method | lowercase_underscore | `my_method` |
-
-### Special Naming
-
-- `_single_leading`: weak "internal use" indicator
-- `__double_leading`: name mangling in classes
-- `__double_both__`: "magic" methods
-
-## Programming Recommendations
-
-### Comparisons
-
-```python
-# Correct:
-if foo is not None:
-if isinstance(obj, int):
-
-# Wrong:
-if foo != None:
-if type(obj) is int:
-```
-
-### Sequences
-
-```python
-# Correct:
-if not seq:
-if seq:
-
-# Wrong:
-if len(seq) == 0:
-if len(seq) > 0:
-```
-
-### Exception Handling
-
-```python
-# Correct:
-try:
-    value = collection[key]
-except KeyError:
-    return key_not_found(key)
-
-# Wrong:
-try:
-    value = collection[key]
-except:  # Bare except
-    return key_not_found(key)
-```
-
-### Context Managers
-
-```python
-# Correct:
-with open('file.txt') as f:
-    contents = f.read()
-
-# Wrong:
-f = open('file.txt')
-contents = f.read()
-f.close()
-```
-
-### Return Statements
-
-```python
-# Correct:
-def foo(x):
-    if x >= 0:
-        return math.sqrt(x)
-    else:
-        return None
-
-# Wrong:
-def foo(x):
-    if x >= 0:
-        return math.sqrt(x)
-```

package/templates/agents/sw-engineer/language/python-expert/refs/python/zen-of-python.md

@@ -1,79 +0,0 @@
-# The Zen of Python (PEP 20)
-
-> Source: https://peps.python.org/pep-0020/
-
-Long time Pythoneer Tim Peters succinctly channels the BDFL's guiding principles for Python's design into 20 aphorisms, only 19 of which have been written down.
-
-```
->>> import this
-```
-
-## The 19 Aphorisms
-
-1. **Beautiful is better than ugly.**
-   - Write elegant, readable code
-
-2. **Explicit is better than implicit.**
-   - Don't hide behavior; make intentions clear
-
-3. **Simple is better than complex.**
-   - Choose straightforward solutions
-
-4. **Complex is better than complicated.**
-   - When complexity is needed, keep it manageable
-
-5. **Flat is better than nested.**
-   - Avoid deep nesting; keep structures flat
-
-6. **Sparse is better than dense.**
-   - Don't pack too much into one line
-
-7. **Readability counts.**
-   - Code is read more often than written
-
-8. **Special cases aren't special enough to break the rules.**
-   - Consistency matters
-
-9. **Although practicality beats purity.**
-   - Be pragmatic when needed
-
-10. **Errors should never pass silently.**
-    - Handle or propagate errors explicitly
-
-11. **Unless explicitly silenced.**
-    - Intentional suppression is acceptable
-
-12. **In the face of ambiguity, refuse the temptation to guess.**
-    - Ask for clarification; don't assume
-
-13. **There should be one-- and preferably only one --obvious way to do it.**
-    - Python favors one canonical approach
-
-14. **Although that way may not be obvious at first unless you're Dutch.**
-    - (A nod to Guido van Rossum)
-
-15. **Now is better than never.**
-    - Don't over-plan; start implementing
-
-16. **Although never is often better than *right* now.**
-    - But don't rush without thought
-
-17. **If the implementation is hard to explain, it's a bad idea.**
-    - Complexity is a warning sign
-
-18. **If the implementation is easy to explain, it may be a good idea.**
-    - Simplicity suggests good design
-
-19. **Namespaces are one honking great idea -- let's do more of those!**
-    - Organize code into clear namespaces
-
-## Application
-
-When writing Python code, ask yourself:
-- Is this beautiful or ugly?
-- Is this explicit or implicit?
-- Is this simple or complex?
-- Is this readable?
-- Could I easily explain this to someone else?
-
-The Zen of Python is not just style guidance—it's a philosophy for writing maintainable, understandable code.

package/templates/agents/sw-engineer/language/python-expert/refs/python-best-practices/index.yaml

@@ -1,25 +0,0 @@
-# Python Best Practices Skill
-
-metadata:
-  name: python-best-practices
-  category: development
-  description: Pythonic patterns from PEP 8 and PEP 20
-
-source:
-  type: internal
-  reference:
-    - https://peps.python.org/pep-0008/
-    - https://peps.python.org/pep-0020/
-    - https://google.github.io/styleguide/pyguide.html
-
-provides:
-  - Python code formatting standards
-  - Naming conventions
-  - Import organization
-  - Whitespace rules
-  - Comment and docstring guidelines
-  - Programming recommendations
-  - Pythonic idioms
-
-used_by:
-  - python-expert

package/templates/agents/sw-engineer/language/rust-expert/AGENT.md

@@ -1,47 +0,0 @@
-# Rust Expert Agent
-
-> **Type**: SW Engineer
-> **Source**: Internal
-
-## Purpose
-
-Expert Rust developer specialized in writing safe, performant, and idiomatic Rust code following official guidelines and community best practices.
-
-## Capabilities
-
-1. Write idiomatic Rust code following official style guide
-2. Design safe APIs leveraging Rust's type system
-3. Implement zero-cost abstractions
-4. Manage ownership, borrowing, and lifetimes correctly
-5. Write efficient concurrent code with fearless concurrency
-6. Optimize for performance without sacrificing safety
-
-## When to Use
-
-- Writing new Rust applications or libraries
-- Reviewing existing Rust code for improvements
-- Designing safe and ergonomic APIs
-- Debugging ownership and lifetime issues
-- Implementing high-performance systems
-
-## Skills
-
-| Skill | Purpose |
-|-------|---------|
-| rust-best-practices | Core Rust development guidelines |
-
-## Guides
-
-| Guide | Purpose |
-|-------|---------|
-| rust | Reference documentation from official Rust docs |
-
-## Workflow
-
-```
-1. Understand requirements
-2. Apply rust-best-practices skill
-3. Reference rust guide for specific patterns
-4. Write/review code with ownership safety
-5. Ensure idiomatic patterns and zero-cost abstractions
-```

package/templates/agents/sw-engineer/language/rust-expert/index.yaml

@@ -1,27 +0,0 @@
-# Rust Expert Agent
-
-metadata:
-  name: rust-expert
-  type: sw-engineer/language
-  description: Expert Rust developer with focus on safety and performance
-
-source:
-  type: internal
-
-capabilities:
-  - Write idiomatic Rust code
-  - Design safe APIs
-  - Implement zero-cost abstractions
-  - Manage ownership and lifetimes
-  - Write concurrent code safely
-  - Optimize for performance
-
-skills:
-  - name: rust-best-practices
-    path: ../../../../skills/development/rust-best-practices/
-    required: true
-
-guides:
-  - name: rust
-    path: ../../../../guides/rust/
-    required: true

package/templates/agents/sw-engineer/language/rust-expert/refs/rust/error-handling.md

@@ -1,262 +0,0 @@
-# Rust Error Handling
-
-> Reference for error handling patterns in Rust
-
-## Result Type
-
-```rust
-enum Result<T, E> {
-    Ok(T),
-    Err(E),
-}
-```
-
-### Basic Usage
-
-```rust
-use std::fs::File;
-
-fn main() {
-    let f = File::open("hello.txt");
-
-    let f = match f {
-        Ok(file) => file,
-        Err(error) => panic!("Problem opening file: {:?}", error),
-    };
-}
-```
-
-### Matching Different Errors
-
-```rust
-use std::fs::File;
-use std::io::ErrorKind;
-
-fn main() {
-    let f = File::open("hello.txt");
-
-    let f = match f {
-        Ok(file) => file,
-        Err(error) => match error.kind() {
-            ErrorKind::NotFound => match File::create("hello.txt") {
-                Ok(fc) => fc,
-                Err(e) => panic!("Problem creating file: {:?}", e),
-            },
-            other_error => panic!("Problem opening file: {:?}", other_error),
-        },
-    };
-}
-```
-
-### Shortcuts
-
-```rust
-// unwrap: panics on error
-let f = File::open("hello.txt").unwrap();
-
-// expect: panics with custom message
-let f = File::open("hello.txt").expect("Failed to open hello.txt");
-
-// unwrap_or: provides default value
-let f = File::open("hello.txt").unwrap_or(default_file);
-
-// unwrap_or_else: computes default on error
-let f = File::open("hello.txt").unwrap_or_else(|error| {
-    panic!("Problem opening file: {:?}", error)
-});
-```
-
-## Propagating Errors
-
-### With match
-
-```rust
-use std::fs::File;
-use std::io::{self, Read};
-
-fn read_username() -> Result<String, io::Error> {
-    let f = File::open("hello.txt");
-
-    let mut f = match f {
-        Ok(file) => file,
-        Err(e) => return Err(e),
-    };
-
-    let mut s = String::new();
-
-    match f.read_to_string(&mut s) {
-        Ok(_) => Ok(s),
-        Err(e) => Err(e),
-    }
-}
-```
-
-### With ? Operator
-
-```rust
-use std::fs::File;
-use std::io::{self, Read};
-
-fn read_username() -> Result<String, io::Error> {
-    let mut f = File::open("hello.txt")?;
-    let mut s = String::new();
-    f.read_to_string(&mut s)?;
-    Ok(s)
-}
-
-// Chained version
-fn read_username_chained() -> Result<String, io::Error> {
-    let mut s = String::new();
-    File::open("hello.txt")?.read_to_string(&mut s)?;
-    Ok(s)
-}
-```
-
-## Custom Error Types
-
-### Simple Custom Error
-
-```rust
-use std::fmt;
-
-#[derive(Debug)]
-struct MyError {
-    message: String,
-}
-
-impl fmt::Display for MyError {
-    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
-        write!(f, "{}", self.message)
-    }
-}
-
-impl std::error::Error for MyError {}
-```
-
-### Error Enum
-
-```rust
-use std::io;
-use std::num::ParseIntError;
-
-#[derive(Debug)]
-enum AppError {
-    Io(io::Error),
-    Parse(ParseIntError),
-    Custom(String),
-}
-
-impl fmt::Display for AppError {
-    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
-        match self {
-            AppError::Io(e) => write!(f, "IO error: {}", e),
-            AppError::Parse(e) => write!(f, "Parse error: {}", e),
-            AppError::Custom(msg) => write!(f, "{}", msg),
-        }
-    }
-}
-
-impl std::error::Error for AppError {}
-
-impl From<io::Error> for AppError {
-    fn from(error: io::Error) -> Self {
-        AppError::Io(error)
-    }
-}
-
-impl From<ParseIntError> for AppError {
-    fn from(error: ParseIntError) -> Self {
-        AppError::Parse(error)
-    }
-}
-```
-
-## Option Type
-
-```rust
-enum Option<T> {
-    Some(T),
-    None,
-}
-```
-
-### Usage
-
-```rust
-fn divide(a: f64, b: f64) -> Option<f64> {
-    if b == 0.0 {
-        None
-    } else {
-        Some(a / b)
-    }
-}
-
-// Pattern matching
-match divide(10.0, 2.0) {
-    Some(result) => println!("Result: {}", result),
-    None => println!("Cannot divide by zero"),
-}
-
-// Combinators
-let result = divide(10.0, 2.0)
-    .map(|x| x * 2.0)
-    .unwrap_or(0.0);
-```
-
-## Panic
-
-### When to Panic
-
-```rust
-// Unrecoverable errors
-panic!("crash and burn");
-
-// Assertion failures
-assert!(x > 0, "x must be positive");
-assert_eq!(a, b, "values must be equal");
-
-// Unreachable code
-unreachable!("this should never happen");
-```
-
-### Panic vs Result
-
-- Use `Result` for recoverable errors
-- Use `panic!` for unrecoverable errors
-- Library code should return `Result`
-- `main` can panic or return `Result`
-
-## Best Practices
-
-```rust
-// 1. Use ? for propagation
-fn process() -> Result<Data, Error> {
-    let input = read_input()?;
-    let parsed = parse(input)?;
-    Ok(transform(parsed))
-}
-
-// 2. Add context with map_err
-let file = File::open(&path)
-    .map_err(|e| format!("Failed to open {}: {}", path, e))?;
-
-// 3. Use anyhow for applications
-use anyhow::{Context, Result};
-
-fn main() -> Result<()> {
-    let config = read_config()
-        .context("Failed to read configuration")?;
-    Ok(())
-}
-
-// 4. Use thiserror for libraries
-use thiserror::Error;
-
-#[derive(Error, Debug)]
-pub enum DataError {
-    #[error("Invalid input: {0}")]
-    InvalidInput(String),
-    #[error("IO error")]
-    Io(#[from] std::io::Error),
-}
-```