oh-my-customcode 0.1.3 → 0.2.0

package/templates/skills/development/python-best-practices/SKILL.md

@@ -1,221 +0,0 @@
-# Python Best Practices Skill
-
-> **Category**: Development
-> **Source**: Internal (based on PEP 8 and PEP 20)
-
-## Purpose
-
-Apply idiomatic Python patterns and best practices from official Python documentation.
-
-## The Zen of Python (PEP 20)
-
-```
-Beautiful is better than ugly.
-Explicit is better than implicit.
-Simple is better than complex.
-Complex is better than complicated.
-Flat is better than nested.
-Sparse is better than dense.
-Readability counts.
-Special cases aren't special enough to break the rules.
-Although practicality beats purity.
-Errors should never pass silently.
-Unless explicitly silenced.
-In the face of ambiguity, refuse the temptation to guess.
-There should be one-- and preferably only one --obvious way to do it.
-Although that way may not be obvious at first unless you're Dutch.
-Now is better than never.
-Although never is often better than *right* now.
-If the implementation is hard to explain, it's a bad idea.
-If the implementation is easy to explain, it may be a good idea.
-Namespaces are one honking great idea -- let's do more of those!
-```
-
-## Rules
-
-### 1. Code Layout
-
-```yaml
-indentation:
-  - Use 4 spaces per indentation level
-  - Never mix tabs and spaces
-  - Continuation lines align vertically or use hanging indent
-
-line_length:
-  - Maximum 79 characters for code
-  - Maximum 72 characters for docstrings/comments
-  - Teams may agree on 99 characters for code
-
-blank_lines:
-  - Two blank lines around top-level definitions
-  - One blank line between method definitions
-  - Use sparingly inside functions
-```
-
-### 2. Imports
-
-```yaml
-rules:
-  - One import per line
-  - Position at file top, after docstrings
-  - Group order: standard library → third-party → local
-  - Separate groups with blank lines
-  - Prefer absolute imports
-  - Avoid wildcard imports (from X import *)
-
-example: |
-  import os
-  import sys
-
-  from third_party import lib
-
-  from myproject import module
-```
-
-### 3. Whitespace
-
-```yaml
-avoid:
-  - Extra spaces inside parentheses/brackets
-  - Spaces before commas or colons
-  - Spaces between function name and parenthesis
-  - Multiple spaces for alignment
-
-required:
-  - Single space around binary operators
-  - Spaces around -> in annotations
-  - No spaces around = for default parameters
-```
-
-### 4. Naming Conventions
-
-```yaml
-modules_packages:
-  style: lowercase_with_underscores
-  example: my_module
-
-classes:
-  style: CapWords
-  example: MyClass
-
-functions_variables:
-  style: lowercase_with_underscores
-  example: my_function, my_variable
-
-constants:
-  style: ALL_CAPS_WITH_UNDERSCORES
-  example: MAX_SIZE, DEFAULT_VALUE
-
-exceptions:
-  style: CapWords + Error suffix
-  example: ValueError, CustomError
-
-private:
-  single_underscore: _internal (weak internal)
-  double_underscore: __private (name mangling)
-  trailing_underscore: class_ (avoid keyword conflict)
-
-avoid:
-  - Single characters l, O, I (ambiguous)
-```
-
-### 5. Comments and Docstrings
-
-```yaml
-principles:
-  - Comments contradicting code are worse than none
-  - Use complete sentences
-  - Keep comments up to date
-
-block_comments:
-  - Indent at same level as code
-  - Start each line with # and space
-
-inline_comments:
-  - Minimum two spaces from code
-  - Avoid obvious statements
-
-docstrings:
-  - Write for all public modules, functions, classes, methods
-  - Use triple quotes
-  - First line: concise summary
-  - Blank line before detailed description
-```
-
-### 6. Programming Recommendations
-
-```yaml
-comparisons:
-  - Use 'is' and 'is not' for None, True, False
-  - Prefer isinstance() over type()
-  - Use 'is not' rather than 'not ... is'
-
-sequences:
-  - Test empty: if not seq: (not if len(seq) == 0)
-  - Use .startswith() and .endswith()
-
-exceptions:
-  - Derive from Exception, not BaseException
-  - Catch specific exceptions
-  - Avoid bare except clauses
-  - Use 'raise X from Y' for chaining
-
-functions:
-  - Use def, not lambda assignment
-  - Consistent return statements
-  - Use with for resource management
-
-type_hints:
-  - Follow PEP 484 syntax
-  - Space after colon in annotations
-  - No space before colon
-```
-
-### 7. Pythonic Idioms
-
-```yaml
-list_comprehension:
-  prefer: "[x*2 for x in items if x > 0]"
-  over: |
-    result = []
-    for x in items:
-        if x > 0:
-            result.append(x*2)
-
-context_managers:
-  prefer: "with open('file') as f:"
-  over: |
-    f = open('file')
-    try:
-        ...
-    finally:
-        f.close()
-
-unpacking:
-  prefer: "a, b = b, a"
-  over: |
-    temp = a
-    a = b
-    b = temp
-
-enumerate:
-  prefer: "for i, item in enumerate(items):"
-  over: "for i in range(len(items)):"
-
-dictionary:
-  prefer: "d.get(key, default)"
-  over: "d[key] if key in d else default"
-```
-
-## Application
-
-When writing or reviewing Python code:
-
-1. **Always** follow PEP 8 formatting
-2. **Always** write docstrings for public APIs
-3. **Prefer** explicit over implicit
-4. **Prefer** simple over complex
-5. **Prefer** flat over nested
-6. **Avoid** premature optimization
-7. **Use** list comprehensions when readable
-8. **Use** context managers for resources

package/templates/skills/development/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/skills/development/react-best-practices/index.yaml

@@ -1,39 +0,0 @@
-# React Best Practices Skill
-
-metadata:
-  name: react-best-practices
-  category: development
-  description: React/Next.js performance optimization with 40+ rules in 8 categories
-
-source:
-  type: external
-  origin: github
-  url: https://github.com/vercel-labs/agent-skills
-  path: skills/react-best-practices
-  version: "1.0.0"
-  last_updated: "2025-01-22"
-
-triggers:
-  - "optimize React"
-  - "performance review"
-  - "bundle size"
-  - "data fetching"
-  - "Next.js optimization"
-
-categories:
-  - name: waterfall-elimination
-    priority: critical
-  - name: bundle-optimization
-    priority: critical
-  - name: server-performance
-    priority: high
-  - name: client-fetching
-    priority: medium-high
-  - name: rendering
-    priority: medium
-  - name: caching
-    priority: medium
-  - name: code-splitting
-    priority: medium
-  - name: image-optimization
-    priority: low-medium

package/templates/skills/development/rust-best-practices/SKILL.md

@@ -1,266 +0,0 @@
-# Rust Best Practices Skill
-
-> **Category**: Development
-> **Source**: Internal (based on Rust API Guidelines and The Book)
-
-## Purpose
-
-Apply idiomatic Rust patterns and best practices from official documentation.
-
-## Core Principles
-
-```
-Safety without garbage collection
-Zero-cost abstractions
-Fearless concurrency
-Ownership as a feature
-```
-
-## Rules
-
-### 1. Naming Conventions
-
-```yaml
-crates:
-  style: snake_case or kebab-case
-  example: my_crate, my-crate
-
-modules:
-  style: snake_case
-  example: my_module
-
-types:
-  style: UpperCamelCase
-  example: MyStruct, MyEnum
-
-traits:
-  style: UpperCamelCase
-  example: Iterator, Display
-
-functions_methods:
-  style: snake_case
-  example: my_function, get_value
-
-constants:
-  style: SCREAMING_SNAKE_CASE
-  example: MAX_SIZE
-
-type_parameters:
-  style: single uppercase or CamelCase
-  example: T, E, Item
-
-lifetimes:
-  style: short lowercase
-  example: 'a, 'b, 'static
-
-macros:
-  style: snake_case!
-  example: vec!, println!
-```
-
-### 2. Ownership and Borrowing
-
-```yaml
-principles:
-  - Each value has exactly one owner
-  - References cannot outlive the data they reference
-  - Either one mutable reference OR many immutable references
-
-prefer:
-  - "&T over T" when not needing ownership
-  - "&mut T over T" when modifying without consuming
-  - "T over Box<T>" when size is known at compile time
-
-avoid:
-  - Clone when borrowing suffices
-  - RefCell unless interior mutability is needed
-  - Unsafe unless absolutely necessary
-```
-
-### 3. Error Handling
-
-```yaml
-result_type:
-  - Return Result<T, E> for recoverable errors
-  - Use ? operator for propagation
-  - Define custom error types for libraries
-
-option_type:
-  - Use Option<T> for nullable values
-  - Prefer map/and_then over match when appropriate
-  - Use unwrap_or, unwrap_or_else, unwrap_or_default
-
-panic:
-  - Only for unrecoverable errors
-  - Use in tests with assert!, assert_eq!
-  - Avoid in library code
-
-patterns: |
-  // Propagation with ?
-  fn read_file() -> Result<String, io::Error> {
-      let mut file = File::open("file.txt")?;
-      let mut contents = String::new();
-      file.read_to_string(&mut contents)?;
-      Ok(contents)
-  }
-
-  // Custom error type
-  #[derive(Debug)]
-  enum MyError {
-      Io(io::Error),
-      Parse(ParseIntError),
-  }
-```
-
-### 4. Traits and Generics
-
-```yaml
-trait_design:
-  - Keep traits focused and small
-  - Use associated types for output types
-  - Implement standard traits: Debug, Clone, Default, PartialEq
-
-standard_traits:
-  - Debug: for debugging output
-  - Clone: explicit duplication
-  - Default: default value construction
-  - PartialEq, Eq: equality comparison
-  - PartialOrd, Ord: ordering
-  - Hash: for HashMap keys
-  - Display: user-facing output
-  - From/Into: type conversion
-
-generics:
-  - Use trait bounds to specify requirements
-  - Prefer impl Trait in argument position
-  - Use where clauses for complex bounds
-```
-
-### 5. Memory Management
-
-```yaml
-stack_vs_heap:
-  - Stack: fixed-size, Copy types
-  - Heap: dynamic-size, Box, Vec, String
-
-smart_pointers:
-  - Box<T>: heap allocation with single owner
-  - Rc<T>: reference counting (single-threaded)
-  - Arc<T>: atomic reference counting (multi-threaded)
-  - RefCell<T>: interior mutability
-
-avoid_leaks:
-  - Drop trait for cleanup
-  - RAII pattern for resources
-  - Weak references to break cycles
-```
-
-### 6. Concurrency
-
-```yaml
-send_sync:
-  - Send: safe to transfer between threads
-  - Sync: safe to share references between threads
-
-primitives:
-  - Mutex<T>: mutual exclusion
-  - RwLock<T>: multiple readers or one writer
-  - Arc<T>: thread-safe reference counting
-  - mpsc: channels for message passing
-
-patterns: |
-  // Shared state with Arc and Mutex
-  let counter = Arc::new(Mutex::new(0));
-  let counter_clone = Arc::clone(&counter);
-
-  thread::spawn(move || {
-      let mut num = counter_clone.lock().unwrap();
-      *num += 1;
-  });
-
-  // Message passing
-  let (tx, rx) = mpsc::channel();
-  thread::spawn(move || {
-      tx.send(value).unwrap();
-  });
-  let received = rx.recv().unwrap();
-```
-
-### 7. API Design
-
-```yaml
-guidelines:
-  - Accept borrowed data when possible
-  - Return owned data when the caller needs it
-  - Use Into/AsRef for flexible parameters
-  - Implement standard conversion traits
-
-constructors:
-  - new() for primary constructor
-  - with_* for alternative constructors
-  - Builder pattern for many parameters
-
-methods:
-  - is_* for boolean queries
-  - as_* for cheap conversions (borrows)
-  - to_* for expensive conversions (copies)
-  - into_* for ownership transfers
-```
-
-### 8. Documentation
-
-```yaml
-rules:
-  - Document all public items
-  - Include examples in doc comments
-  - Use # Examples section
-  - Document panics, errors, safety
-
-format: |
-  /// Brief description.
-  ///
-  /// More detailed explanation if needed.
-  ///
-  /// # Examples
-  ///
-  /// ```
-  /// let result = my_function(42);
-  /// assert_eq!(result, 84);
-  /// ```
-  ///
-  /// # Panics
-  ///
-  /// Panics if the input is zero.
-  pub fn my_function(x: i32) -> i32 {
-      x * 2
-  }
-```
-
-### 9. Project Structure
-
-```yaml
-layout:
-  - src/lib.rs or src/main.rs: crate root
-  - src/bin/: additional binaries
-  - tests/: integration tests
-  - benches/: benchmarks
-  - examples/: example programs
-
-modules:
-  - One module per file
-  - mod.rs or filename.rs for module
-  - pub use for re-exports
-```
-
-## Application
-
-When writing or reviewing Rust code:
-
-1. **Always** handle ownership correctly
-2. **Always** handle errors with Result/Option
-3. **Prefer** borrowing over cloning
-4. **Prefer** zero-cost abstractions
-5. **Implement** standard traits (Debug, Clone, etc.)
-6. **Document** public APIs with examples
-7. **Avoid** unsafe unless necessary
-8. **Use** clippy for linting

package/templates/skills/development/rust-best-practices/index.yaml

@@ -1,26 +0,0 @@
-# Rust Best Practices Skill
-
-metadata:
-  name: rust-best-practices
-  category: development
-  description: Idiomatic Rust patterns from official guidelines
-
-source:
-  type: internal
-  reference:
-    - https://doc.rust-lang.org/book/
-    - https://rust-lang.github.io/api-guidelines/
-    - https://doc.rust-lang.org/nightly/style-guide/
-
-provides:
-  - Rust naming conventions
-  - Ownership and borrowing patterns
-  - Error handling patterns
-  - Trait and generic design
-  - Memory management guidelines
-  - Concurrency patterns
-  - API design guidelines
-  - Documentation standards
-
-used_by:
-  - rust-expert

package/templates/skills/development/typescript-best-practices/index.yaml

@@ -1,28 +0,0 @@
-# TypeScript Best Practices Skill
-
-metadata:
-  name: typescript-best-practices
-  category: development
-  description: Type-safe TypeScript patterns from industry standards
-
-source:
-  type: internal
-  reference:
-    - https://www.typescriptlang.org/docs/handbook/
-    - https://google.github.io/styleguide/tsguide.html
-    - https://basarat.gitbook.io/typescript/
-
-provides:
-  - TypeScript type system patterns
-  - Interface and type design
-  - Generic usage guidelines
-  - Variable and constant rules
-  - Function design patterns
-  - Class structure guidelines
-  - Naming conventions
-  - Control flow patterns
-  - Error handling patterns
-  - Import/export organization
-
-used_by:
-  - typescript-expert

package/templates/skills/development/vercel-deploy/SKILL.md

@@ -1,73 +0,0 @@
-# Vercel Deploy
-
-> **Source**: vercel-labs/agent-skills
-> **Capability**: Instant deployment to Vercel
-
-## When to Use
-
-- Deploy application to Vercel
-- Create preview deployments
-- Generate shareable URLs
-
-## Features
-
-### Framework Detection
-```
-Auto-detects 40+ frameworks from package.json:
-- Next.js
-- React
-- Vue
-- Nuxt
-- Svelte
-- Astro
-- and more...
-```
-
-### Auto Exclusions
-```
-Automatically excludes:
-- node_modules/
-- .git/
-- .env files
-```
-
-### Output
-```
-On successful deployment:
-1. Preview URL (view deployment)
-2. Claim URL (transfer ownership)
-```
-
-## Execution Flow
-
-```
-1. Detect project framework
-2. Prepare deployment bundle
-3. Upload to Vercel
-4. Return URLs
-```
-
-## Output Format
-
-```
-[Deploy Success]
-Preview: https://project-xxx.vercel.app
-Claim: https://vercel.com/claim/xxx
-```
-
-## Scripts
-
-See `scripts/deploy.sh` for deployment automation.
-
-## Requirements
-
-- Valid project structure
-- package.json present
-- Vercel CLI or API token (for authenticated deploys)
-
-## Limitations
-
-- Claimable deploys are anonymous
-- Preview URLs are temporary
-- Full features require Vercel account
-```

package/templates/skills/development/vercel-deploy/index.yaml

@@ -1,30 +0,0 @@
-# Vercel Deploy Skill
-
-metadata:
-  name: vercel-deploy
-  category: development
-  description: Deploy applications to Vercel with auto-detection and preview URLs
-
-source:
-  type: external
-  origin: github
-  url: https://github.com/vercel-labs/agent-skills
-  path: skills/vercel-deploy-claimable
-  version: "1.0.0"
-  last_updated: "2025-01-22"
-
-triggers:
-  - "deploy to Vercel"
-  - "create preview"
-  - "publish site"
-  - "Vercel deployment"
-
-capabilities:
-  - Auto-detect 40+ frameworks
-  - Generate preview URLs
-  - Ownership transfer links
-  - Exclude node_modules, .git automatically
-
-requirements:
-  - Vercel CLI or API access
-  - Project with package.json