# Agent Skill Bundle — Humanize Loop

> Generated from the canonical public Skill source. This bundle is an invocation artifact, not a separate editable source.

## Agent instruction

Apply this Skill to the user’s actual task. Follow its inputs, behavior, guardrails, outputs, and verification criteria. Do not merely explain or summarize the Skill. If required task context is missing, ask only for the missing information that blocks correct execution.

## Skill identity

- source: skills/humanize-loop
- canonical human page: https://personal-ai-ops.vercel.app/wbeen/skills/humanize-loop/
- version: 0.1.0
- workflow phase: execute
- invocation: either

## Skill contract

Keep humanization in the UI build loop by deciding when intervention is needed and routing each moment to the smallest appropriate anti-slop specialist.

### Inputs

- Current UI task or implementation state
- Existing design system, product intent, information architecture, and interaction constraints
- Lifecycle moment such as start, build, checkpoint, repair, rescue, ship, or study
- Available Humanizers and any explicit user preference

### Outputs

- Intervention decision, including none when appropriate
- One primary Humanizer route at most
- One validator route at most when verification adds value
- Bounded repair, redesign, research, or verification guidance
- Residual issues and stop condition

### Guardrails

- Route, don't pile; do not load or invoke every Humanizer by default.
- Existing product intent, design system, information architecture, accessibility, responsiveness, and behavior outrank an external Humanizer's stylistic preferences.
- Diagnose before structural redesign and use the minimum sufficient intervention.
- Do not invent testimonials, customers, metrics, avatars, screenshots, or other authenticity signals.
- Do not claim that an external Humanizer ran when it was only referenced or unavailable.
- Do not automatically install or update third-party Humanizers.
- Avoid turning anti-slop taste into a new generic aesthetic monoculture.

### Verification

- The selected route matches the surface, lifecycle moment, problem depth, and available runtime.
- No more than one primary Humanizer and one validator are selected by default.
- Existing behavior, accessibility, responsive states, and product constraints are preserved unless explicitly changed.
- Material generated-looking patterns are addressed without treating preference-level differences as defects.
- The pass stops when remaining differences are preference-level or intervention is unnecessary.

### Source instructions

## What it does

Humanize Loop keeps **humanization inside the UI development loop** instead of treating AI-slop as a final cosmetic cleanup. Its internal routing layer is the **Switchboard**: a small control plane that decides whether intervention is needed, what depth is appropriate, which specialist fits the moment, whether a validator is useful, and when to stop.

The operating rule is **route, don't pile**. The default ceiling is one primary Humanizer and at most one validator. If the interface is already intentional and fit for purpose, `intervention: none` is a successful outcome.

## When to reach for it

Use it when AI-assisted frontend work needs deliberate design judgment at the start, during implementation, at a checkpoint, during repair/rescue, or before shipping. It is most useful when “this looks AI-generated” is too vague to justify a redesign by itself.

The Switchboard first preserves the product context, then classifies the surface, lifecycle moment, problem depth, and minimum useful intervention. A product dashboard, a marketing page, a small component, and a structural rescue should not automatically receive the same Humanizer.

## What one run does

1. Inspect existing product intent, design tokens, components, IA, responsive behavior, and accessibility constraints.
2. Decide whether humanization is materially needed.
3. Classify the UI context and deepest relevant problem.
4. Select the smallest appropriate intervention and at most one primary specialist.
5. Add one validator only when a separate verification pass is useful.
6. Preserve intentional patterns and stop before preference-level polishing becomes churn.

External Humanizers remain independent tools or services. Humanize Loop may route to them when they are already available, but it does not silently install, update, vendor, or pretend to have executed them.

## Common failure modes

- Treating every gradient, card, rounded corner, or familiar pattern as proof of AI slop.
- Loading several taste systems at once and producing contradictory redesign pressure.
- Letting an external Humanizer overwrite an established product system.
- Escalating a cosmetic or compositional issue into a structural redesign without diagnosis.
- Replacing generic AI defaults with an equally generic “tasteful minimal” house style.
- Reporting fake precision such as a numeric “human score.”

## It’s working if

The UI has fewer material generated-looking defaults while still feeling like the same product. The intervention is explainable, bounded, and matched to the task; existing behavior and usability remain intact; and the process can explicitly conclude that no further humanization is necessary.

## Where it fits

Humanize Loop is primarily an **Execute**-phase operating skill, but it intentionally spans the UI lifecycle from prevention through final verification. PAOS publishes this as an editorial capability description, not as an executable Skill marketplace entry or a mirror of the private Skill Registry.

## Completion rule

Return the useful task result first. Then state briefly which verification criteria passed, which could not be checked, and any stop/escalation condition that remains.