@jaimevalasek/aioson 1.4.0 → 1.6.0

package/template/.aioson/skills/process/design-hybrid-forge/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: design-hybrid-forge
+description: Process skill that creates project-local hybrid design skills by fusing exactly two primary AIOSON design skills, with optional limited modifiers. When activated, guides you through pair selection, identity synthesis, crossover spec, skill generation, preview creation, metadata, and optional promotion.
+activation: |
+  You are now running the design-hybrid-forge process. Begin by asking the user for the names of the two primary AIOSON design skills they want to combine, then ask whether they want optional modifiers. Use up to two modifiers by default, or up to three only when the active variation preset or the user explicitly enables advanced mode. Follow the phases described in this skill.
+---
+
+# Skill: design-hybrid-forge
+
+> Process skill. Creates new hybrid design skills by fusing DNA from two existing AIOSON design skills.
+> Load this file first. Then load only the `references/` file you need for your current phase.
+
+## What this skill produces
+
+A complete, production-quality hybrid design skill package for the current project:
+
+```
+.aioson/installed-skills/{hybrid-name}/
+  SKILL.md
+  .skill-meta.json
+  references/
+    art-direction.md
+    design-tokens.md
+    components.md
+    patterns.md
+    dashboards.md
+    websites.md
+    motion.md
+  previews/
+    {hybrid-name}.html
+    {hybrid-name}-website.html
+```
+
+If tool-native skill folders exist, the finished package may also be mirrored to:
+
+```
+.claude/skills/{hybrid-name}/
+.cursor/skills/{hybrid-name}/
+.windsurf/skills/{hybrid-name}/
+```
+
+## When to load
+
+Load this skill when:
+- You want to create a new hybrid design skill from two base skills
+- You are planning this week's hybrid (pair selection phase)
+- You are executing the crossover (generation phase)
+- You need to validate a hybrid before shipping
+- You want an anti-sameness variation overlay for a more extravagant, classic, animated, or CSS-advanced result
+
+Do NOT load this skill to apply a design skill to a project. Use the target hybrid's own SKILL.md for that.
+
+## Output modes
+
+### 1. Project-local installed skill (default)
+
+Use this mode in normal AIOSON projects.
+
+- Writes the new hybrid to `.aioson/installed-skills/{hybrid-name}/`
+- Keeps the skill versioned with the project
+- Generates local previews inside the skill folder
+- Records author / generator metadata in `.skill-meta.json`
+- Does not touch AIOSON core galleries or first-party skill folders
+
+### 2. Core promotion (optional)
+
+Use this mode only when the user explicitly wants to propose the hybrid back to AIOSON core or marketplace curation.
+
+- Starts from an already-generated project-local skill
+- Prepares promotion artifacts for `.aioson/skills/design/{hybrid-name}/`
+- Updates gallery / registry files only in the core repo
+- Must stay a separate step from project-local generation
+
+## Process overview
+
+| Phase | What happens | Produces |
+|---|---|---|
+| **1. Pair Selection** | Choose 2 primary skills with creative tension | Chosen pair + rationale |
+| **2. Identity Synthesis** | Name, 3 pillars, accent fusion, substrate | Hybrid identity doc (in conversation) |
+| **3. Crossover Spec** | Define DNA from A, DNA from B, optional modifiers, new elements | Crossover map (in conversation) |
+| **4. Skill Generation** | Write SKILL.md + 7 reference files + metadata | Skill package |
+| **5. Preview Generation** | Write dashboard HTML + landing HTML inside the skill package | 2 `.html` files |
+| **6. Distribution** | Register in `AGENTS.md` and mirror to tool-native skill folders if present | Tool-ready copies |
+| **7. Optional Promotion** | Prepare for core/gallery/marketplace only if requested | Promotion bundle |
+
+Each phase must complete before the next begins. Do not skip phase 2 and 3 — they are what makes the hybrid coherent rather than a random blend.
+
+## Input contract
+
+```
+primary_a: {skill-name}            # e.g. "cognitive-core-ui"
+primary_b: {skill-name}            # e.g. "glassmorphism-ui"
+modifiers: {optional 0..2}         # e.g. ["bold-editorial-ui"]
+variation_overlay: {optional}      # selected via conversation or `aioson design-hybrid:options`
+modifier_policy: {optional}        # "up_to_2_modifiers" by default, "up_to_3_modifiers" in advanced mode
+name_suggestion: {optional}        # e.g. "aurora-command-ui" or leave blank
+target_domain: {optional}          # e.g. "SOC platform" — narrows expression modes
+author_name: {optional}            # e.g. "Jaime" or "ACME Design Team"
+generator_model: {optional}        # fill if the runtime/tool exposes it
+```
+
+## Output contract
+
+The hybrid must satisfy ALL of the following:
+- 8 files (SKILL.md + 7 references) with full content — no placeholders
+- 1 metadata file: `.skill-meta.json`
+- 2 HTML previews: dashboard (operational) + landing page (marketing)
+- A name that is original and not a concatenation of the parent names
+- A new accent that is NOT identical to either parent's accent
+- A substrate rule that is clearly stated and non-negotiable
+- At minimum 5 expression modes in art-direction.md
+- At minimum 20 components in components.md
+- Exactly 2 primary parents
+- At most 2 optional modifiers with limited scope by default
+- Up to 3 modifiers only when advanced mode is explicitly enabled
+- A single coherent visual system that can be selected as one `design_skill`
+- Metadata that records authorship and generator/model details when available
+- When a variation overlay exists, the generated skill and previews must visibly express it
+- When a temporary variation preset exists, it must be archived or removed from active context after successful generation
+
+## References available
+
+| File | Load when |
+|---|---|
+| `references/pair-compatibility.md` | Choosing which two skills to combine this week |
+| `references/crossover-protocol.md` | Running phases 2 and 3 (identity + crossover spec) |
+| `references/variation-library.md` | Choosing a variation overlay or anti-sameness directions |
+| `references/output-contract.md` | Running phases 4 and 5 (file generation) |
+| `references/naming-registry.md` | Naming the hybrid and checking for conflicts |
+| `references/quality-gates.md` | Validating the hybrid before shipping (distribution / promotion gates) |
+
+## Non-negotiable rules
+
+1. Exactly 2 primary parents are required. Never generate a hybrid with 3 or 4 co-equal parents.
+2. Optional modifiers are capped at 2 by default. A 3rd modifier is allowed only in advanced mode and still cannot own substrate or structure.
+3. The hybrid must have its own identity — not "A with B colors" but a third thing.
+4. The crossover spec must be explicit: what comes from each primary parent, what modifiers influence, and what is new.
+5. The accent must be a genuine fusion — not parent A's accent, not parent B's. A new value or gradient pair.
+6. The substrate rule is always the first decision. One primary parent wins the background model.
+7. The hybrid's SKILL.md must explicitly name its parents in a `## Hybrid DNA` section.
+8. Never combine two primary skills from the same family (e.g. cognitive-core + premium-command = too similar).
+9. Every hybrid ships with both previews and a `.skill-meta.json`. No preview = not done.
+10. Project-local generation goes to `.aioson/installed-skills/` by default. Promotion to core is a separate, explicit step.
+11. `design-hybrid:options` creates a temporary preset in `.aioson/context/design-variation-preset.md`; after successful generation, archive or remove the active preset and preserve the history snapshot.

package/template/.aioson/skills/process/design-hybrid-forge/references/crossover-protocol.md

@@ -0,0 +1,221 @@
+# Crossover Protocol — design-hybrid-forge
+
+Load when running Phase 2 (Identity Synthesis) and Phase 3 (Crossover Spec).
+
+This is the methodological core of the forge. Follow it in order. Do not skip to generation.
+
+---
+
+## Phase 2 — Identity Synthesis
+
+Before writing a single file, answer all six questions. If you cannot answer them, you are not ready to generate.
+
+### 2.1 Name the creative tension
+
+Write one sentence naming what the two skills pull against each other.
+
+Example:
+> "cognitive-core-ui pulls toward dense operational precision and solid surfaces; glassmorphism-ui pulls toward fluid depth through transparency. The hybrid resolves this by making the command structure live inside a glass aurora — precision without opacity."
+
+If the sentence feels like a compromise ("both are dark and professional"), the pair is too similar. Pick a different pair or articulate a sharper tension.
+
+### 2.2 Decide the substrate winner
+
+The background system of the hybrid belongs to exactly ONE parent. Never split this 50/50.
+
+Ask: which parent's background model is more distinctive and harder to achieve without the other?
+- If parent A uses a gradient substrate (glassmorphism, premium-command) and parent B uses solid backgrounds → gradient substrate wins.
+- If both use solid backgrounds → the one with the stronger depth model wins.
+- If both use gradient substrates → this pair may be too similar (check anti-pairs).
+
+Document the substrate winner and the exact CSS value.
+
+### 2.3 Decide the structure winner
+
+The layout architecture and information density rules belong to exactly ONE parent.
+
+Ask: which parent has a more opinionated information structure?
+- mono rails → cognitive-core wins
+- editorial sections → bold-editorial wins
+- raw grid → neo-brutalist wins
+- balanced/neutral → the other parent's structure can fill in
+
+Document the structure winner and what it contributes concretely (layout, rhythm, navigation pattern, density scale).
+
+### 2.4 Design the accent fusion
+
+The hybrid's accent must be genuinely new. Rules:
+- NOT parent A's accent color
+- NOT parent B's accent color
+- Usually a gradient pair where each endpoint references one parent
+- Sometimes a completely new color at the midpoint between the two parent accents
+- The gradient pair is the hybrid's strongest visual signature
+
+Document the primary accent, secondary accent, gradient, and at least one glow/shadow value derived from it.
+
+**Method — midpoint derivation:**
+1. Get parent A's accent in HSL
+2. Get parent B's accent in HSL
+3. The hybrid's primary can be the H/S/L midpoint, or a deliberate shift toward the more distinctive one
+4. The gradient goes from primary → secondary (A-derived → B-derived)
+
+**Example (cognitive-core × glassmorphism):**
+- cognitive-core accent: `#22D3EE` (teal, H=190)
+- glassmorphism accent: `#7C3AED` (violet, H=263)
+- midpoint H ≈ 226 (blue) — but this is bland
+- chosen: shift toward teal → `#00C8E8` (electric teal) + keep violet as gradient endpoint
+- result: `linear-gradient(135deg, #00C8E8, #7C3AED)` — teal-electric × violet
+
+### 2.5 Name the hybrid
+
+Requirements:
+- 2–3 word compound noun or adjective + noun
+- Must NOT be a concatenation of parent names (not "glass-core" or "warm-brutalist")
+- Must evoke the resolved tension — what the interface *feels like*, not what it's made of
+- Should be memorable and suggest a specific vibe
+
+**Naming patterns:**
+| Pattern | Example |
+|---|---|
+| Material + Role | `aurora-command`, `crystal-forge`, `void-craft` |
+| Texture + Purpose | `warm-terminal`, `raw-glass`, `cold-editorial` |
+| Atmosphere + Function | `dusk-ops`, `ember-dashboard`, `frost-bureau` |
+| Poetic compound | `eclipse-ui`, `obsidian-core`, `solar-canvas` |
+
+After naming: confirm it is not in `naming-registry.md`. If taken, iterate.
+
+### 2.6 Write the three pillars
+
+Every AIOSON design skill defines its identity through three pillars. Write them for the hybrid now, before generating any file.
+
+Each pillar is a short paragraph (3–5 sentences) describing one non-negotiable visual principle. The three must be distinct and together tell the full story of the hybrid.
+
+Structure:
+```
+1. [Substrate + surface model] — how depth is created
+2. [Structure + rhythm model] — how information is organized
+3. [Accent + signature model] — what the eye remembers
+```
+
+If you can't write three distinct, non-overlapping pillars, the hybrid doesn't have a clear enough identity. Revise the crossover spec before generating.
+
+### 2.7 Optional modifier ownership
+
+If the user selected modifier skills, assign each one a narrow lane.
+
+Allowed modifier lanes:
+- accent refinement
+- motion language
+- landing-page / website composition
+- one small component family
+
+Forbidden modifier lanes:
+- substrate / background model
+- layout structure
+- density default
+- navigation architecture
+
+If you cannot describe the modifier contribution in one short sentence, drop the modifier.
+
+---
+
+## Phase 3 — Crossover Spec
+
+A crossover spec is a table mapping every design dimension to its source.
+
+### 3.1 Dimension map
+
+Fill in this table for the chosen pair:
+
+| Dimension | Source | Value / Rule |
+|---|---|---|
+| Background model | A or B | e.g. "gradient substrate from glassmorphism" |
+| Surface treatment | A or B or NEW | e.g. "dark-tinted glass from hybrid" |
+| Layout system | A or B | e.g. "command shell from cognitive-core" |
+| Navigation pattern | A or B | e.g. "topbar + sidebar from cognitive-core" |
+| Typography | A or B or NEW | e.g. "Inter + JetBrains Mono from cognitive-core" |
+| Heading scale | A or B | e.g. "bold headings from cognitive-core" |
+| Accent primary | NEW | e.g. "#00C8E8 teal-electric" |
+| Accent secondary | NEW | e.g. "#7C3AED violet" |
+| Accent gradient | NEW | e.g. "linear-gradient(135deg, #00C8E8, #7C3AED)" |
+| Depth model | A, B, or NEW | e.g. "blur-based layers from glassmorphism" |
+| Border style | A or B or NEW | e.g. "luminous rgba white from glassmorphism" |
+| Shadow style | NEW | e.g. "teal-electric tinted shadows" |
+| Density default | A or B | e.g. "compact from cognitive-core" |
+| Border radius | A or B | e.g. "generous (16px+) from glassmorphism" |
+| Mono labels | A or B or none | e.g. "section rails only from cognitive-core" |
+| New signature | NEW | e.g. "dark glass panels revealing aurora gradient" |
+
+### 3.2 New elements (things neither parent has)
+
+List at least 3 elements that are genuinely new — not in parent A, not in parent B.
+
+These are the hybrid's creative contribution:
+- A new surface type, a new interaction pattern, a new composition rule
+- Something that only makes sense because BOTH parents are in the mix
+
+Example from aurora-command-ui:
+1. **Dark-tinted glass** — glassmorphism's glass is white-transparent; cognitive-core's surfaces are solid dark. The hybrid invents dark-tinted glass (`rgba(10,14,26,0.65)`) that is neither.
+2. **Gradient stat numbers** — cognitive-core has plain white stat numbers; glassmorphism puts gradients on hero text. The hybrid puts the teal→violet gradient on operational stat numbers specifically.
+3. **Aurora glow shadows** — cognitive-core uses black shadows; glassmorphism uses violet-tinted shadows. The hybrid uses teal-electric shadows, which only makes sense because the teal accent is "operational signal" (from cognitive-core) applied to a glass system (from glassmorphism).
+
+### 3.3 Conflict resolution
+
+When both parents claim the same dimension, use this priority order:
+1. **Substrate parent wins background** — no exceptions
+2. **Structure parent wins layout and density** — no exceptions
+3. **For everything else**: whichever parent has the more distinctive/unusual approach wins. The blend wins only if it creates a new element that didn't exist before.
+4. **Modifiers never override the 2 rules above.** If a modifier conflicts with a primary parent on substrate or structure, the modifier loses automatically.
+
+### 3.4 Anti-blend rules
+
+Never do these:
+- Average the two accent colors and use the average → the hybrid looks washed out
+- Use both parent layout systems simultaneously → the interface looks confused
+- Apply parent A's texture at 50% and parent B's texture at 50% → neither reads clearly
+- Keep both parent backgrounds in different sections → the substrate must be unified
+- Let a modifier become a stealth third parent → the identity collapses
+
+### 3.5 Modifier map (optional)
+
+If modifiers exist, add this small table after the dimension map:
+
+| Modifier | Allowed lane | Concrete contribution |
+|---|---|---|
+| `modifier-skill` | motion | "springier reveal timings for marketing sections only" |
+
+Keep this table short. Zero to 2 rows maximum in the default flow, or zero to 3 rows only in advanced mode.
+
+---
+
+## Crossover spec output format
+
+After completing phases 2 and 3, produce this summary before writing any file:
+
+```
+HYBRID: {name}
+PARENTS: {skill_a} × {skill_b}
+MODIFIERS: {optional list or "none"}
+TENSION: {one sentence}
+
+SUBSTRATE: {parent} — {substrate value}
+STRUCTURE: {parent} — {what it contributes}
+ACCENT: primary={value}, secondary={value}, gradient={value}
+
+PILLARS:
+1. {pillar title}: {3–5 sentences}
+2. {pillar title}: {3–5 sentences}
+3. {pillar title}: {3–5 sentences}
+
+DIMENSION MAP: (filled table)
+
+MODIFIER MAP: (only if modifiers exist)
+
+NEW ELEMENTS:
+- {element 1}
+- {element 2}
+- {element 3}
+```
+
+This summary is NOT a file. It lives in the conversation and guides file generation.
+Once the user confirms: proceed to Phase 4 (file generation).

package/template/.aioson/skills/process/design-hybrid-forge/references/naming-registry.md

@@ -0,0 +1,88 @@
+# Naming Registry — design-hybrid-forge
+
+Load when naming a new hybrid or checking for conflicts.
+
+---
+
+## Registered hybrids
+
+| Hybrid name | Parents | Shipped | Domain |
+|---|---|---|---|
+| `aurora-command-ui` | cognitive-core-ui × glassmorphism-ui | 2026-03-29 | SOC, AI platforms, dev tools |
+
+---
+
+## Naming conventions
+
+### Rules
+
+1. The name must be a compound of 2–3 words separated by hyphens.
+2. Must end in `-ui` (consistent with native skills).
+3. Must NOT contain either parent name (not "glass-core-ui", not "warm-glass-ui").
+4. Must evoke the resolved creative tension — the hybrid's *vibe*, not its recipe.
+5. Must be original — check this registry before finalizing.
+
+### Patterns that work
+
+| Pattern | Examples |
+|---|---|
+| `{atmosphere}-{function}-ui` | `aurora-command-ui`, `dusk-ops-ui`, `frost-bureau-ui` |
+| `{material}-{role}-ui` | `crystal-forge-ui`, `void-craft-ui`, `obsidian-core-ui` |
+| `{temperature}-{structure}-ui` | `warm-terminal-ui`, `cold-editorial-ui`, `ember-grid-ui` |
+| `{light}-{discipline}-ui` | `shadow-data-ui`, `neon-ledger-ui`, `pale-signal-ui` |
+
+### Patterns to avoid
+
+- Concatenating parent names: `glass-cognitive-ui`, `brutalist-warm-ui` ✕
+- Generic terms: `modern-ui`, `premium-dark-ui`, `clean-glass-ui` ✕
+- Overclaiming: `perfect-ui`, `ultimate-command-ui` ✕
+- Too abstract with no feel: `hybrid-alpha-ui`, `variant-b-ui` ✕
+
+---
+
+## Name ideas bank (unclaimed)
+
+The following names are available for future hybrids. They are not reserved — first hybrid that ships with a matching identity claims the name.
+
+### Dark + glass tier
+- `void-glass-ui` — dark structural void with glass transparency
+- `eclipse-dashboard-ui` — dark command, glass panels, celestial depth
+- `obsidian-signal-ui` — black-glass surfaces with sharp operational precision
+- `midnight-forge-ui` — deep dark atmosphere with raw structural energy
+
+### Warm + structured tier
+- `ember-command-ui` — warm earthy palette meeting command center density
+- `clay-terminal-ui` — terracotta palette over raw grid structure
+- `warm-bureau-ui` — humanized command center, serif meets mono
+- `amber-ops-ui` — golden-warm atmosphere with operational structure
+
+### Raw + luminous tier
+- `brutalist-glass-ui` — raw borders made luminous through glass
+- `frost-grid-ui` — neo-brutalist structure with glass frost treatment
+- `chalk-signal-ui` — rough texture with precision data signals
+- `raw-aurora-ui` — structural honesty floating on a glass aurora
+
+### Editorial + depth tier
+- `cinema-data-ui` — editorial cinematic rhythm with data density
+- `manifesto-ops-ui` — bold editorial headlines + operational panels
+- `dark-editorial-glass-ui` — editorial structure with glass depth layers
+- `ink-command-ui` — editorial typography commanding operational data
+
+### Clean + luminous tier
+- `crystalline-saas-ui` — minimal glass precision for enterprise
+- `cloud-command-ui` — clean systematic structure with glass elevation
+- `pale-aurora-ui` — light glass system over soft gradient, enterprise-grade
+
+---
+
+## How to register a new hybrid
+
+Only after explicit core promotion, add a row to the "Registered hybrids" table with:
+- The exact skill name used in the directory
+- Both parent skill names (alphabetical order)
+- The date shipped (`YYYY-MM-DD`)
+- 3–4 word domain description
+
+Also remove the name from the ideas bank if it was claimed from there.
+
+Project-local hybrids do not update this registry automatically. They should keep their chosen name in `.skill-meta.json` until a curator promotes them to core.