@lenardangeloolajay/len-toolkit 1.1.0

package/templates/skills/patterns-of-enterprise-application-architecture/patterns-of-enterprise-application-architecture.md

@@ -0,0 +1,404 @@
+# OBEY Patterns of Enterprise Application Architecture by Martin Fowler
+
+## Purpose
+
+This repository follows the practical style of **Patterns of Enterprise Application Architecture**:
+structure enterprise software around clear responsibilities for domain logic, persistence, transaction boundaries, integration, and presentation.
+
+All code generation, edits, and reviews must optimize for:
+- explicit separation of concerns
+- predictable business logic placement
+- appropriate enterprise patterns instead of accidental coupling
+- manageable persistence and transaction boundaries
+- clear mapping between in-memory objects and external systems
+- code that is maintainable under real enterprise constraints
+
+This file is a binding engineering policy: `MUST` is binding, `SHOULD` is a strong default, and `MUST NOT` is forbidden.
+
+---
+
+## Primary Directive
+
+Enterprise software is not improved by inventing architecture from scratch for every feature.
+Prefer a small number of well-understood structural patterns, applied deliberately.
+
+When uncertain, choose the design that makes these responsibilities explicit:
+- presentation and transport
+- application workflow
+- domain logic
+- data source interaction
+- transaction management
+- concurrency control
+- integration boundaries
+
+Do not let one class or layer own all of them.
+
+---
+
+## Architectural Baseline
+
+### Layering
+Use layering as a default organizing principle:
+1. presentation and delivery
+2. application coordination
+3. domain logic
+4. data source and integration access
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+- upper layers may depend on lower ones
+- lower layers must not reach into presentation concerns
+- each layer must earn its existence by reducing coupling or clarifying responsibility
+
+Anti-patterns (MUST NOT):
+- controllers reaching directly into SQL and transaction details
+- domain logic embedded in views or handlers
+- repositories returning HTTP-shaped DTOs
+- fake layers that only pass calls through
+
+---
+
+## Choosing the Business Logic Pattern
+
+### Transaction Script
+Use when:
+- logic is simple
+- each request or use case is mostly independent
+- rich domain modeling is unnecessary
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+- scripts must remain short and use-case focused
+- do not let transaction scripts become dumping grounds for all business logic
+- if duplication, lifecycle, or invariant complexity grows, escalate to a stronger pattern
+
+### Table Module
+Use when:
+- logic is naturally organized around tabular data sets
+- calculations are set-oriented
+- object identity is not the key organizing force
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+- keep behavior centered on the table abstraction
+- do not fake entities if the real model is fundamentally tabular
+- isolate tabular logic from presentation and transport
+
+### Domain Model
+Use when:
+- domain complexity is significant
+- business rules, invariants, and lifecycles matter
+- identity, collaboration, and behavior belong in the model
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+- rich domain logic belongs in model objects
+- keep application coordination separate from domain decisions
+- avoid anemic models in behavior-rich domains
+
+---
+
+## Application Workflow Rules
+
+### Service Layer
+Use a service layer to define application operations.
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+1. Application services coordinate use cases.
+2. They define transaction boundaries and orchestration.
+3. They must not absorb all domain logic by default.
+4. They should expose an application-oriented API, not UI mechanics.
+
+### Remote Facade
+Use when:
+- the boundary is remote
+- coarse-grained APIs reduce chatty calls
+- transport shape differs from internal design
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+- expose coarse remote operations
+- translate between remote contracts and internal model
+- keep remote transport concerns at the boundary
+
+### Data Transfer Object
+Use when:
+- data crosses process or layer boundaries
+- batching values reduces remote or serialization cost
+- translation protects the internal model
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+- DTOs are transport structures, not domain models
+- keep mapping explicit
+- do not move business behavior into DTOs
+
+---
+
+## Persistence Pattern Rules
+
+### Repository
+Use repositories to present a collection-like interface over domain object access.
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+1. Repositories must speak in domain terms.
+2. Repository interfaces should reflect domain access needs rather than table shape.
+3. Repository implementations hide query, mapping, and storage details.
+4. Repositories must not become generic “everything” gateways.
+
+### Data Mapper
+Use when:
+- the domain model should remain decoupled from the database structure
+- object-relational mismatch is real
+- persistence logic deserves isolation
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+- mapping code belongs outside the domain objects
+- do not force domain objects to know SQL, record formats, or mapping mechanics
+- keep mapping explicit and testable
+
+### Row Data Gateway
+Use when behavior is simple and record-oriented.
+
+### Table Data Gateway
+Use when operations are naturally table-oriented and one table interface can clearly centralize access.
+
+### Active Record
+Use only when domain logic is simple and persistence coupling is acceptable.
+Do not default to Active Record for complex domains.
+
+---
+
+## Identity, Caching, and Unit-of-Work Rules
+
+### Identity Map
+- preserve one in-memory representation per identity per scope where needed
+- avoid duplicate object instances fighting each other inside one logical unit of work
+
+### Unit of Work
+- make transactional write coordination explicit
+- commit work as one logical unit
+- keep unit-of-work scope understandable
+
+### Lazy Load
+- use deliberately, not everywhere
+- know where lazy loading may trigger remote/database chatter
+- avoid lazy loading surprises in loops and serialization paths
+
+Anti-patterns (MUST NOT):
+- invisible N+1 behavior everywhere
+- hidden auto-persistence with surprising write timing
+- saving each object ad hoc from random callers
+
+---
+
+## Object-Relational Mapping Pattern Index
+
+- USE Identity Field when in-memory objects need stable database identity; keep identity mapping explicit.
+- USE Foreign Key Mapping when object references map to relational keys; avoid hiding expensive joins behind innocent traversal.
+- USE Association Table Mapping when many-to-many relationships need a separate relational table.
+- USE Dependent Mapping when child objects have no independent database identity outside their owner.
+- USE Embedded Value when a small value object can live inside the owning row without independent lifecycle.
+- USE Serialized LOB only when querying inside the value is not required and serialization versioning is controlled.
+- USE Single Table Inheritance when one table with nullable columns is simpler than multiple joins.
+- USE Class Table Inheritance when normalized subtype data is worth join complexity.
+- USE Concrete Table Inheritance when each concrete type can own its table without excessive duplication.
+- USE Inheritance Mappers to isolate inheritance persistence decisions from domain logic.
+- USE Metadata Mapping when mapping rules are regular enough to centralize safely; avoid it when metadata obscures exceptional behavior.
+- USE Query Object when query construction needs a composable object model instead of scattered SQL strings.
+
+---
+
+## Concurrency and Transaction Rules
+
+### Optimistic Offline Lock
+Use when conflicts are possible but uncommon.
+
+Rules (MUST unless marked SHOULD or MUST NOT):
+- detect conflicting concurrent updates
+- fail safely and explicitly
+- surface conflict resolution or merge semantics intentionally
+
+### Pessimistic Locking
+Use only when contention is expected and the cost is justified.
+
+### Transaction Boundaries
+1. Transaction boundaries must be explicit in application workflow.
+2. Avoid transactions that span remote calls when possible.
+3. Keep transactions short.
+4. Do not bury transaction ownership deep in helper classes.
+
+### Additional Offline Concurrency Patterns
+- USE Coarse-Grained Lock when related objects must be locked together to preserve a user-level edit.
+- USE Implicit Lock only when lock acquisition is reliably hidden without making concurrency invisible to maintainers.
+- Do not let implicit locking make transaction ownership or contention impossible to diagnose.
+
+---
+
+## Presentation Layer Rules
+
+1. Presentation code handles input, rendering, and transport concerns.
+2. Business rules must not live in controllers or views.
+3. Presentation models may differ from domain models.
+4. Formatting, pagination, and UI interaction state belong outside domain logic.
+
+Choose Page Controller vs Front Controller pragmatically, but keep routing concerns out of business logic.
+
+### Presentation Pattern Index
+- USE Model View Controller to separate domain model, view, and controller responsibilities.
+- USE Page Controller when each page/action can be handled independently.
+- USE Front Controller when centralized request handling, authentication, routing, or dispatch is valuable.
+- USE Template View when server-side templates clearly express the response.
+- USE Transform View when transforming data into output is clearer than embedding logic in templates.
+- USE Two Step View when shared presentation structure should be separated from page-specific content.
+- USE Application Controller when flow and navigation decisions need a dedicated coordinator.
+
+---
+
+## Offline and Integration Rules
+
+1. External systems must be accessed through clear boundaries.
+2. Translate partner formats into internal concepts.
+3. Integration events/messages are not domain objects.
+4. Do not allow integration convenience to dominate internal design.
+
+Anti-patterns (MUST NOT):
+- internal code shaped around partner API payloads
+- direct vendor DTOs used across the application
+- business logic embedded in serialization code
+
+---
+
+## Session State and Base Pattern Index
+
+- USE Client Session State only when client storage is acceptable and integrity/security implications are handled.
+- USE Server Session State when server-managed session data is needed and scaling/cleanup costs are explicit.
+- USE Database Session State when session durability or server-farm sharing outweighs database load.
+- USE Gateway to isolate access to an external resource or subsystem.
+- USE Mapper to move data between objects or layers while keeping both sides independent.
+- USE Layer Supertype only when shared layer behavior is real and stable.
+- USE Separated Interface when clients should depend on an interface in a different package from implementation details.
+- USE Registry sparingly for well-known objects; avoid turning it into global hidden dependency.
+- USE Value Object for small values where equality by value and immutability simplify code.
+- USE Money for currency amounts so rounding, currency, and arithmetic rules stay explicit.
+- USE Special Case to replace repeated null or exceptional handling with a named object.
+- USE Plugin when implementations must be selected or extended without changing core code.
+- USE Service Stub to test or run without a real remote service.
+- USE Record Set when tabular data is the natural interchange shape and object behavior is not needed.
+
+---
+
+## Distribution Rules
+
+1. Do not distribute objects or services remotely by default.
+2. Remote boundaries must be coarse-grained.
+3. Separate local object design from remote contract design.
+4. Budget explicitly for latency, serialization, versioning, and partial failure.
+
+Anti-patterns (MUST NOT):
+- chatty remote object interfaces
+- assuming local method-call semantics over a network
+- leaking domain internals through remote endpoints
+
+---
+
+## Code Generation Rules
+
+When generating code, apply this order:
+1. identify the business logic pattern that actually fits the complexity
+2. place use-case coordination in an application/service layer
+3. place domain decisions in the domain model when the domain is rich
+4. place persistence behind repositories, mappers, or gateways
+5. define transaction boundaries explicitly
+6. define DTOs or remote facades only at boundaries
+7. keep presentation and transport concerns at the edge
+
+Default choices:
+- simple CRUD -> transaction script or simple service layer
+- rich invariants -> domain model + repository + mapper
+- table-oriented calculations -> table module or table gateway
+- remote boundary -> remote facade + DTO
+
+Avoid by default:
+- using domain model everywhere regardless of complexity
+- generic repository for everything
+- exposing persistence models directly to callers
+- placing transactions, validation, rendering, and SQL in one class
+
+---
+
+## Review Rules
+
+When reviewing code, actively look for:
+- domain logic in controllers or views
+- repositories returning transport shapes
+- lower layers knowing presentation details
+- trivial CRUD wrapped in excessive modeling
+- complex rules trapped in transaction scripts
+- SQL spread through business code
+- missing transaction boundaries
+- hidden unit-of-work behavior
+- accidental N+1 loading
+- chatty remote APIs
+- no translation between internal and remote models
+
+---
+
+## Forbidden Patterns
+
+### Layering Theater
+- five layers that only forward method calls
+
+### Generic Repository Everywhere
+- one CRUD abstraction for all domain and data access
+- repository APIs shaped by tables instead of use cases
+
+### ORM-Driven Everything
+- all design decisions dictated by ORM convenience
+- aggregates, services, and DTOs collapsed into one persistence model
+
+### Controller-Centric Enterprise App
+- request handlers coordinating transactions, SQL, domain rules, and external calls
+
+### Distributed Object Fantasy
+- pretending network calls are normal method calls
+
+### Unclear Transaction Ownership
+- random save calls across layers
+- no clear transaction owner
+- long-running workflows treated as one immediate transaction
+
+---
+
+## Testing Rules
+
+1. Test domain logic independently from presentation and persistence when possible.
+2. Test repositories, mappers, and gateways separately as data-access infrastructure.
+3. Test service/application workflows for transaction and orchestration behavior.
+4. Test concurrency behaviors where optimistic or pessimistic locking matters.
+5. Test DTO and remote facade mapping at the boundaries.
+
+---
+
+## Review Checklist
+
+Before finalizing any change, verify:
+- Did we choose the right business logic pattern for the actual complexity?
+- Are presentation, workflow, domain logic, and persistence responsibilities distinct?
+- Is transaction ownership explicit?
+- Are repositories or gateways shaped by use cases or aggregates rather than raw tables?
+- Is mapping isolated from domain logic?
+- Are remote boundaries coarse-grained and translated explicitly?
+- Did we avoid generic repository overreach?
+- Did we avoid controller-centric design?
+- Did we avoid layering theater?
+- Did we keep concurrency and loading assumptions visible?
+
+If any answer is no, revise before shipping.
+
+---
+
+## Final Instruction
+
+When uncertain, choose the smallest set of enterprise patterns that makes:
+1. business logic placement obvious
+2. persistence and mapping explicit
+3. transaction boundaries clear
+4. remote boundaries coarse and safe
+5. the application easier to evolve under real enterprise constraints
+
+Reject fashionable complexity and accidental coupling alike.

package/templates/skills/patterns-of-enterprise-application-architecture/patterns-of-enterprise-application-architecture.mini.md

@@ -0,0 +1,54 @@
+# OBEY Patterns of Enterprise Application Architecture by Martin Fowler
+
+## When to use
+
+Use when designing or reviewing enterprise application code that crosses presentation, application workflow, domain logic, persistence, transactions, concurrency, integration, session state, or remote boundaries.
+
+## Primary bias to correct
+
+Enterprise applications are not improved by inventing architecture for every feature or by letting the framework, ORM, database schema, or transport shape choose the design. Use a small set of well-understood patterns to make responsibilities and boundaries explicit.
+
+## Decision rules
+
+- Make responsibility ownership explicit before naming patterns: presentation and transport, application workflow, domain logic, data source interaction, transaction management, concurrency control, and integration boundaries must not collapse into one class or layer.
+- Use layering as the default organizing principle, but every layer must earn its cost by reducing coupling or clarifying responsibility; forbid lower layers from reaching into presentation concerns and reject pass-through layering theater.
+- Choose the business logic pattern by force: Transaction Script for short independent simple flows, Table Module for table-centered set logic, and Domain Model for significant rules, invariants, identity, lifecycle, or collaboration.
+- Let Transaction Scripts stay use-case focused, Table Modules stay honestly tabular, and Domain Models own rich behavior; escalate when duplication, lifecycle, or invariant complexity grows.
+- Use a Service Layer to define application operations, coordinate use cases, own transaction boundaries and orchestration, expose an application-oriented API, and avoid absorbing all domain logic by default.
+- At remote or cross-layer boundaries, use Remote Facade and DTOs to make coarse operations, batching, translation, and transport shape explicit; DTOs are transport structures, not domain models.
+- Choose persistence patterns deliberately: repositories speak domain terms and hide query/mapping/storage details, Data Mappers keep SQL and record formats outside domain objects, gateways centralize record/table access, and Active Record is only for simple domains where persistence coupling is acceptable.
+- Keep identity, write coordination, and loading behavior visible: use Identity Map for one object per identity per scope, Unit of Work for one logical transactional commit, and Lazy Load only where hidden database or remote chatter will not surprise loops or serializers.
+- Choose object-relational mappings by identity, lifecycle, query needs, schema shape, and evolution cost; keep identity fields, foreign keys, association tables, dependent objects, embedded values, serialized values, inheritance mapping, metadata mapping, and query objects explicit rather than accidental.
+- Design concurrency and transactions in the application workflow: optimistic locks detect conflicts and surface merge semantics, pessimistic locks require justified contention, transactions stay short, remote calls usually sit outside transactions, and helpers must not hide transaction ownership.
+- Use coarse-grained and implicit offline locks only when they preserve a user-level edit without making ownership, contention, or stale-lock cleanup impossible to diagnose.
+- Keep presentation code focused on input, rendering, routing, formatting, pagination, UI state, and transport; business rules stay out of controllers, views, templates, and presentation models.
+- Access external systems through boundaries, translate partner formats into internal concepts, treat integration events and messages as boundary data, and do not let vendor payloads or serialization code shape internal domain design.
+- Choose session state deliberately: client, server, or database session storage must account for integrity, security, scaling, cleanup, durability, server-farm sharing, and database load.
+- Use base patterns only for concrete pressure: Gateway for external resources, Mapper for independent sides, Layer Supertype for real shared behavior, Separated Interface for dependency breaks, Registry for controlled well-known objects, Value Object and Money for value semantics, Special Case for repeated null/default behavior, Plugin for runtime extension, Service Stub for remote-service tests, and Record Set when tabular interchange is natural.
+- Do not distribute objects or services by default; when distribution is required, separate local object design from the remote contract and budget latency, serialization, versioning, and partial failure.
+- Generate code in this order: choose the business logic pattern, place use-case coordination in application services, put rich domain decisions in the domain model, hide persistence behind repositories/mappers/gateways, define transactions explicitly, put DTOs or facades only at boundaries, and keep presentation/transport at the edge.
+- Test each responsibility at the level where it owns behavior: domain logic apart from UI and persistence, repositories/mappers/gateways as data infrastructure, services for workflow and transactions, locking where concurrency matters, and DTO/facade mapping at boundaries.
+
+## Trigger rules
+
+- If domain behavior appears in controllers, views, handlers, SQL scripts, triggers, DTOs, framework glue, serialization code, or vendor payload adapters, move it to the owning layer or justify the exception explicitly.
+- If one class or layer coordinates rendering, validation, SQL, transactions, domain rules, and external calls, split by responsibility before adding another pattern.
+- If a Transaction Script accumulates duplicated decisions, invariants, or lifecycle rules, revisit Domain Model and the supporting persistence pattern.
+- If a model is table-shaped in a behavior-rich domain, a repository is generic CRUD, or a service only forwards to persistence, check whether the ORM or database schema has taken over the design.
+- If SQL, mapping, transaction ownership, lock acquisition, saves, or external resource access is scattered across callers, introduce the smallest repository, mapper, gateway, Unit of Work, service boundary, or policy that centralizes the rule.
+- If lazy loading, duplicate in-memory identities, hidden auto-persistence, N+1 behavior, or ad hoc saves can happen inside one logical work scope, define identity scope, Unit of Work, and loading behavior before continuing.
+- If concurrency conflicts, stale locks, user-level edits, or long-running workflows matter, choose explicit optimistic, pessimistic, coarse-grained, or implicit locking semantics instead of relying on informal developer discipline.
+- If a remote API looks like local object collaboration, leaks domain internals, or requires many calls per user action, redesign it as a coarse use-case contract with DTO translation.
+- If session state has unclear owner, lifetime, storage location, security, scaling, failover, durability, or cleanup behavior, choose the session-state pattern before adding features.
+- If a layer exists only to forward calls, a generic repository covers everything, an ORM model doubles as aggregate/service/DTO, or a controller owns the enterprise workflow, treat it as a forbidden-pattern review blocker.
+
+## Final checklist
+
+- Are presentation, workflow, domain, persistence, transaction, concurrency, integration, session, and distribution responsibilities separated intentionally?
+- Does the business logic pattern match actual complexity rather than habit or framework shape?
+- Are repositories, mappers, gateways, Active Record, Unit of Work, Identity Map, and Lazy Load used only where their forces fit?
+- Is transaction ownership explicit, short, and kept out of hidden helpers or remote-call spans?
+- Are concurrency conflicts, offline locks, identity scope, and loading behavior visible?
+- Are remote and integration boundaries coarse, translated, version-aware, and failure-aware?
+- Is session state owned, protected, scalable, durable enough, and cleaned up?
+- Are tests aligned to the responsibility that owns each behavior?

package/templates/skills/patterns-of-enterprise-application-architecture/patterns-of-enterprise-application-architecture.nano.md

@@ -0,0 +1,35 @@
+# OBEY Patterns of Enterprise Application Architecture by Martin Fowler
+
+## When to use
+
+Use as a compact always-on compass for enterprise application pattern choices.
+
+## Primary bias to correct
+
+Pattern reuse is not pattern choice. Make responsibilities, persistence, transactions, and remote boundaries explicit before naming a pattern.
+
+## Decision rules
+
+- Keep presentation/transport, application workflow, domain logic, data source interaction, transaction management, concurrency control, and integration boundaries logically separate.
+- Choose the business logic pattern by complexity: Transaction Script for simple independent flows, Table Module for table-centered set logic, and Domain Model for rich behavior, invariants, identity, or lifecycle.
+- Use Service Layer for use-case coordination and transaction orchestration without turning it into the default home for all domain behavior.
+- Match persistence to coupling pressure: Repository/Data Mapper for domain separation, Gateway for record or table access, and Active Record only for simple persistence-coupled domains.
+- Make Unit of Work, Identity Map, Lazy Load, transaction boundaries, and lock semantics visible before trusting ORM behavior.
+- Keep presentation, DTOs, integration messages, vendor payloads, and serialization code free of business behavior.
+- Treat remote boundaries as expensive and failure-prone: use coarse Remote Facade operations, DTO translation, explicit versioning, and partial-failure handling.
+- Use session-state and base patterns only for concrete pressure; avoid fake layers, generic repositories, ORM-driven design, controller-centric workflows, and distributed-object illusions.
+
+## Trigger rules
+
+- If one class or layer owns UI, workflow, domain rules, SQL, transactions, and external calls, split responsibility before adding more patterns.
+- If a simple Transaction Script grows duplication, invariants, or lifecycle decisions, revisit Domain Model and persistence pattern together.
+- If repositories are table-shaped CRUD, models mirror tables in behavior-rich areas, or services only forward calls, check whether the database or ORM has captured the design.
+- If lazy loading, duplicate identities, hidden writes, N+1 behavior, ad hoc saves, or unclear locks appear, define identity scope, Unit of Work, loading, and concurrency semantics explicitly.
+- If a remote API is chatty, object-shaped, or leaks domain internals, redesign it as a coarse use-case boundary with DTO translation.
+
+## Final checklist
+
+- Right business logic and persistence pattern for actual complexity?
+- Explicit layer, transaction, identity, loading, lock, session, and integration ownership?
+- Business rules kept out of UI, DTOs, integration, and serialization?
+- Remote boundary coarse, translated, version-aware, and failure-aware?

package/templates/skills/ponytail/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: ponytail
+description: >
+  Forces the laziest solution that actually works, simplest, shortest, most
+  minimal. Channels a senior dev who has seen everything: question whether the
+  task needs to exist at all (YAGNI), reach for the standard library before
+  custom code, native platform features before dependencies, one line before
+  fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY
+  coding task: writing, adding, refactoring, fixing, reviewing, or designing
+  code, and choosing libraries or dependencies. Also use whenever the user
+  says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal
+  solution", "yagni", "do less", or "shortest path", or complains about
+  over-engineering, bloat, boilerplate, or unnecessary dependencies. Do NOT
+  use for non-coding requests (general knowledge, prose, translation,
+  summaries, recipes).
+metadata:
+  argument-hint: "[lite|full|ultra]"
+license: MIT
+---
+
+# Ponytail
+
+You are a lazy senior developer. Lazy means efficient, not careless. You have
+seen every over-engineered codebase and been paged at 3am for one. The best
+code is the code never written.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE. No drift back to over-building. Still active if
+unsure. Off only: "stop ponytail" / "normal mode". Default: **full**.
+Switch: `/ponytail lite|full|ultra`.
+
+## The ladder
+
+Stop at the first rung that holds:
+
+1. **Does this need to exist at all?** Speculative need = skip it, say so in one line. (YAGNI)
+2. **Already in this codebase?** A helper, util, type, or pattern that already lives here → reuse it. Look before you write; re-implementing what's a few files over is the most common slop.
+3. **Stdlib does it?** Use it.
+4. **Native platform feature covers it?** `<input type="date">` over a picker lib, CSS over JS, DB constraint over app code.
+5. **Already-installed dependency solves it?** Use it. Never add a new one for what a few lines can do.
+6. **Can it be one line?** One line.
+7. **Only then:** the minimum code that works.
+
+The ladder is a reflex, not a research project - but it runs *after* you
+understand the problem, not instead of it. Read the task and the code it
+touches first, trace the real flow end to end, then climb. Two rungs work →
+take the higher one and move on. The first lazy solution that works is the
+right one - once you actually know what the change has to touch.
+
+**Bug fix = root cause, not symptom.** A report names a symptom. Before you
+edit, grep every caller of the function you're about to touch. The lazy fix IS
+the root-cause fix: one guard in the shared function is a smaller diff than a
+guard in every caller - and patching only the path the ticket names leaves
+every sibling caller still broken. Fix it once, where all callers route through.
+
+## Rules
+
+- No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.
+- No boilerplate, no scaffolding "for later", later can scaffold for itself.
+- Deletion over addition. Boring over clever, clever is what someone decodes at 3am.
+- Fewest files possible. Shortest working diff wins - but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
+- Complex request? Ship the lazy version and question it in the same response, "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
+- Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.
+- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path (`# ponytail: global lock, per-account locks if throughput matters`).
+
+## Output
+
+Code first. Then at most three short lines: what was skipped, when to add it.
+No essays, no feature tours, no design notes. If the explanation is longer
+than the code, delete the explanation, every paragraph defending a
+simplification is complexity smuggled back in as prose. Explanation the user
+explicitly asked for (a report, a walkthrough, per-phase notes) is not debt,
+give it in full, the rule is only against unrequested prose.
+
+Pattern: `[code] → skipped: [X], add when [Y].`
+
+## Intensity
+
+| Level | What change |
+|-------|------------|
+| **lite** | Build what's asked, but name the lazier alternative in one line. User picks. |
+| **full** | The ladder enforced. Stdlib and native first. Shortest diff, shortest explanation. Default. |
+| **ultra** | YAGNI extremist. Deletion before addition. Ship the one-liner and challenge the rest of the requirement in the same breath. |
+
+Example: "Add a cache for these API responses."
+- lite: "Done, cache added. FYI: `functools.lru_cache` covers this in one line if you'd rather not own a cache class."
+- full: "`@lru_cache(maxsize=1000)` on the fetch function. Skipped custom cache class, add when lru_cache measurably falls short."
+- ultra: "No cache until a profiler says so. When it does: `@lru_cache`. A hand-rolled TTL cache class is a bug farm with a hit rate."
+
+## When NOT to be lazy
+
+Never simplify away: input validation at trust boundaries, error handling
+that prevents data loss, security measures, accessibility basics, anything
+explicitly requested. User insists on the full version → build it, no
+re-arguing.
+
+Never lazy about understanding the problem. The ladder shortens the
+solution, never the reading. Trace the whole thing first - every file the
+change touches, the actual flow - before picking a rung. Laziness that skips
+comprehension to ship a small diff is the dangerous kind: it dresses up as
+efficiency and ships a confident wrong fix. Read fully, then be lazy.
+
+Hardware is never the ideal on paper: a real clock drifts, a real sensor
+reads off, a PCA9685 runs a few percent fast. Leave the calibration knob, not
+just less code, the physical world needs tuning a minimal model can't see.
+
+Lazy code without its check is unfinished. Non-trivial logic (a branch, a
+loop, a parser, a money/security path) leaves ONE runnable check behind, the
+smallest thing that fails if the logic breaks: an `assert`-based
+`demo()`/`__main__` self-check or one small `test_*.py`. No frameworks, no
+fixtures, no per-function suites unless asked. Trivial one-liners need no
+test, YAGNI applies to tests too.
+
+## Boundaries
+
+Ponytail governs what you build, not how you talk (pair with Caveman for
+terse prose). "stop ponytail" / "normal mode": revert. Level persists until
+changed or session end.
+
+The shortest path to done is the right path.
+
+
+Read project AGENTS.md for shared workflow, scope, and evidence policy.

package/templates/skills/ponytail-audit/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: ponytail-audit
+description: >
+  Whole-repo audit for over-engineering. Like ponytail-review, but scans the
+  entire codebase instead of a diff: a ranked list of what to delete, simplify,
+  or replace with stdlib/native equivalents. Use when the user says "audit this
+  codebase", "audit for over-engineering", "what can I delete from this repo",
+  "find bloat", "ponytail-audit", or "/ponytail-audit". One-shot report, does
+  not apply fixes.
+license: MIT
+---
+
+ponytail-review, repo-wide. Scan the whole tree instead of a diff. Rank
+findings biggest cut first.
+
+## Tags
+
+Same as ponytail-review:
+
+- `delete:` dead code, unused flexibility, speculative feature. Replacement: nothing.
+- `stdlib:` hand-rolled thing the standard library ships. Name the function.
+- `native:` dependency or code doing what the platform already does. Name the feature.
+- `yagni:` abstraction with one implementation, config nobody sets, layer with one caller.
+- `shrink:` same logic, fewer lines. Show the shorter form.
+
+## Hunt
+
+Deps the stdlib or platform already ships, single-implementation interfaces,
+factories with one product, wrappers that only delegate, files exporting one
+thing, dead flags and config, hand-rolled stdlib.
+
+## Output
+
+One line per finding, ranked: `<tag> <what to cut>. <replacement>. [path]`.
+End with `net: -<N> lines, -<M> deps possible.` Nothing to cut: `Lean already. Ship.`
+
+## Boundaries
+
+Scope: over-engineering and complexity only. Correctness bugs, security holes,
+and performance are explicitly out of scope. Route them to a normal review
+pass. Lists findings, applies nothing. One-shot.
+"stop ponytail-audit" or "normal mode" to revert.
+
+
+Read project AGENTS.md for shared workflow, scope, and evidence policy.