โ† Back to list
elasticdotventures

dry-philosophy

by elasticdotventures

๐Ÿฅพ _b00t_: brians dotfiles aka state of the art agentic tooling & context initialization

โญ 9๐Ÿด 0๐Ÿ“… Dec 13, 2025
agentagentic-aiaigentawsazureb00tgcpmcp-client

SKILL.md


name: dry-philosophy description: | Don't Repeat Yourself (DRY) and Never Reinvent the Wheel (NRtW) - core b00t principles. Use existing libraries, leverage Rust via PyO3 instead of duplicating logic in Python, and contribute to upstream projects rather than fork privately. version: 1.0.0 allowed-tools: Read, Grep, Glob, Bash, WebSearch

What This Skill Does

The DRY philosophy is a central tenet of b00t: YEI exist to contribute ONLY new and novel meaningful work. This skill helps you:

  • Identify when code is being duplicated or reinvented
  • Find existing libraries instead of writing new code
  • Use Rust functionality via PyO3 rather than duplicate in Python
  • Contribute upstream rather than maintain private forks
  • Write lean, maintainable code with minimal dependencies

When It Activates

Activate this skill when you see:

  • "implement [common functionality]"
  • "create a [parser/validator/client]"
  • "write code to [read/parse/validate] [format]"
  • Any task that sounds like it might already exist in a library
  • Code that duplicates existing Rust functionality
  • Multiple implementations of the same logic

Core Principles

1. DRY: Don't Repeat Yourself

AVOID writing code for functionality that exists in libraries:

โŒ Anti-pattern:

# Writing custom JSON parser
def parse_json(text):
    # 200 lines of parsing logic...

โœ… DRY approach:

import json
data = json.loads(text)

2. NRtW: Never Reinvent the Wheel

SEARCH for existing solutions before coding:

# Search for Python packages
pip search [functionality]
# or
uv pip search [functionality]

# Check PyPI
https://pypi.org/search/?q=[functionality]

# Check Rust crates
https://crates.io/search?q=[functionality]

3. Leverage Rust via PyO3

USE Rust for heavy lifting, expose to Python:

โŒ Anti-pattern:

# Duplicating Rust datum parsing in Python
def parse_datum_file(path: str) -> dict:
    with open(path) as f:
        toml_data = toml.load(f)
    # Validation logic...
    # Parsing logic...
    return processed_data

โœ… DRY approach:

# Use Rust via PyO3
import b00t_py
datum = b00t_py.load_ai_model_datum("model-name", "~/.dotfiles/_b00t_")

Why? Rust implementation already exists, is faster, type-safe, and tested.

4. Contribute Upstream

FORK and PATCH forward, don't maintain private copies:

โŒ Anti-pattern:

# Copy library code into project
cp -r /path/to/library my_project/vendored/
# Make private modifications

โœ… DRY approach:

# Fork the library
gh repo fork upstream/library

# Create patch
git checkout -b fix/issue-123
# Make changes
git commit -m "fix: resolve issue #123"

# Submit PR
gh pr create --upstream

# Use your fork temporarily
# pyproject.toml
dependencies = [
    "library @ git+https://github.com/you/library@fix/issue-123"
]

Decision Tree

Need to implement functionality?
    โ†“
Does it already exist in a library?
    โ”œโ”€ YES โ†’ Use the library (DRY)
    โ””โ”€ NO โ†“
           Is it standard functionality?
               โ”œโ”€ YES โ†’ Search harder, it probably exists
               โ””โ”€ NO โ†“
                      Does similar Rust code exist in b00t?
                          โ”œโ”€ YES โ†’ Expose via PyO3 (DRY)
                          โ””โ”€ NO โ†“
                                 Is this truly novel?
                                     โ”œโ”€ YES โ†’ Implement (with tests!)
                                     โ””โ”€ NO โ†’ Reconsider: use library

Examples

Finding Libraries

Task: Parse TOML files

# Search
pip search toml

# Results: tomli, tomlkit, pytoml
# Use established: tomli (or tomllib in Python 3.11+)

Task: Make HTTP requests

# DON'T: Write custom HTTP client
# DO: Use httpx or requests
pip install httpx

Task: Validate Pydantic models

# DON'T: Write custom validation
# DO: Use Pydantic's built-in validation
from pydantic import BaseModel, field_validator

Using Rust via PyO3

b00t Pattern: Rust does heavy lifting, Python uses it.

Datum Operations

โŒ Duplicate (Anti-pattern):

# b00t_j0b_py/datum_parser.py
import toml

class DatumParser:
    def load_provider(self, name: str):
        path = f"~/.dotfiles/_b00t_/{name}.ai.toml"
        with open(os.path.expanduser(path)) as f:
            data = toml.load(f)
        # Validation...
        # Parsing...
        return data

โœ… DRY (Use Rust):

# Use PyO3 bindings
import b00t_py

datum = b00t_py.load_ai_model_datum("model-name", "~/.dotfiles/_b00t_")

Why better?

  • โœ… No duplication - single source of truth in Rust
  • โœ… Type-safe - Rust ensures correctness
  • โœ… Tested - Rust tests cover this
  • โœ… Faster - Rust performance
  • โœ… Maintainable - one codebase, not two

Environment Validation

โŒ Duplicate:

def validate_provider_env(provider: str) -> bool:
    # Read datum
    # Parse required env vars
    # Check os.environ
    # Return result

โœ… DRY:

import b00t_py

validation = b00t_py.check_provider_env("openrouter", "~/.dotfiles/_b00t_")
if not validation["available"]:
    print(f"Missing: {validation['missing_env_vars']}")

Contributing Upstream

Scenario: Bug in pydantic-ai library

โŒ Anti-pattern:

# Copy code into project
cp -r site-packages/pydantic_ai b00t_j0b_py/vendored/
# Fix bug privately
# Now you maintain a fork forever

โœ… DRY approach:

# Fork
gh repo fork pydantic/pydantic-ai

# Fix and test
git checkout -b fix/agent-validation-bug
# Make changes
pytest tests/
git commit -m "fix: agent validation for None values"

# Submit PR
gh pr create --title "fix: agent validation for None values"

# Temporarily use your fork
# pyproject.toml
dependencies = [
    "pydantic-ai @ git+https://github.com/elasticdotventures/pydantic-ai@fix/agent-validation-bug"
]

# After PR merged, switch back to upstream
dependencies = [
    "pydantic-ai>=0.0.15"  # includes fix
]

Library Selection Criteria

When choosing a library:

โœ… Good Signs

  • โœ… Many stars (>1000 on GitHub)
  • โœ… Active maintenance (commits in last month)
  • โœ… Minimal open issues/PRs
  • โœ… Good documentation
  • โœ… Permissive license (MIT, Apache, BSD)
  • โœ… Used by major projects
  • โœ… Type hints (Python) or strong types (Rust)
  • โœ… Comprehensive tests
  • โœ… Lively, polite community discussions

๐Ÿšฉ Red Flags

  • ๐Ÿšฉ Abandoned (no commits in 1+ years)
  • ๐Ÿšฉ Many unresolved issues
  • ๐Ÿšฉ No tests
  • ๐Ÿšฉ Copyleft license (GPL) for permissive projects
  • ๐Ÿšฉ No type hints
  • ๐Ÿšฉ Breaking changes without semver
  • ๐Ÿšฉ Hostile maintainers

PyO3 Pattern

When to Use Rust (via PyO3)

Use Rust for:

  • โœ… Performance-critical code
  • โœ… Type-safe validation
  • โœ… Complex parsing
  • โœ… Shared logic between Rust and Python
  • โœ… System-level operations

How to Expose Rust to Python

// b00t-py/src/lib.rs
use pyo3::prelude::*;

#[pyfunction]
fn my_function(py: Python<'_>, arg: &str) -> PyResult<String> {
    // Rust implementation
    Ok(format!("Processed: {}", arg))
}

#[pymodule]
fn b00t_py(_py: Python, m: &PyModule) -> PyResult<()> {
    m.add_function(wrap_pyfunction!(my_function, m)?)?;
    Ok(())
}
# Python usage
import b00t_py

result = b00t_py.my_function("test")

Code Review Checklist

Before writing code, ask:

  1. โ˜ Does this functionality exist in a library?
  2. โ˜ Does similar Rust code exist in b00t?
  3. โ˜ Can I use PyO3 to expose Rust instead?
  4. โ˜ Is this truly novel functionality?
  5. โ˜ Have I searched PyPI/crates.io?
  6. โ˜ Have I checked existing b00t modules?

If all answers are "no", then implement.

Anti-Patterns to Avoid

1. Reinventing Standard Library

โŒ Bad:

def read_json_file(path):
    with open(path) as f:
        return custom_json_parse(f.read())

โœ… Good:

import json

def read_json_file(path):
    with open(path) as f:
        return json.load(f)

2. Duplicating Rust Logic

โŒ Bad:

# Reimplementing datum validation in Python
class DatumValidator:
    def validate_env(self, provider): ...
    def parse_toml(self, path): ...

โœ… Good:

# Use Rust via PyO3
import b00t_py
validation = b00t_py.check_provider_env(provider, path)

3. Private Forks

โŒ Bad:

# Fork library, never contribute back
# Maintain private version forever

โœ… Good:

# Fork, fix, PR upstream
# Use fork temporarily until merged
# Switch back to upstream after merge

4. Not Using Type Hints

โŒ Bad:

def process_data(data):
    # No types, unclear what's expected
    return data.transform()

โœ… Good:

from pydantic import BaseModel

def process_data(data: dict[str, Any]) -> ProcessedData:
    return ProcessedData(**data)

Benefits of DRY

  1. Less code to maintain - fewer bugs, faster development
  2. Better quality - libraries are tested by many users
  3. Security updates - library maintainers handle CVEs
  4. Performance - Rust is faster than Python for heavy tasks
  5. Type safety - Rust ensures correctness
  6. Community - contribute to ecosystem, get help
  • datum-system: Uses Rust via PyO3 (DRY example)
  • direnv-pattern: Uses existing direnv tool (DRY)
  • justfile-usage: Uses casey/just tool (DRY)

References

  • CLAUDE.md - YEI MUST ALWAYS/NEVER section
  • b00t-py/src/lib.rs - PyO3 bindings example
  • b00t-j0b-py/pyproject.toml - Dependency management

Summary

DRY Philosophy:

  • ๐Ÿ” Search for existing solutions first
  • ๐Ÿ“ฆ Use established libraries over custom code
  • ๐Ÿฆ€ Leverage Rust via PyO3 instead of duplicating in Python
  • ๐Ÿ”„ Fork, fix, PR upstream - don't maintain private copies
  • โœ… Write only novel, meaningful code
  • ๐Ÿงช Test everything you write

Alignment: A lean hive is a happy hive. Finding and patching bugs in libraries is divine; committing buggy code is unforgivable.

Score

Total Score

65/100

Based on repository quality metrics

โœ“SKILL.md

SKILL.mdใƒ•ใ‚กใ‚คใƒซใŒๅซใพใ‚Œใฆใ„ใ‚‹

+20
โœ“LICENSE

ใƒฉใ‚คใ‚ปใƒณใ‚นใŒ่จญๅฎšใ•ใ‚Œใฆใ„ใ‚‹

+10
โ—‹่ชฌๆ˜Žๆ–‡

100ๆ–‡ๅญ—ไปฅไธŠใฎ่ชฌๆ˜ŽใŒใ‚ใ‚‹

0/10
โ—‹ไบบๆฐ—

GitHub Stars 100ไปฅไธŠ

0/15
โœ“ๆœ€่ฟ‘ใฎๆดปๅ‹•

3ใƒถๆœˆไปฅๅ†…ใซๆ›ดๆ–ฐ

+5
โ—‹ใƒ•ใ‚ฉใƒผใ‚ฏ

10ๅ›žไปฅไธŠใƒ•ใ‚ฉใƒผใ‚ฏใ•ใ‚Œใฆใ„ใ‚‹

0/5
โœ“Issue็ฎก็†

ใ‚ชใƒผใƒ—ใƒณIssueใŒ50ๆœชๆบ€

+5
โœ“่จ€่ชž

ใƒ—ใƒญใ‚ฐใƒฉใƒŸใƒณใ‚ฐ่จ€่ชžใŒ่จญๅฎšใ•ใ‚Œใฆใ„ใ‚‹

+5
โœ“ใ‚ฟใ‚ฐ

1ใคไปฅไธŠใฎใ‚ฟใ‚ฐใŒ่จญๅฎšใ•ใ‚Œใฆใ„ใ‚‹

+5

Reviews

๐Ÿ’ฌ

Reviews coming soon