@polderlabs/bizar-omp 0.9.0 → 0.10.0

package/skills/bizar-uiux/references/principles.md

@@ -0,0 +1,244 @@
+# Bizar UI/UX principle catalog
+
+This reference translates common UX psychology and UI composition laws into operational design guidance. Use principles as hypotheses about user behavior, not as automatic rules. Context, accessibility, product conventions, and observed user evidence take precedence.
+
+## Decision-making and cognitive effort
+
+### Hick's Law
+Decision time tends to grow as the number and complexity of choices increases.
+
+Use it to:
+- reduce simultaneous choices on time-sensitive paths;
+- separate advanced options from common actions;
+- provide sensible defaults and recommendations;
+- split genuinely complex tasks into meaningful stages.
+
+Do not use it to remove necessary comparison information or force users through excessive wizard steps.
+
+### Choice overload
+Too many alternatives can reduce decision confidence and increase abandonment.
+
+Prefer filtering, ranking, comparison, presets, and progressive disclosure over dumping all options into one undifferentiated list.
+
+### Cognitive load
+Every control, instruction, unfamiliar pattern, remembered value, and context switch consumes mental effort.
+
+Reduce load by making state visible, reusing conventions, grouping information, removing redundant decisions, and keeping required information near the action that needs it.
+
+### Working memory
+Users should not have to remember information from one view to operate another.
+
+Keep important values, prior selections, requirements, and task context visible or retrievable. Prefer recognition over recall.
+
+### Miller-style chunking
+Human short-term memory benefits from meaningful grouping; exact numeric limits are not a design target.
+
+Break dense information into semantically coherent groups. Do not create arbitrary seven-item rules.
+
+### Chunking
+Group related information into understandable units to improve scanning and comprehension.
+
+Use headings, spacing, progressive disclosure, grouped controls, and summaries that reflect task structure.
+
+### Tesler's Law / conservation of complexity
+Some complexity is inherent and must live somewhere.
+
+Move repetitive, technical, or machine-manageable complexity into the system. Keep decision-relevant complexity visible to the user.
+
+### Occam-style simplicity
+When two designs solve the same problem equally well, prefer the one with fewer assumptions and unnecessary mechanisms.
+
+Do not confuse simplicity with fewer pixels. A slightly richer interface may be simpler to understand.
+
+### Complexity bias
+People can overvalue complicated explanations or systems.
+
+Do not add configuration, abstraction, dashboards, or workflow steps merely to make a product appear powerful.
+
+## Familiarity, models, and consistency
+
+### Jakob's Law
+Users bring expectations learned from other products.
+
+Use familiar navigation, control behavior, terminology, form patterns, and platform conventions for ordinary tasks. Deviate when there is a clear user benefit, and make the new behavior learnable.
+
+### Mental models
+Users act according to their internal understanding of how the system works.
+
+Make cause/effect, state, ownership, and object relationships match the conceptual model presented by the interface. Avoid labels or layouts that imply a false structure.
+
+### Consistency
+Repeated patterns reduce learning cost and strengthen predictability.
+
+Keep the same component, state, terminology, placement, and behavior for the same concept. Differentiate only when semantics differ.
+
+### Paradox of the active user
+Users commonly start using software instead of studying instructions first.
+
+Make the primary path self-explanatory. Put help in context, reveal advanced guidance when needed, and do not rely on manuals or onboarding slides to explain basic operation.
+
+## Target acquisition and interaction speed
+
+### Fitts's Law
+Larger and nearer targets are easier and faster to acquire.
+
+Give important controls adequate hit areas, place frequent actions where pointer/thumb travel is low, avoid tiny icon-only targets, and keep destructive actions separated from common actions.
+
+### Doherty Threshold
+Interfaces feel much more fluid when interaction feedback arrives quickly; the often-cited target is around 400 ms for keeping the interaction loop engaged.
+
+Acknowledge actions immediately. Use optimistic state, skeletons, inline progress, streaming, or background execution when the underlying work is slower.
+
+### Parkinson's Law
+Work tends to expand to fill the available time.
+
+For UX, constrain tasks and forms to what users actually need. Do not make a workflow longer because the available surface permits it.
+
+## Motivation, progress, and memory
+
+### Goal-gradient effect
+Motivation often increases as users perceive themselves getting closer to completion.
+
+Expose meaningful progress, completed steps, remaining work, and achievable next actions. Avoid fake progress indicators.
+
+### Zeigarnik effect
+Unfinished tasks remain cognitively salient.
+
+Preserve drafts and progress, make incomplete work easy to resume, and use pending-state cues carefully. Do not weaponize unfinished-state anxiety for dark patterns.
+
+### Peak-end rule
+People disproportionately remember intense moments and the ending of an experience.
+
+Prioritize failure recovery, success confirmation, checkout completion, onboarding finish, and other high-emotion points. A polished ending cannot compensate for a broken flow, but a poor ending can damage an otherwise good one.
+
+### Serial position effect
+People tend to remember items at the beginning and end of a sequence more readily.
+
+Put high-priority actions or information in strong positions, but do not hide lower-ranked critical items in the middle of long lists.
+
+### Flow
+Sustained work benefits from clear goals, immediate feedback, manageable challenge, and minimal interruption.
+
+Keep expert workflows fast, preserve context, avoid unnecessary modal interruptions, and reduce repetitive confirmation where risk does not require it.
+
+## Attention and emphasis
+
+### Selective attention
+Users focus on stimuli related to their current goal and ignore much of the rest.
+
+Put task-relevant information near the point of action. Do not assume a banner, tooltip, or distant status indicator will be noticed simply because it exists.
+
+### Von Restorff / isolation effect
+A visually distinct item attracts attention and is more memorable.
+
+Use singular emphasis for the primary action, warning, selected state, or exceptional item. Avoid multiple competing accent treatments.
+
+### Aesthetic-usability effect
+Visually polished interfaces are often perceived as easier to use.
+
+Use visual quality to create trust and reduce perceived friction, but never let polish hide bad interaction design, inaccessible contrast, or ambiguous behavior.
+
+### Cognitive bias
+Judgment is affected by predictable heuristics and context.
+
+Use behavioral principles to reduce mistakes and improve comprehension, not to manipulate users into decisions against their interests.
+
+## Grouping and Gestalt structure
+
+### Proximity
+Nearby elements are perceived as related.
+
+Use spacing before borders. Keep labels near their controls, related actions together, and unrelated groups separated.
+
+### Common region
+Elements enclosed by a shared boundary are perceived as a group.
+
+Use containers only when the boundary communicates a real relationship. Too many cards create visual noise and competing regions.
+
+### Similarity
+Elements with similar appearance are interpreted as related.
+
+Keep shared semantics visually consistent. Avoid making different actions look identical or identical actions look unrelated.
+
+### Uniform connectedness
+Explicit visual connections imply stronger relationships than mere proximity.
+
+Use connecting lines, stepper paths, grouped controls, and shared backgrounds when relationships must be unmistakable.
+
+### Prägnanz / simplicity of form
+People tend to interpret complex visual input as the simplest stable structure available.
+
+Create clean silhouettes, obvious hierarchy, and unambiguous grouping. Remove ornamental geometry that makes the structure harder to parse.
+
+### Closure
+People infer complete forms from partial visual information.
+
+Useful for icons, charts, logos, and restrained decorative composition. Do not depend on closure for essential controls or information where ambiguity would hurt usability.
+
+### Continuity
+Aligned elements and continuous visual paths are perceived as related.
+
+Use alignment to lead scanning through forms, tables, timelines, navigation, and multi-step flows. Break continuity intentionally to signal a semantic break.
+
+### Symmetry
+Balanced symmetrical structures are often perceived as coherent and stable.
+
+Use symmetry for calm, comparison, and balanced layouts. Break it deliberately when hierarchy or directional emphasis matters more.
+
+## Composition and visual hierarchy
+
+### Rule of thirds
+A 3x3 compositional grid can help establish balanced focal placement in image-heavy, landing-page, editorial, or promotional layouts.
+
+Treat it as a composition aid, not an application-layout requirement. Functional product interfaces usually benefit more from grid consistency and task hierarchy than photographic composition rules.
+
+### White space
+Unused space is an active structural tool.
+
+Use it to separate groups, increase legibility, create emphasis, and reduce density. Avoid both cramped interfaces and wasteful whitespace that pushes important controls off-screen.
+
+### Typography hierarchy
+Text size, weight, spacing, and style should reveal the information structure before the user reads every word.
+
+Keep heading levels coherent, body text readable, metadata subordinate, labels distinguishable, and emphasis limited. Do not use font size alone to communicate semantics.
+
+### Contrast
+Contrast directs attention and establishes hierarchy.
+
+Use contrast for readability, primary actions, selected state, errors, and key distinctions. Verify color contrast and avoid relying on color as the only signal.
+
+### Color theory
+Color carries perceptual and cultural associations and can encode hierarchy/state.
+
+Use a constrained semantic palette, consistent state colors, accessible contrast, and theme-aware tokens. Avoid assigning meaning only through hue and avoid decorative color that competes with status/action semantics.
+
+## Robustness and resilience
+
+### Postel-style robustness
+User input is variable and imperfect; interfaces should tolerate reasonable variation while producing clear, consistent output.
+
+Normalize benign input, accept common formatting differences, show constraints before failure, and return specific recovery guidance. Do not apply this principle to security boundaries where permissiveness creates risk.
+
+### Pareto principle
+A small subset of actions often accounts for most use.
+
+Optimize frequent, high-value paths first. Keep rare expert functions available without letting them dominate the primary interface.
+
+## Practical combination rules
+
+Some principles reinforce each other:
+
+- Hick + choice overload + cognitive load -> reduce and structure decisions.
+- Fitts + selective attention + contrast -> make the primary action easy to find and hit.
+- Proximity + common region + similarity + connectedness -> make grouping unambiguous.
+- Jakob + consistency + mental models -> preserve predictable behavior.
+- Goal-gradient + Zeigarnik + peak-end -> design progress, resumption, and completion intentionally.
+- Doherty + flow -> keep interaction feedback fast and interruptions low.
+- White space + typography hierarchy + contrast -> establish readable visual hierarchy.
+
+Some principles can conflict:
+
+- Minimalism vs necessary complexity: Tesler wins when hidden complexity harms decisions.
+- Familiarity vs innovation: Jakob wins unless novelty produces a material benefit.
+- Emphasis vs consistency: Von Restorff should create one intentional exception, not a new visual language.
+- Robust input vs security: security constraints override permissive input handling.

package/skills/bizar-uiux/references/review-checklist.md

@@ -0,0 +1,114 @@
+# UI/UX review checklist
+
+Use only the sections relevant to the product and task. This is a review aid, not a requirement to produce findings in every category.
+
+## 1. Primary task and information architecture
+- Can a first-time user identify the screen's purpose within a few seconds?
+- Is one primary action visually and semantically dominant where appropriate?
+- Are navigation labels based on user concepts rather than implementation terminology?
+- Are advanced/rare actions available without competing with the common path?
+- Are related items grouped consistently by spacing, region, alignment, and styling?
+- Does the hierarchy remain clear when content grows, localizes, or wraps?
+
+## 2. Decisions and cognitive load
+- Is the user asked to make more choices than necessary at once?
+- Are defaults safe and meaningful?
+- Can complex choices be filtered, compared, or progressively disclosed?
+- Does the interface require remembering values or instructions from elsewhere?
+- Are labels, values, requirements, and consequences visible at the point of decision?
+
+## 3. Actions and controls
+- Are target sizes and hit areas adequate for pointer and touch?
+- Are frequent actions easy to reach?
+- Are destructive actions separated and clearly distinguished?
+- Do icons have obvious meaning or accessible labels/tooltips where needed?
+- Do controls look interactive and expose disabled/selected/pressed/loading state?
+- Are keyboard focus order and shortcuts coherent?
+
+## 4. Feedback and system state
+- Is there immediate acknowledgment after an action?
+- Are loading, queued, background, partial, success, failure, empty, and offline states handled?
+- Can users tell whether something is saved, synced, selected, running, or complete?
+- Do long operations expose progress or meaningful status rather than appearing frozen?
+- Are repeated submissions prevented or safely idempotent where needed?
+
+## 5. Forms and input
+- Are labels persistent and clear?
+- Are format requirements visible before submission?
+- Is reasonable input variation accepted and normalized safely?
+- Are errors attached to the relevant field and written as recovery instructions?
+- Is entered data preserved after recoverable errors?
+- Are optional fields actually necessary?
+- Are autocomplete, input modes, and platform-native controls used appropriately?
+
+## 6. Visual hierarchy
+- Does typography reveal structure without relying on reading order alone?
+- Is whitespace used to communicate grouping rather than simply increase emptiness?
+- Is contrast sufficient and intentional?
+- Is accent color reserved for meaningful priority/state?
+- Are cards/borders/shadows doing structural work, or just adding visual noise?
+- Does the layout remain balanced without flattening important hierarchy?
+
+## 7. Consistency and familiarity
+- Does the interface follow the host platform's conventions?
+- Are repeated concepts named and represented consistently?
+- Are similar actions placed and styled similarly?
+- Does a redesign preserve useful learned behavior or clearly teach the change?
+- Are custom controls justified over native/design-system primitives?
+
+## 8. Accessibility
+- Can all interactive controls be reached and used with keyboard alone?
+- Is focus visible?
+- Are accessible names, roles, states, headings, and landmarks appropriate?
+- Is color never the only carrier of meaning?
+- Is text/background and UI-component contrast adequate?
+- Does the interface survive 200%+ zoom/reflow where applicable?
+- Is meaningful motion reducible and non-essential?
+- Are touch targets and spacing usable for motor impairments?
+- Do validation and notifications work with assistive technology?
+
+## 9. Responsive/mobile behavior
+- Does priority change appropriately on small screens instead of merely stacking everything?
+- Are touch targets, thumb reach, and gesture discoverability considered?
+- Are sticky controls preventing content access?
+- Are tables, dense filters, and multi-column layouts redesigned rather than squeezed?
+- Does orientation/viewport change preserve state?
+
+## 10. Onboarding and discoverability
+- Can users begin without reading a manual?
+- Is contextual guidance available exactly where uncertainty appears?
+- Is progressive disclosure used for advanced functionality?
+- Are empty states instructional and actionable?
+- Does onboarding teach the core behavior rather than describe features abstractly?
+
+## 11. Progress, completion, and resumption
+- Is meaningful progress visible for multi-step tasks?
+- Can users resume unfinished work?
+- Are final confirmation and next steps clear?
+- Are success screens dead ends, or do they help users continue appropriately?
+- Are drafts/autosave states understandable?
+
+## 12. Error prevention and recovery
+- Can the interface prevent common errors before they happen?
+- Are irreversible/destructive actions proportionately protected?
+- Are undo/retry/recover options available when practical?
+- Are errors specific, local, and actionable?
+- Does the system fail safely under latency, duplicate input, refresh, disconnect, or stale state?
+
+## 13. Review of implementation quality
+- Does the implementation reuse existing design tokens/components?
+- Are one-off CSS values creating design drift?
+- Are semantic HTML and native controls used where suitable?
+- Are interactive states implemented, not just shown in static mockups?
+- Do loading/error/empty states have actual code paths?
+- Are responsive and accessibility behaviors covered by tests or manual verification?
+
+## Final prioritization
+
+Before reporting, ask:
+
+1. Which issue most blocks the user's goal?
+2. Which change removes the most friction for the most common path?
+3. Which issue creates the highest error/accessibility risk?
+4. Which recommendations can share one underlying fix?
+5. Which observations are merely stylistic preference and should be omitted?

package/skills/bizar-uiux/references/sources.md

@@ -0,0 +1,32 @@
+# Canonical skill repository
+
+Standalone source distribution: https://github.com/DrB0rk/Borks-uiux-skill
+
+BizarHarness-OMP includes the skill by default so OMP can discover it from the installed package. The standalone repository is the intended canonical home for the reusable skill itself; Bizar's packaged copy must stay semantically aligned with it.
+
+# Sources and provenance
+
+This skill is an original operational synthesis. It does not reproduce article text, examples, illustrations, or proprietary visual assets from the source sites.
+
+## Laws of UX
+
+- Website: https://lawsofux.com/
+- Creator: Jon Yablonski
+- Scope consulted: the site's current law index and public explanatory pages.
+- The site states that its content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0.
+- Because BizarHarness-OMP is an independently licensed software package, keep this skill to independently worded summaries of general design/psychology principles and attribution. Do not copy the site's prose, examples, diagrams, posters, or branded graphics.
+
+Principles represented in this skill include the site's current index of concepts such as aesthetic-usability effect, choice overload, chunking, cognitive load, Doherty threshold, Fitts's Law, flow, goal-gradient effect, Hick's Law, Jakob's Law, Gestalt grouping principles, mental models, working memory, active-user behavior, Pareto/Parkinson effects, peak-end rule, Postel-style robustness, selective attention, serial-position effects, Tesler's Law, isolation effect, and unfinished-task effects.
+
+## Laws of UI
+
+- Website: https://www.uilaws.com/
+- Scope consulted: the current public law index.
+- The site footer states "All rights reserved."
+- Do not copy its page text or visual assets. This skill independently expresses common UI principles and design practice.
+
+Principles represented from its public index include symmetry, rule of thirds, white space, color theory, typography hierarchy, consistency, proximity, contrast, closure, continuity, Fitts's Law, Hick's Law, and Jakob's Law.
+
+## Evidence discipline
+
+These principles are heuristics, not empirical guarantees for every context. When product analytics, usability tests, accessibility requirements, platform conventions, or direct user research contradict a heuristic, prefer the stronger task-specific evidence.

package/skills/omp-native-development/references/source-manifest.json

@@ -8,7 +8,7 @@
     "tag": "v18.6.1",
     "commit": "2a2c6dcbbb558c0f8145f67f28b3370984f2bf60",
     "npm_integrity": "sha512-UZoZWYUfflDgd0HVDP12X8r4hiYSps7XMf96U7o8ScThAuw6OoI+zBBIypRfTQnzg0QJljpchpa7i0xqCNyXcA==",
-    "qualification": "The unmodified published @oh-my-pi/pi-coding-agent package at 18.6.1 (integrity above) was installed from npm and passed `npm run verify:omp`: packed install, repeat install, native extension discovery, the session-id-keyed ownership lease and profile isolation. Source discovery uses the version-scoped SDK prelude import adapter. The bundled docs/source inventory remains pinned to the research commit below."
+    "qualification": "The unmodified published @oh-my-pi/pi-coding-agent package at 18.6.1 (integrity above) passed the repository's native qualification gate. The bundled docs/source inventory remains pinned to the separate research commit below; runtime and mobile surfaces have their own qualification gates."
   },
   "inspected_target": {
     "tag": "v18.5.0",

package/skills/ponytail/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 DietrichGebert
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/ponytail/SKILL.md

@@ -0,0 +1,119 @@
+---
+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).
+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 in OMP: `/skill: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.

package/skills/ponytail/UPSTREAM.md

@@ -0,0 +1,27 @@
+# Upstream
+
+- Project: Ponytail
+- Repository: https://github.com/DietrichGebert/ponytail
+- Website: https://ponytail.dev/
+- Pinned release: v4.13.0
+- Release commit: 08e952d7a8057a57ce561ff1330d093fd92eec67
+- Imported file: skills/ponytail/SKILL.md
+- License: MIT
+
+The bundled `SKILL.md` is the upstream v4.13.0 skill text. BizarHarness-OMP
+adds activation policy outside the upstream file so the vendored source remains
+auditable against the pin.
+
+To update it, compare the new tagged upstream `skills/ponytail/SKILL.md`,
+review behavior changes, update the pin, and rerun package/skill contract tests.
+Do not track upstream `main` implicitly.
+
+
+## OMP compatibility adaptation
+
+OMP 18.6.1 validates Agent Skills against a closed frontmatter field set:
+`name`, `description`, `license`, `allowed-tools`, `metadata`, and
+`compatibility`. Ponytail v4.13.0 includes `argument-hint`, which is useful
+to some clients but is not part of that OMP skill field set.
+
+The Bizar packaged copy removes that unsupported frontmatter field and changes the documented level command from upstream `/ponytail ...` to OMP's native `/skill:ponytail ...` form. The design rules, name, description, license, and default `full` behavior remain unchanged.