openhermes 4.3.0 → 4.11.2

package/harness/skills/oh-facade/SKILL.md

@@ -1,29 +1,7 @@
 ---
 name: oh-facade
-description: "Full UI pipeline: from concept to production frontend. Design system generation, premium component architecture, production-grade implementation, structured audit. Use when building any user-facing interface, component system, or visual application."
+description: "Full UI pipeline: from concept to production frontend. Design system generation, premium component architecture, production-grade implementation, structured audit."
 tier: 4
-benefits-from: [oh-planner, oh-gauntlet, oh-review]
-triggers:
-  - "build a frontend for"
-  - "create a design system"
-  - "build a landing page"
-  - "build a dashboard"
-  - "build a web app"
-  - "visual design for"
-  - "make this look good"
-  - "redesign this page"
-  - "redesign this app"
-  - "theme the application"
-  - "layout this page"
-  - "responsive layout"
-  - "user interface design"
-  - "improve the UX"
-  - "aesthetic design"
-  - "style the component"
-  - "polish the UI"
-  - "frontend component"
-  - "interface design for"
-  - "build a component for"
 route:
   pass:
     - oh-review
@@ -34,265 +12,23 @@ route:
 
 # oh-facade
 
-The complete UI pipeline: from concept to production frontend. A closed-loop system that plans, designs, builds, verifies, and iterates on user-facing interfaces.
+Full UI pipeline: Concept → Design System → Build → Audit → Iterate.
 
-Architecture of the visible. Engineering, not decoration.
+## Steps
 
-## When to Use
-
-- Building any user-facing interface from scratch
-- Adding a design system to an existing project
-- Redesigning or upgrading existing UIs
-- The task involves anything visual: pages, components, dashboards, themes, layouts
-- `oh-manifest` delegates to `oh-facade` when UI work is detected in a full build
-
-## Pipeline
-
-The 5-phase closed loop:
-
-```
-Concept → Design System → Build → Audit → Iterate
-                                      ↓
-                                 (loop until pass)
-```
-
-Output at each phase: brief → DESIGN.md → code → report → final code.
-
----
-
-## Phase 1: Concept
-
-Input: vague idea, brief, or "make this look good"
-Output: structured design brief with direction
-
-### 1a. Understand the Context
-
-- What is the product/feature? Who uses it?
-- What problem does this interface solve?
-- Are there technical constraints? (framework, viewport targets, accessibility requirements)
-- Is this a new build or an existing project to redesign?
-
-### 1b. Set the Direction
-
-Choose an archetype. **Commit to it. Do not hedge.**
-
-| Archetype | Best for | Substrate | Density |
-|---|---|---|---|
-| Minimal Editorial | Content sites, portfolios, docs | Light (warm off-white) | Low (1-3) |
-| Premium SaaS | Web apps, dashboards, B2B tools | Light or Dark (zinc-based) | Medium (4-7) |
-| Industrial/Data | Analytics, monitoring, internal tools | Dark (charcoal) | High (7-10) |
-| Creative/Expressive | Marketing, agency sites, showcases | Dark or Light | Variable |
-
-### 1c. Set Metric Dials
-
-Three measurable controls that drive all downstream decisions. Default baseline, adapt based on context.
-
-| Dial | Range | 1-3 | 4-7 | 8-10 |
-|---|---|---|---|---|
-| VARIANCE | 1-10 | Symmetric, predictable | Offset, asymmetric | Chaotic, artsy |
-| MOTION | 1-10 | Static, CSS only | Fluid CSS + spring | Cinematic choreography |
-| DENSITY | 1-10 | Gallery, airy | Standard app | Cockpit, packed |
-
-**Default baseline:** VARIANCE=6, MOTION=5, DENSITY=4
-
-### 1d. Output Design Brief
-
-Single paragraph capturing: archetype, substrate (light/dark), metric dials, and key differentiator.
-
-If the brief is clearly wrong or self-contradictory → surface to user.
-Otherwise → Phase 2. Do not ask for approval.
-
----
-
-## Phase 2: Design System
-
-Input: design brief with direction + dials
-Output: `DESIGN.md` — encoded design system as single source of truth
-
-Generate a complete `DESIGN.md` file. This is the blueprint consumed by Phase 3. Every value must be specific — no vagueness, no "use a nice font."
-
-### 2a. Color Palette
-
-- **Neutral base**: Zinc or Slate family. Pick one (warm or cool). Never mix.
-- **Accent**: Exactly one. Saturation < 80%. No purple/blue "AI aesthetic."
-- **Surface**: Background, card, border, elevated. Specific hex codes.
-- **Text**: Primary, secondary, muted, inverse. Specific hex codes.
-- **Semantic**: Success, warning, error, info. Specific hex codes.
-- **Dark substrate**: Never pure `#000000`. Use `#0a0a0a` or `#121212`.
-
-### 2b. Typography Architecture
-
-- **Display/Headline**: Premium sans-serif (Geist, Satoshi, Cabinet Grotesk, Outfit, Switzer). Tight tracking (`-0.03em` to `-0.05em`). Fluid scale via `clamp()`.
-- **Body**: Relaxed leading (`1.6-1.8`). Max 65 characters per line. Off-black, not `#000`.
-- **Monospace**: JetBrains Mono, Geist Mono, or SF Mono. Required for all data/number contexts when DENSITY > 5.
-- **Serif**: Only for editorial/creative contexts and only distinctive modern serifs (Fraunces, Instrument Serif, Editorial New). **Never in dashboards or software UIs.**
-- **BANNED**: Inter, Roboto, Arial, Open Sans, Helvetica, Georgia, Times New Roman.
-
-### 2c. Component System
-
-Define every component with structure, states, and interaction behavior:
-
-**Buttons:**
-- Primary: solid background, off-black or accent. Hover: lift or darken. Active: `scale(0.98)`. Focus ring.
-- Secondary: outline or ghost. Same interaction physics.
-- Icon button: square, matching radius system.
-- Button-in-Button pattern (from high-end-visual-design): nested icon in its own pill inside the button.
-
-**Cards:**
-- Double-Bezel architecture: outer shell (subtle background, hairline border, large radius) + inner core (content background, inset highlight, smaller radius).
-- OR border-only: `border-t` or `divide-y` for high-density contexts.
-- Cards used ONLY when elevation communicates hierarchy. Not as default container.
-
-**Forms/Inputs:**
-- Label above input. Helper text optional. Error text below.
-- Focus state: ring or border color shift.
-- Touch targets: minimum 44px.
-
-**Loading states:**
-- Skeleton loaders matching exact layout dimensions. Never circular spinners.
-
-**Empty states:**
-- Composed illustration or icon, short message, single action button.
-
-**Navigation:**
-- Based on density dial: glass floating pill (low), sidebar (medium/high), or minimal top bar.
-- Active state on current section.
-- Mobile: clean collapse, not hamburger-only.
-
-### 2d. Layout Principles
-
-- **Grid**: CSS Grid. Never `calc()` or flexbox percentage math for multi-column layouts.
-- **Container**: 1200-1440px max-width with auto margins. Wider for editorial/creative archetypes.
-- **Section spacing**: Based on DENSITY dial. Low = `py-32 md:py-48`. Medium = `py-24`. High = `py-16`.
-- **Responsive**: All multi-column layouts collapse to single column below 768px. No exceptions. Verify with `md:` breakpoints.
-- **Full-height**: Always `min-h-[100dvh]`. Never `h-screen` (iOS Safari viewport bug).
-- **BANNED**: centered hero when VARIANCE > 4, 3-equal-card feature rows, edge-to-edge content on wide screens.
-
-### 2e. Motion Philosophy
-
-- **Spring physics**: Default `cubic-bezier(0.32, 0.72, 0, 1)` or Framer Motion `spring(stiffness: 100, damping: 20)`. Never linear easing.
-- **Scroll entry**: Elements fade up gently (`translateY(12-24px)` + `opacity: 0` → resolved over 600-800ms). Use IntersectionObserver or CSS scroll-driven animations. Never `window.addEventListener('scroll')`.
-- **Staggered reveals**: Lists and grids cascade via `animation-delay` or Framer Motion `staggerChildren`.
-- **Hover physics**: Scale, translate, shadow shift, or color transition on interactive elements. Duration 200-300ms.
-- **Active feedback**: Every clickable element must provide tactile response — `scale(0.98)` or `translateY(1px)`.
-- **Performance**: Animate exclusively via `transform` and `opacity`. Never `top`, `left`, `width`, `height`. Use `will-change: transform` sparingly.
-- **Backdrop-blur**: Only on fixed/sticky elements (navbars, overlays). Never on scrolling containers.
-
-### 2f. Anti-Patterns Registry
-
-Explicit rules encoded into DESIGN.md. These are hard failures.
-
-- No emojis in code, content, alt text, or markup
-- No `Lorem Ipsum` — write real draft copy
-- No "Elevate", "Seamless", "Next-Gen", "Unleash", "Game-changer" copy
-- No generic names (John Doe, Acme Corp) — use realistic, specific content
-- No rocket ship for "launch" or shield for "security" icons
-- No purple/blue neon gradients
-- No dark section in a white page (or vice versa) without committed dark mode
-- No animated `top`, `left`, `width`, `height`
-- No `window.addEventListener('scroll')`
-- No `h-screen` for full-height sections
-
----
-
-## Phase 3: Build
-
-Input: DESIGN.md
-Output: production code implementing the full system
-
-### 3a. Set Up Foundations
-
-1. CSS custom properties for colors, spacing, typography scale, shadows, border-radii
-2. Tailwind config extensions (if using Tailwind) — map design tokens to utility classes
-3. Theme provider or global stylesheet
-4. Component directory structure
-
-### 3b. Build Component Library
-
-Implement every component defined in Phase 2 with ALL states:
-- Default, hover, active, focus-visible, disabled
-- Loading (skeleton matching layout)
-- Empty (composed illustration + message + action)
-- Error (inline messaging)
-
-Apply performance guardrails to every component:
-- Animations use `transform` and `opacity` only
-- No layout-triggering properties in transitions
-- `backdrop-blur` only on fixed/sticky elements
-- Z-index follows systemic scale (no arbitrary `z-50` or `z-[9999]`)
-
-### 3c. Build Pages/Screens
-
-1. Implement the full interface using the component system
-2. Responsive: verify single-column collapse below 768px
-3. All viewports filled: loading → populated → empty → error states
-4. Navigation wired with active states and mobile collapse
-
-### 3d. Technical Requirements
-
-- Check `package.json` before importing any dependency. Never assume a library exists.
-- Use framework-appropriate patterns: Server Components in Next.js, client isolation for interactive islands
-- Semantic HTML: `<nav>`, `<main>`, `<section>`, `<article>`, `<aside>`, `<header>`, `<footer>`
-- Accessibility: visible focus rings, skip-to-content link, alt text, aria labels on interactive elements
-- Meta tags: `<title>`, `description`, `og:image`, viewport
-
----
-
-## Phase 4: Audit
-
-Input: built code + DESIGN.md
-Output: audit report with pass/fail per check + ranked fix list
-
-Run the full structured audit. Checks are grouped and priority-ranked.
-
-### Priority 1 — High Impact, Low Risk (do first)
-
-- **Typography**: font choice matches DESIGN.md? scale correct? tracking applied? no orphan lines? body max-width limited?
-- **Color**: single accent? saturation < 80%? no AI purple? warm/cool consistent? dark not pure black?
-- **Layout**: grid not flexbox math? max-width container? `min-h-[100dvh]` everywhere? responsive at 768px?
-
-### Priority 2 — Makes it Feel Alive
-
-- **Interactivity**: hover states on all clickables? active feedback (`scale(0.98)` or translate)? focus rings? transitions smooth (200-300ms)?
-- **States**: every component has loading, empty, error states? skeleton loaders (not spinners)?
-- **Motion**: scroll entry animations present? staggered reveals? spring physics (not linear)?
-
-### Priority 3 — Content Polish
-
-- **Content**: no lorem ipsum? no cliche copy? realistic names and data? no generic placeholders?
-- **Emojis**: zero emojis in code or content?
-- **Anti-patterns**: no "Elevate", no rocket icons, no purple gradients?
-
-### Priority 4 — Production Hardening
-
-- **Components**: Double-Bezel or appropriate card architecture? button-in-button pattern where applicable? navigation active states?
-- **Iconography**: consistent stroke width? no default library? no emoji substitutions?
-- **Code quality**: semantic HTML? no div soup? no inline styles? no orphaned imports?
-- **Strategic**: 404 page? skip-to-content? meta tags? cookie consent consideration?
-
-### Phase 5: Iterate
-
-1. Apply fixes in Priority order — do not skip ahead
-2. Re-run audit after each priority level
-3. Continue until all Priority 1-3 checks pass
-4. Priority 4 is target-state — surface remaining items as recommendations
-5. If blocked on a specific check → narrow scope, try alternative approach, or surface
-
-## Design Principles
-
-These govern all decisions across all phases:
-
-1. **Intentionality over intensity** — Bold maximalism and refined minimalism both work. The key is commitment to a direction, not how loud it is.
-2. **Engineering over decoration** — A button is not "styled" — it has a physical structure, interaction physics, and accessible states.
-3. **Consistency over variety** — One palette, one font system, one component architecture. Consistency beats every single creative choice.
-4. **Performance is a feature** — A beautiful UI that lags is not a beautiful UI. Hardware acceleration, transform-only animation, guarded backdrop-blur.
-5. **Ship every state** — Default-only is not production. Loading, empty, error, hover, active, focus, disabled. Every state designed and implemented.
+1. Scan existing codebase — detect framework, styling, current patterns. For redesigns, run phase 0 diagnosis first.
+2. Establish direction — collect product/user/problem context, commit to one archetype (Warm Minimalist, Premium SaaS, Industrial Brutalist, Creative/Expressive), set metric dials (VARIANCE, MOTION, DENSITY).
+3. Produce DESIGN.md — define color tokens (neutral/accent/surface/text/semantic/dark), typography stack (display/body/mono/serif), component specs, layout grid, and motion rules.
+4. Build foundations — CSS custom properties, Tailwind config extensions, theme provider, component directory.
+5. Implement component library — all components with every state: default, hover, active, focus-visible, disabled, loading, empty, error.
+6. Assemble pages — full interfaces from components, responsive collapse at 768px, all viewport states (loading → populated → empty → error).
+7. Run priority-ranked audit — P1 (typography/color/layout), P2 (interactivity/states/motion), P3 (content quality), P4 (hardening/a11y), P5 (existing-project redesign scan).
+8. Iterate — fix highest-priority failures first, re-audit after each level, surface blocker if fix impossible.
 
 ## Routing
 
 | Outcome | Route |
-|---|---|
-| all phases pass | -> oh-review (design review) or back to oh-manifest |
-| audit fails Priority 1-2 | -> Phase 5 (iterate — fix and re-audit) |
-| audit fails Priority 3-4 only | -> Phase 5 (recommendations), route to oh-review |
-| blocker | -> surface to user |
+|---------|-------|
+| pass | → oh-review or oh-manifest |
+| fail | → oh-facade |
+| blocker | → surface |

package/harness/skills/oh-freeze/DEEP.md

@@ -0,0 +1,18 @@
+# oh-freeze — Deep Reference
+
+## When to Use
+
+When the user says "don't touch anything outside [path]" or "only edit files in [dir]." Prevents accidental edits to configuration, infrastructure, or unrelated modules.
+
+## Mode
+
+- Allowed paths: only the specified directory and its children
+- If you need to edit outside: state the reason and ask
+- Read operations unrestricted anywhere
+- File creation restricted to allowed paths
+
+## Anti-patterns
+
+- Editing outside allowed path without asking
+- Reading unrelated files for context and using that to justify edits
+- "Just this one file outside" — ask first

package/harness/skills/oh-freeze/SKILL.md

@@ -1,11 +1,7 @@
 ---
 name: oh-freeze
-description: "Restrict file edits to a specific directory for the session"
+description: "Restricts file edits to a specific directory for the session."
 tier: 2
-triggers:
-  - "freeze directory"
-  - "restrict edits to"
-  - "lock edits to"
 route:
   pass: mode
   fail: mode
@@ -14,24 +10,19 @@ route:
 
 # oh-freeze
 
-## When to Use
-When debugging a specific module and you want to prevent accidentally "fixing" unrelated code. Scopes all Edit/Write operations to one directory.
+Restrict write operations to one allowed directory.
 
-## Workflow
-1. Specify target directory to freeze
-2. All Edit/Write operations outside that directory are blocked
-3. User can explicitly approve cross-boundary edits
-4. Unfreeze to release the boundary
+## Steps
 
-## Anti-patterns
-- Freezing too broadly (defeats the purpose)
-- Forgetting to unfreeze when task scope expands
-- Using freeze as a substitute for git discipline
+1. Identify the allowed directory from user instructions
+2. Restrict all write/edit/create operations to the allowed path
+3. Allow read operations unrestricted anywhere
+4. If a write outside the allowed path is required, state the reason and ask before proceeding
 
 ## Routing
 
 | Outcome | Route |
 |---------|-------|
-| pass | → [return to prior skill — scope lock active] |
-| fail | → [surface issue — freeze not applied] |
-| blocker | → surface to user |
+| pass | → mode |
+| fail | → mode |
+| blocker | → surface |

package/harness/skills/oh-full-output/DEEP.md

@@ -0,0 +1,25 @@
+# oh-full-output — Deep Reference
+
+## When to Use
+
+When generating long files, multi-component output, or any task where partial output would be a broken deliverable.
+
+## Banned Patterns (Hard Failures)
+
+**Code:** `// ...`, `// rest of code`, `// implement here`, `// TODO`, `/* ... */`, `// similar`, `// continue`, `// same as`, bare `...`.
+
+**Prose:** "let me know if you want me to continue", "for brevity", "the rest follows the same pattern", "and so on", "I'll leave that as an exercise".
+
+**Structural:** Skeleton instead of full impl. First/last sections skipping middle. One example + description for repeated logic. Describing instead of writing.
+
+## Long Outputs
+
+When approaching token limit:
+- Write at full quality to a clean breakpoint (end of function/file/section)
+- Do NOT compress remaining sections
+- End with: `[PAUSED — X of Y complete. Send "continue" to resume from: next section name]`
+- On "continue": pick up exactly where stopped. No recap.
+
+## Quick Check
+
+Before finalizing: no banned patterns, every item present and finished, code blocks contain runnable code, nothing shortened.

package/harness/skills/oh-full-output/SKILL.md

@@ -1,81 +1,28 @@
 ---
 name: oh-full-output
-description: "Override LLM truncation behavior. Enforce complete code generation, ban placeholder patterns (// ..., /* ... */, TODO, 'rest of code'), and handle token-limit splits cleanly. Use when generating long files, multi-component output, or any task where partial output would be a broken deliverable."
+description: "Override LLM truncation — enforce complete code generation, ban placeholders."
 tier: 2
-triggers:
-  - "full output"
-  - "complete code"
-  - "no truncation"
-  - "dont skip"
-  - "no placeholders"
-  - "banned patterns"
-  - "generate everything"
-  - "dont abbreviate"
-  - "dont use ..."
-  - "no etc"
-  - "write it all"
-  - "exhaustive"
-  - "unabridged"
-  - "long file"
-  - "large output"
-  - "many files"
-  - "all components"
-  - "stop truncating"
 route:
   pass: done
-  fail: surface
+  fail: [surface, oh-expert]
   blocker: surface
 ---
 
 # oh-full-output
 
-Override default LLM truncation behavior. Enforce complete generation, ban placeholder patterns, and handle token-limit splits cleanly.
+Override truncation. Enforce complete generation. Ban placeholders.
 
-## Baseline
+## Steps
 
-Treat every task as production-critical. A partial output is a broken output. Do not optimize for brevity -- optimize for completeness. If the user asks for a full file, deliver the full file. If the user asks for 5 components, deliver 5 components. No exceptions.
-
-## Banned Output Patterns
-
-The following patterns are hard failures. Never produce them:
-
-**In code blocks:** `// ...`, `// rest of code`, `// implement here`, `// TODO`, `/* ... */`, `// similar to above`, `// continue pattern`, `// add more as needed`, bare `...` standing in for omitted code, `// same as above`
-
-**In prose:** "Let me know if you want me to continue", "I can provide more details if needed", "for brevity", "the rest follows the same pattern", "similarly for the remaining", "and so on" (when replacing actual content), "I'll leave that as an exercise"
-
-**Structural shortcuts:** Outputting a skeleton when the request was for a full implementation. Showing the first and last section while skipping the middle. Replacing repeated logic with one example and a description. Describing what code should do instead of writing it.
-
-## Execution Process
-
-1. **Scope** -- Read the full request. Count how many distinct deliverables are expected (files, functions, sections, answers). Lock that number.
-2. **Build** -- Generate every deliverable completely. No partial drafts, no "you can extend this later."
-3. **Cross-check** -- Before output, re-read the original request. Compare your deliverable count against the scope count. If anything is missing, add it before responding.
-
-## Handling Long Outputs
-
-When a response approaches the token limit:
-
-- Do not compress remaining sections to squeeze them in.
-- Do not skip ahead to a conclusion.
-- Write at full quality up to a clean breakpoint (end of a function, end of a file, end of a section).
-- End with:
-  ```
-  [PAUSED -- X of Y complete. Send "continue" to resume from: next section name]
-  ```
-- On "continue", pick up exactly where you stopped. No recap, no repetition.
-
-## Quick Check
-
-Before finalizing any response:
-- No banned patterns from the list above appear anywhere in the output
-- Every item the user requested is present and finished
-- Code blocks contain actual runnable code, not descriptions of what code would do
-- Nothing was shortened to save space
+1. Scope — Count distinct deliverables. Lock the number.
+2. Build — Generate every deliverable completely. No partial drafts.
+3. Cross-check — Re-read request. Compare deliverable count. Add anything missing.
+4. Verify — No banned patterns, every item present, code blocks are runnable, nothing shortened.
 
 ## Routing
 
 | Outcome | Route |
-|---|---|
-| pass | -> continue current task |
-| truncation still happens | -> oh-expert (diagnose attention/context issues) |
-| blocker | -> surface to user |
+|---------|-------|
+| pass | → done |
+| fail | → surface, oh-expert |
+| blocker | → surface |

package/harness/skills/oh-fusion/DEEP.md

@@ -0,0 +1,120 @@
+# oh-fusion — Deep Reference
+
+## When to Use
+
+Use when a user wants to bring an external skill or capability into the OpenHermes harness as an OH-native skill.
+
+## Phase 1: Discovery
+
+| Source | Access |
+|--------|--------|
+| `.agents/skills/<name>/SKILL.md` | Read file |
+| `npx skills` package | `npx skills find <query>` |
+| URL | Fetch content |
+| User path | Resolve and read |
+| Inline text | Capture raw |
+
+Confirm: content loaded, frontmatter present, no access restrictions. For multiple: all loaded.
+
+## Phase 2: Analysis
+
+### Depth Scoring
+| Metric | Assessment |
+|--------|-----------|
+| Lines | SKILL.md length |
+| Concrete rules | "must/never/always/banned" count |
+| Examples | Before/after or usage code blocks |
+| Anti-patterns | Explicit "don't" sections |
+| Workflow steps | Sequential, actionable steps |
+| Routing table | pass/fail/blocker defined |
+
+**Score:** High (70-100) = concrete + examples + routing. Medium (30-69) = some structure. Low (0-29) = vague, no rules.
+
+### Overlap Detection
+Compare against existing `harness/skills/oh-*` skills. Overlap: none / partial (complementary) / complete (redundant).
+
+### Convention Check
+- Clear description for triggering? Actionable instructions? Anti-patterns? Examples? Measurable outcomes? No time-sensitive refs? No platform assumptions?
+
+### Report Template
+```markdown
+**Depth:** <0-100> — <High/Medium/Low>
+**Overlap:** <existing skill> — <none/partial/complete>
+**Verdict:** <keep / fuse / discard / ask>
+**Action:** <port directly / fuse with X / discard>
+```
+
+## Phase 3: Decision
+
+| Verdict | Action |
+|---------|--------|
+| Keep | High signal, no overlap. Port to `oh-<name>`. |
+| Fuse | Partial overlap with existing. Merge complementary DNA. |
+| Discard | Low signal or complete overlap. Surface reasoning. |
+| Ask | Ambiguous quality. Surface findings. |
+
+When in doubt: prefer fuse over keep, keep over discard if ANY unique signal.
+
+## Phase 4: Adaptation
+
+### Frontmatter
+```yaml
+name: oh-<name>
+description: "Adapted from <source>. Core function. Use when ..."
+tier: <2|3|4>
+```
+
+### Body Structure
+1. **Summary** — one-paragraph of what the skill does
+2. **When to Use** — clear triggering context
+3. **Workflow** — numbered steps (the core)
+4. **Anti-patterns** — what NOT to do
+5. **Routing** — pass/fail/blocker table
+
+### Adaptation Rules
+- Remove emojis. Replace ecosystem terms with OH equivalents.
+- Convert relative paths to OH harness conventions.
+- Add routing table based on the skill's purpose.
+- Keep all concrete rules, examples, and anti-patterns from the original.
+- Discard fluff, philosophy, and motivational language.
+- Preserve the original's unique signal — that's why you're importing it.
+
+### Naming
+Match `^[a-z0-9]+(-[a-z0-9]+)*$`, prefix `oh-`. Original name if good fit, adapt if not. Fusion names signal combined purpose.
+
+## Phase 5: Fusion (opt — skip for single imports)
+
+For each skill being fused, identify:
+- **Unique concepts** — content only this skill has
+- **Overlapping content** — same idea expressed differently (keep the better version)
+- **Conflicting directives** — skills that say opposite things (surface to user)
+
+### Merge Architecture
+Structure so each source contributes its strength. Do NOT concatenate — must read as one coherent workflow, not three documents glued together.
+
+```markdown
+## Combined Workflow
+### Phase A: <from skill 1>
+### Phase B: <from skill 2>
+```
+
+### Naming
+Name signals combined purpose, not individual sources. E.g., `oh-facade` from redesign + design-taste + high-end-visual, not `oh-redesign-plus-taste`.
+
+## Phase 6: Integration
+
+1. **Create file** → user dir (`~/.config/opencode/skills/oh-<name>/SKILL.md`)
+2. **Wire AUTOPILOT** → add to auto-classify matrix in `harness/codex/AUTOPILOT.md`: signal keywords → classification → "Load **oh-<name>**. Do not ask."
+3. **Wire routing** → add `route:` frontmatter in the skill. Dynamic loading reads `route.pass`, `route.fail`, `route.blocker` directly from `SKILL.md` — no ROUTING.md edit needed. Skill becomes routable automatically.
+4. **Wire AGENTS.md** → add to skills table with tier and purpose. Increment total count.
+5. **Wire openhermes.md** → add to orchestrator's skill list in `harness/agents/openhermes.md`.
+6. **Verify** → route to `oh-skills-link` to confirm OpenCode discovers it.
+
+## Anti-patterns
+
+- Importing without analysis (always run Phase 2)
+- Keeping everything — ~50% of external skills is fluff
+- Fusing incompatible domains (confusing to model and user)
+- Naming after source ("oh-tailwind-v2") instead of capability ("oh-styles")
+- Skipping route frontmatter — without it, autopilot can't route
+- Overwriting existing routing without checking for collisions