oh-my-customcode 0.1.4 → 0.2.0

package/templates/agents/manager/supplier/refs/skills/development/kotlin-best-practices/SKILL.md

@@ -1,255 +0,0 @@
-# Kotlin Best Practices Skill
-
-> **Category**: Development
-> **Source**: Internal (based on Kotlin Coding Conventions)
-
-## Purpose
-
-Apply idiomatic Kotlin patterns and best practices from official JetBrains documentation.
-
-## Core Principles
-
-```
-Concise yet readable
-Null safety by design
-Interoperability with Java
-Functional when appropriate
-```
-
-## Rules
-
-### 1. Naming Conventions
-
-```yaml
-packages:
-  style: lowercase, no underscores
-  example: org.example.project
-
-classes_objects:
-  style: UpperCamelCase
-  example: DeclarationProcessor
-
-functions_variables:
-  style: lowerCamelCase
-  example: processDeclarations, declarationCount
-
-constants:
-  style: SCREAMING_SNAKE_CASE
-  example: const val MAX_COUNT = 8
-
-backing_properties:
-  style: underscore prefix
-  example: private val _elementList
-
-acronyms:
-  two_letters: both uppercase (IOStream)
-  three_plus: capitalize first only (XmlFormatter)
-```
-
-### 2. Source File Organization
-
-```yaml
-file_naming:
-  single_class: name after the class (MyClass.kt)
-  multiple_classes: descriptive UpperCamelCase (ProcessDeclarations.kt)
-  platform_specific: add suffix (Platform.jvm.kt)
-
-class_layout:
-  1: Property declarations and initializer blocks
-  2: Secondary constructors
-  3: Method declarations
-  4: Companion object
-
-directory_structure:
-  - Follow package structure with common root omitted
-  - Example: org.example.kotlin.network → network/
-```
-
-### 3. Formatting
-
-```yaml
-indentation:
-  - 4 spaces (no tabs)
-  - Opening brace at end of line
-  - Closing brace on separate line
-
-horizontal_whitespace:
-  around_binary_operators: "a + b"
-  no_around_range: "0..i"
-  no_around_unary: "a++"
-  after_control_keywords: "if (condition)"
-  no_before_parentheses: "method()"
-  never_around_dot: "foo.bar()"
-
-colons:
-  type_supertype: "class Foo : Bar"
-  declaration_type: "val x: Int"
-  always_space_after: true
-
-trailing_commas:
-  recommended: true
-  reason: cleaner diffs, easier reordering
-```
-
-### 4. Functions
-
-```yaml
-expression_bodies:
-  prefer: "fun foo() = 1"
-  over: |
-    fun foo(): Int {
-        return 1
-    }
-
-default_parameters:
-  prefer: "fun foo(a: String = \"a\")"
-  over: overloaded functions
-
-single_line_signatures:
-  if_fits: "fun foo(a: Int): String = ..."
-  otherwise: |
-    fun longMethodName(
-        argument: ArgumentType = defaultValue,
-        argument2: AnotherArgumentType,
-    ): ReturnType { }
-
-unit_return:
-  avoid: "fun foo(): Unit { }"
-  prefer: "fun foo() { }"
-```
-
-### 5. Null Safety
-
-```yaml
-principles:
-  - Prefer non-null types by default
-  - Use ? only when nullability is meaningful
-  - Leverage safe calls (?.) and elvis (?:)
-
-patterns: |
-  // Safe call
-  val length = text?.length
-
-  // Elvis operator
-  val name = user?.name ?: "Anonymous"
-
-  // Let for null checks
-  user?.let {
-      println(it.name)
-  }
-
-  // Not-null assertion (use sparingly)
-  val name = user!!.name
-```
-
-### 6. Idiomatic Patterns
-
-```yaml
-immutability:
-  prefer: "val over var"
-  collections: "listOf() over arrayListOf()"
-
-conditionals:
-  binary: use if
-  multiple: use when
-
-  patterns: |
-    // if expression
-    return if (x) foo() else bar()
-
-    // when expression
-    return when(x) {
-        0 -> "zero"
-        else -> "nonzero"
-    }
-
-functional:
-  prefer: "list.filter { it > 10 }.map { it * 2 }"
-  over: manual loops (except forEach)
-
-ranges:
-  prefer: "for (i in 0..<n)"
-  avoid: "for (i in 0..n - 1)"
-
-type_aliases:
-  use_for: |
-    typealias MouseClickHandler = (Any, MouseEvent) -> Unit
-    typealias PersonIndex = Map<String, Person>
-```
-
-### 7. Lambdas
-
-```yaml
-formatting:
-  - Spaces around curly braces: "list.filter { it > 10 }"
-  - Single lambda outside parentheses
-  - it for single parameter
-
-patterns: |
-  // Outside parentheses
-  list.filter { it > 10 }
-
-  // Multiple parameters
-  list.fold(0) { acc, item -> acc + item }
-
-  // Destructuring
-  map.forEach { (key, value) -> println("$key = $value") }
-```
-
-### 8. Coroutines
-
-```yaml
-principles:
-  - Use suspend functions for async operations
-  - Structured concurrency with scopes
-  - Proper exception handling
-
-patterns: |
-  // Suspend function
-  suspend fun fetchData(): Data {
-      return withContext(Dispatchers.IO) {
-          api.getData()
-      }
-  }
-
-  // Coroutine scope
-  lifecycleScope.launch {
-      val data = fetchData()
-      updateUI(data)
-  }
-
-  // Exception handling
-  try {
-      val result = async { fetchData() }.await()
-  } catch (e: Exception) {
-      handleError(e)
-  }
-```
-
-### 9. Documentation
-
-```yaml
-format: |
-  /**
-   * Returns the absolute value of the given [number].
-   */
-  fun abs(number: Int): Int { ... }
-
-best_practices:
-  - Incorporate parameters into description
-  - Use brackets for parameter references
-  - Use @param/@return only for lengthy descriptions
-```
-
-## Application
-
-When writing or reviewing Kotlin code:
-
-1. **Always** prefer val over var
-2. **Always** use null-safe types appropriately
-3. **Prefer** expression bodies for simple functions
-4. **Prefer** functional operations over loops
-5. **Use** default parameters over overloads
-6. **Use** when for multiple conditions
-7. **Leverage** extension functions
-8. **Document** public APIs

package/templates/agents/manager/supplier/refs/skills/development/kotlin-best-practices/index.yaml

@@ -1,27 +0,0 @@
-# Kotlin Best Practices Skill
-
-metadata:
-  name: kotlin-best-practices
-  category: development
-  description: Idiomatic Kotlin patterns from JetBrains conventions
-
-source:
-  type: internal
-  reference:
-    - https://kotlinlang.org/docs/coding-conventions.html
-    - https://kotlinlang.org/docs/idioms.html
-    - https://developer.android.com/kotlin/style-guide
-
-provides:
-  - Kotlin naming conventions
-  - Source file organization
-  - Formatting standards
-  - Function design patterns
-  - Null safety patterns
-  - Idiomatic expressions
-  - Lambda best practices
-  - Coroutine patterns
-  - Documentation guidelines
-
-used_by:
-  - kotlin-expert

package/templates/agents/manager/supplier/refs/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/agents/manager/supplier/refs/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/agents/manager/supplier/refs/skills/development/react-best-practices/SKILL.md

@@ -1,100 +0,0 @@
-# React Best Practices
-
-> **Source**: vercel-labs/agent-skills
-> **Rules**: 40+ rules in 8 categories
-
-## When to Use
-
-- Writing React/Next.js components
-- Data fetching implementation
-- Performance review
-- Bundle size optimization
-
-## Categories by Priority
-
-### Critical Priority
-
-#### Waterfall Elimination
-```
-- Avoid sequential data fetching
-- Use parallel data fetching
-- Implement proper loading states
-- Prefetch critical data
-```
-
-#### Bundle Optimization
-```
-- Minimize client-side JavaScript
-- Use dynamic imports
-- Tree-shake unused code
-- Analyze bundle with tools
-```
-
-### High Priority
-
-#### Server-Side Performance
-```
-- Use Server Components by default
-- Minimize 'use client' directives
-- Implement streaming where possible
-- Cache server responses
-```
-
-### Medium-High Priority
-
-#### Client-Side Fetching
-```
-- Use SWR or React Query
-- Implement optimistic updates
-- Handle loading/error states
-- Cache API responses
-```
-
-### Medium Priority
-
-#### Rendering
-```
-- Avoid unnecessary re-renders
-- Use React.memo strategically
-- Implement useMemo/useCallback properly
-- Virtualize long lists
-```
-
-#### Caching
-```
-- Implement proper cache headers
-- Use ISR for dynamic content
-- Cache database queries
-- CDN caching strategies
-```
-
-#### Code Splitting
-```
-- Split by route
-- Lazy load below-fold content
-- Dynamic import heavy libraries
-- Preload critical chunks
-```
-
-### Low-Medium Priority
-
-#### Image Optimization
-```
-- Use next/image
-- Implement proper sizing
-- Use modern formats (WebP, AVIF)
-- Lazy load off-screen images
-```
-
-## Execution Flow
-
-```
-1. Identify optimization area
-2. Check relevant category rules
-3. Apply recommendations
-4. Verify improvements
-```
-
-## Scripts
-
-See `scripts/` directory for automation helpers.

package/templates/agents/manager/supplier/refs/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