home / skills / gigaverse-app / skillet / pythonista-patterning

pythonista-patterning skill

/pythonista/skills/pythonista-patterning

This skill helps you discover code patterns before writing new code, enabling reuse, consistency, and cleaner architectures across projects.

npx playbooks add skill gigaverse-app/skillet --skill pythonista-patterning

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.5 KB
---
name: pythonista-patterning
description: Use when writing new code, implementing features, or refactoring. Triggers on "pattern", "reuse", "duplicate", "extract", "helper", "refactor", "architecture", "DRY", "don't repeat yourself", "abstract", "reusable", "similar", "existing code", or when about to write new functionality.
---

# Pattern Discovery and Code Reuse

## Core Philosophy

**Before writing ANY new code, actively search for existing patterns and reuse opportunities.**

Duplicating code with subtle variations is one of the most damaging things you can do to a codebase.

## Pattern Discovery Workflow

### 1. Search for Similar Implementations

```bash
# In Claude Code, use the Grep tool instead of bash grep:
# pattern="similar_function" path="src/"

# Check sibling files in same directory
ls src/services/

# Look at parallel structures
# If writing campaign_api.py, check drip_api.py, prompt_api.py
```

### 2. Document Patterns Found

- Note the common structure/approach
- Identify what varies vs what stays the same
- List helper functions or utilities used

### 3. Follow Established Patterns Exactly

- Use the same parameter names and types
- Use the same error handling approach
- Use the same validation strategy

### 4. Identify Reuse Opportunities

- Spot duplicated logic that can be extracted
- Find DB queries that appear multiple times
- Notice validation patterns repeated across files

## Balance: Don't Over-Engineer, Don't Under-Engineer

### Under-Engineering (BAD)

```python
# campaign_api.py
async def update_campaign(handle: str, campaign: Campaign):
    if campaign.version == 0:
        current = await collection.find_one({"handle": handle})
        next_version = (current["campaign"]["version"] + 1) if current else 1
        campaign.version = next_version

# drip_api.py - DUPLICATE with subtle variation!
async def update_drip(handle: str, drip: Drip):
    if drip.version == 0:
        current = await collection.find_one({"handle": handle})
        next_version = (current["drip"]["version"] + 1) if current else 1
        drip.version = next_version
```

### Over-Engineering (BAD)

```python
# Creating a generic "VersionedEntityManager" for only 2 entities
class VersionedEntityManager(ABC, Generic[T]):
    # 50+ lines of generic infrastructure for 2 use cases
```

### Right Balance (GOOD)

```python
# Simple, focused helper
async def auto_increment_version(
    collection, handle: str, field_name: str, entity: VersionedEntity
) -> VersionedEntity:
    """Auto-increment version using version=0 sentinel."""
    if entity.version == 0:
        current = await collection.find_one({"handle": handle})
        current_version = current.get(field_name, {}).get("version", 0) if current else 0
        entity.version = current_version + 1
    return entity

# Usage
campaign = await auto_increment_version(collection, handle, "campaign", campaign)
drip = await auto_increment_version(collection, handle, "drip", drip)
```

## Simple Helper vs Infrastructure

### Simple Helper - Extract Immediately
- Duplicated calculations
- Repeated DB queries (same query in 3+ places)
- Filtering/validation logic repeated across functions
- **Action**: Extract now, include in current PR

### Infrastructure - Ask First
- Affects how multiple components interact
- Introduces new architectural layer
- **Action**: Ask user, likely separate PR

## Trust the Architecture

**NEVER duplicate validation that already exists in lower layers.**

```python
# WRONG - Service layer blocks API
async def _create_item(self, name, item):
    versions = await api.list_versions(id)  # Checking what API handles!
    if versions:
        raise ValueError(f"Already exists")

# CORRECT - Service layer trusts API
async def _create_item(self, name, item):
    validate_name(name)  # Only validate what service should
    return await api.create_item(item)  # Let API handle versioning
```

## Checklist

Before writing new code:
- [ ] Searched for existing patterns (Grep tool, sibling files)
- [ ] Documented patterns found
- [ ] Following established patterns exactly
- [ ] Identified reuse opportunities
- [ ] Not duplicating validation from lower layers
- [ ] Simple helpers extracted, infrastructure changes discussed

## Related Skills

- [/pythonista-debugging](../pythonista-debugging/SKILL.md) - Root cause analysis
- [/pythonista-testing](../pythonista-testing/SKILL.md) - Testing patterns
- [/pythonista-reviewing](../pythonista-reviewing/SKILL.md) - Code review
- [/pythonista-typing](../pythonista-typing/SKILL.md) - Type patterns

Overview

This skill helps developers discover existing code patterns and extract reusable helpers before writing new code. It enforces a pragmatic balance: prefer small focused helpers extracted immediately, and escalate architectural changes for discussion. Use it to avoid subtle duplication and keep implementations consistent across a codebase.

How this skill works

It guides you to search for similar implementations (sibling files, parallel modules, repository-wide grep) and document what is common vs what varies. It recommends following established naming, parameter, and error-handling patterns, and gives concrete rules for when to extract a simple helper vs propose new infrastructure. It includes a short checklist to run before adding or changing code.

When to use it

  • Before writing any new functionality that might resemble existing code
  • When you see keywords like pattern, duplicate, extract, helper, refactor, or DRY
  • When adding similar endpoints, services, or database queries in multiple places
  • During code review when spotting repeated logic or inconsistent validation
  • When preparing a change that could affect multiple modules or teams

Best practices

  • Search sibling and parallel files first; use repository grep to confirm scope
  • Document the common structure and clearly list what varies vs what stays constant
  • Match existing parameter names, types, error handling, and validation strategies exactly
  • Extract small, focused helpers immediately for duplicated calculations or queries repeated 3+ times
  • Propose new infrastructure only after discussion if the change affects multiple components or adds an architectural layer
  • Never duplicate validation handled by lower layers; trust each layer’s responsibilities

Example use cases

  • You’re implementing update_campaign and find an almost-identical update_drip — extract an auto_increment_version helper
  • Multiple services perform the same DB query — extract a shared repository function and update callers in the same PR
  • You notice repeated validation logic across endpoints — extract a validator utility and reuse it consistently
  • Two feature teams consider a shared manager; use this skill to decide between a simple helper or starting a design discussion
  • Refactoring to reduce duplicated error handling across similar API functions

FAQ

When should I extract a helper immediately?

If the same calculation, query, or validation appears in 3+ places or will be duplicated in the current change, extract a focused helper and include it in your PR.

When is a new infrastructure component appropriate?

When the change affects cross-component interactions, introduces a new architectural layer, or requires coordination across teams—ask first and likely create a separate design PR.