@olegkoval/agent-skills 1.56.1 → 1.57.0

package/.github/copilot-instructions.md

@@ -34,6 +34,7 @@ Available reusable prompt files:
 - product-builder: .github/prompts/product-builder.prompt.md
 - mvp-oneshot: .github/prompts/mvp-oneshot.prompt.md
 - ux-ui-audit-loop: .github/prompts/ux-ui-audit-loop.prompt.md
+- frontend-direction: .github/prompts/frontend-direction.prompt.md
 - starter-rules: .github/prompts/starter-rules.prompt.md
 - viral-launch: .github/prompts/viral-launch.prompt.md
 - context-repo: .github/prompts/context-repo.prompt.md

package/.github/prompts/frontend-direction.prompt.md

@@ -0,0 +1,57 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Choose a distinctive, coherent visual direction and source-backed components before building a new frontend, page, or substantial UI redesign. Use for frontend implementation and requests to make an interface less generic; keep small fixes within the existing design."
+---
+
+Use the olko:frontend-direction skill.
+
+# Frontend direction
+
+For Pi, Codex, Claude Code and Hermes, using the existing frontend stack. Use the host's available file, shell, browsing and image-inspection tools; no provider-specific tool names or plugins are required. Resolve bundled reference paths relative to this skill folder. Browsing and browser inspection improve source selection and visual verification; their absence must be reported, not disguised as verification.
+
+Make a deliberate visual choice before writing interface code. Deliver a recognizable composition that serves this product's users, with components that belong together. Distinctiveness can come from typography, imagery, spatial hierarchy, content or interaction; it does not require animation or new dependencies.
+
+## Match the effort to the task
+
+For a new page or substantial redesign, use the workflow below. For a small fix, reuse the established components and tokens and verify the affected state. Do not turn a spacing correction into a redesign or browse libraries on every turn. If another design skill supplies an approved direction, use it and perform the component selection here without repeating discovery.
+
+Read the relevant application instructions, stack, existing components and visual conventions. Inspect the current screen when available. Infer the audience, primary action, content density and constraints from the task. Ask only when a missing decision materially changes the result; otherwise state the assumption and proceed within the user's authorization.
+
+## Choose the direction before the components
+
+For an open-ended brief, consider two or three genuinely different compositions and choose the strongest fit. A color swap is not a different direction. A buyer comparing evidence may need an inspection workspace; a photographer may need an image-led editorial sequence. Avoid defaulting every product to a centered hero followed by identical cards.
+
+Briefly state the choice and why it helps the primary task. Do not require approval unless the user requested a design checkpoint or the choice would change their scope or brand. Respect supplied designs and existing systems.
+
+Define the visual anchors: layout and hierarchy, typography roles, palette, density, image treatment, and motion purpose. Reuse tokens where possible. Choose one or two signature treatments for emphasis, such as an annotated comparison rail or an editorial image sequence. Keep frequent controls familiar. Treat these as a default attention budget, not a prohibition on expressive briefs.
+
+## Select a coherent component set
+
+Read [references/sources.md](references/sources.md) when external references would improve the result. If that file is not bundled with your copy of this skill, read the [published catalog](https://github.com/oleg-koval/agent-skills/blob/main/plugins/olko-product/skills/frontend-direction/references/sources.md) instead. The catalog is a starting point, not a required dependency list. Existing project components and a small custom implementation are valid choices.
+
+Start with at most three relevant candidates. Expand only if none fits. Judge task fit, visual coherence, stack compatibility, accessibility, dependency cost and reuse terms. Do not rank novelty above usability or invent numeric scores that imply measurement.
+
+Inspect the exact official component page and available source before copying or installing. Record the URL, intended adaptation, dependencies, and known license or paid-access boundary. Unknown terms mean do not copy that source until clarified; use existing primitives or an original implementation instead. A screenshot or a social recommendation does not verify source availability or accessibility. Inspect registry payloads and install commands before execution.
+
+Prefer one primary component family per surface. Borrow an isolated interaction from another source only when it can share the same typography, spacing, radius, color and motion conventions. Never add a framework merely to use a decorative component. If browsing fails, label references unverified, use local primitives, and continue without claiming live checks.
+
+Before substantial implementation, leave a compact decision record in the task's existing plan, or in the response if no plan exists:
+
+| UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
+| --- | --- | --- | --- | --- |
+| Primary comparison | Aligned comparison rows | Existing table primitive | Makes differences scanable | Shared column widths; no dependency |
+
+Record the chosen direction and the most relevant rejected alternative with its reason. Reuse this decision on later turns; revisit only when evidence or requirements change. Do not create a new document for every small edit.
+
+## Build the composition, then inspect it
+
+Implement one representative section with realistic content before repeating it across the page. Establish shared tokens, responsive behavior and meaningful hierarchy there. Keep the product's actual states, including loading, empty, error, long text and unknown data. Decorative charts and invented statistics are not a substitute for content.
+
+Use motion to explain a transition or provide feedback. Preserve keyboard focus, semantics and immediate response; support reduced motion and interruption. Never hide essential content behind hover or animation.
+
+Inspect the rendered screen at desktop and narrow mobile sizes when browser tools are available. Check the primary action, text hierarchy, contrast, keyboard use, overflow, long content and relevant failure states. Compare the result with the chosen direction: does its composition still express it, or did it collapse into repeated generic cards? Is the signature treatment useful and proportionate?
+
+Make one focused correction pass for observed issues. Continue only for a specific unresolved defect, rather than redesigning indefinitely. Run the project's relevant checks. If visual inspection is unavailable, report that limit explicitly and distinguish code checks from visual acceptance.
+
+Report the direction, components and sources selected, dependencies added, and what was actually verified. This skill does not authorize deployment, publication or purchases.

package/.kiro/steering/frontend-direction.md

@@ -0,0 +1,56 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+inclusion: manual
+description: "Choose a distinctive, coherent visual direction and source-backed components before building a new frontend, page, or substantial UI redesign. Use for frontend implementation and requests to make an interface less generic; keep small fixes within the existing design."
+---
+
+# Frontend direction
+
+For Pi, Codex, Claude Code and Hermes, using the existing frontend stack. Use the host's available file, shell, browsing and image-inspection tools; no provider-specific tool names or plugins are required. Resolve bundled reference paths relative to this skill folder. Browsing and browser inspection improve source selection and visual verification; their absence must be reported, not disguised as verification.
+
+Make a deliberate visual choice before writing interface code. Deliver a recognizable composition that serves this product's users, with components that belong together. Distinctiveness can come from typography, imagery, spatial hierarchy, content or interaction; it does not require animation or new dependencies.
+
+## Match the effort to the task
+
+For a new page or substantial redesign, use the workflow below. For a small fix, reuse the established components and tokens and verify the affected state. Do not turn a spacing correction into a redesign or browse libraries on every turn. If another design skill supplies an approved direction, use it and perform the component selection here without repeating discovery.
+
+Read the relevant application instructions, stack, existing components and visual conventions. Inspect the current screen when available. Infer the audience, primary action, content density and constraints from the task. Ask only when a missing decision materially changes the result; otherwise state the assumption and proceed within the user's authorization.
+
+## Choose the direction before the components
+
+For an open-ended brief, consider two or three genuinely different compositions and choose the strongest fit. A color swap is not a different direction. A buyer comparing evidence may need an inspection workspace; a photographer may need an image-led editorial sequence. Avoid defaulting every product to a centered hero followed by identical cards.
+
+Briefly state the choice and why it helps the primary task. Do not require approval unless the user requested a design checkpoint or the choice would change their scope or brand. Respect supplied designs and existing systems.
+
+Define the visual anchors: layout and hierarchy, typography roles, palette, density, image treatment, and motion purpose. Reuse tokens where possible. Choose one or two signature treatments for emphasis, such as an annotated comparison rail or an editorial image sequence. Keep frequent controls familiar. Treat these as a default attention budget, not a prohibition on expressive briefs.
+
+## Select a coherent component set
+
+Read [references/sources.md](references/sources.md) when external references would improve the result. If that file is not bundled with your copy of this skill, read the [published catalog](https://github.com/oleg-koval/agent-skills/blob/main/plugins/olko-product/skills/frontend-direction/references/sources.md) instead. The catalog is a starting point, not a required dependency list. Existing project components and a small custom implementation are valid choices.
+
+Start with at most three relevant candidates. Expand only if none fits. Judge task fit, visual coherence, stack compatibility, accessibility, dependency cost and reuse terms. Do not rank novelty above usability or invent numeric scores that imply measurement.
+
+Inspect the exact official component page and available source before copying or installing. Record the URL, intended adaptation, dependencies, and known license or paid-access boundary. Unknown terms mean do not copy that source until clarified; use existing primitives or an original implementation instead. A screenshot or a social recommendation does not verify source availability or accessibility. Inspect registry payloads and install commands before execution.
+
+Prefer one primary component family per surface. Borrow an isolated interaction from another source only when it can share the same typography, spacing, radius, color and motion conventions. Never add a framework merely to use a decorative component. If browsing fails, label references unverified, use local primitives, and continue without claiming live checks.
+
+Before substantial implementation, leave a compact decision record in the task's existing plan, or in the response if no plan exists:
+
+| UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
+| --- | --- | --- | --- | --- |
+| Primary comparison | Aligned comparison rows | Existing table primitive | Makes differences scanable | Shared column widths; no dependency |
+
+Record the chosen direction and the most relevant rejected alternative with its reason. Reuse this decision on later turns; revisit only when evidence or requirements change. Do not create a new document for every small edit.
+
+## Build the composition, then inspect it
+
+Implement one representative section with realistic content before repeating it across the page. Establish shared tokens, responsive behavior and meaningful hierarchy there. Keep the product's actual states, including loading, empty, error, long text and unknown data. Decorative charts and invented statistics are not a substitute for content.
+
+Use motion to explain a transition or provide feedback. Preserve keyboard focus, semantics and immediate response; support reduced motion and interruption. Never hide essential content behind hover or animation.
+
+Inspect the rendered screen at desktop and narrow mobile sizes when browser tools are available. Check the primary action, text hierarchy, contrast, keyboard use, overflow, long content and relevant failure states. Compare the result with the chosen direction: does its composition still express it, or did it collapse into repeated generic cards? Is the signature treatment useful and proportionate?
+
+Make one focused correction pass for observed issues. Continue only for a specific unresolved defect, rather than redesigning indefinitely. Run the project's relevant checks. If visual inspection is unavailable, report that limit explicitly and distinguish code checks from visual acceptance.
+
+Report the direction, components and sources selected, dependencies added, and what was actually verified. This skill does not authorize deployment, publication or purchases.

package/.windsurf/rules/frontend-direction.md

@@ -0,0 +1,55 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+description: "Choose a distinctive, coherent visual direction and source-backed components before building a new frontend, page, or substantial UI redesign. Use for frontend implementation and requests to make an interface less generic; keep small fixes within the existing design."
+---
+
+# Frontend direction
+
+For Pi, Codex, Claude Code and Hermes, using the existing frontend stack. Use the host's available file, shell, browsing and image-inspection tools; no provider-specific tool names or plugins are required. Resolve bundled reference paths relative to this skill folder. Browsing and browser inspection improve source selection and visual verification; their absence must be reported, not disguised as verification.
+
+Make a deliberate visual choice before writing interface code. Deliver a recognizable composition that serves this product's users, with components that belong together. Distinctiveness can come from typography, imagery, spatial hierarchy, content or interaction; it does not require animation or new dependencies.
+
+## Match the effort to the task
+
+For a new page or substantial redesign, use the workflow below. For a small fix, reuse the established components and tokens and verify the affected state. Do not turn a spacing correction into a redesign or browse libraries on every turn. If another design skill supplies an approved direction, use it and perform the component selection here without repeating discovery.
+
+Read the relevant application instructions, stack, existing components and visual conventions. Inspect the current screen when available. Infer the audience, primary action, content density and constraints from the task. Ask only when a missing decision materially changes the result; otherwise state the assumption and proceed within the user's authorization.
+
+## Choose the direction before the components
+
+For an open-ended brief, consider two or three genuinely different compositions and choose the strongest fit. A color swap is not a different direction. A buyer comparing evidence may need an inspection workspace; a photographer may need an image-led editorial sequence. Avoid defaulting every product to a centered hero followed by identical cards.
+
+Briefly state the choice and why it helps the primary task. Do not require approval unless the user requested a design checkpoint or the choice would change their scope or brand. Respect supplied designs and existing systems.
+
+Define the visual anchors: layout and hierarchy, typography roles, palette, density, image treatment, and motion purpose. Reuse tokens where possible. Choose one or two signature treatments for emphasis, such as an annotated comparison rail or an editorial image sequence. Keep frequent controls familiar. Treat these as a default attention budget, not a prohibition on expressive briefs.
+
+## Select a coherent component set
+
+Read [references/sources.md](references/sources.md) when external references would improve the result. If that file is not bundled with your copy of this skill, read the [published catalog](https://github.com/oleg-koval/agent-skills/blob/main/plugins/olko-product/skills/frontend-direction/references/sources.md) instead. The catalog is a starting point, not a required dependency list. Existing project components and a small custom implementation are valid choices.
+
+Start with at most three relevant candidates. Expand only if none fits. Judge task fit, visual coherence, stack compatibility, accessibility, dependency cost and reuse terms. Do not rank novelty above usability or invent numeric scores that imply measurement.
+
+Inspect the exact official component page and available source before copying or installing. Record the URL, intended adaptation, dependencies, and known license or paid-access boundary. Unknown terms mean do not copy that source until clarified; use existing primitives or an original implementation instead. A screenshot or a social recommendation does not verify source availability or accessibility. Inspect registry payloads and install commands before execution.
+
+Prefer one primary component family per surface. Borrow an isolated interaction from another source only when it can share the same typography, spacing, radius, color and motion conventions. Never add a framework merely to use a decorative component. If browsing fails, label references unverified, use local primitives, and continue without claiming live checks.
+
+Before substantial implementation, leave a compact decision record in the task's existing plan, or in the response if no plan exists:
+
+| UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
+| --- | --- | --- | --- | --- |
+| Primary comparison | Aligned comparison rows | Existing table primitive | Makes differences scanable | Shared column widths; no dependency |
+
+Record the chosen direction and the most relevant rejected alternative with its reason. Reuse this decision on later turns; revisit only when evidence or requirements change. Do not create a new document for every small edit.
+
+## Build the composition, then inspect it
+
+Implement one representative section with realistic content before repeating it across the page. Establish shared tokens, responsive behavior and meaningful hierarchy there. Keep the product's actual states, including loading, empty, error, long text and unknown data. Decorative charts and invented statistics are not a substitute for content.
+
+Use motion to explain a transition or provide feedback. Preserve keyboard focus, semantics and immediate response; support reduced motion and interruption. Never hide essential content behind hover or animation.
+
+Inspect the rendered screen at desktop and narrow mobile sizes when browser tools are available. Check the primary action, text hierarchy, contrast, keyboard use, overflow, long content and relevant failure states. Compare the result with the chosen direction: does its composition still express it, or did it collapse into repeated generic cards? Is the signature treatment useful and proportionate?
+
+Make one focused correction pass for observed issues. Continue only for a specific unresolved defect, rather than redesigning indefinitely. Run the project's relevant checks. If visual inspection is unavailable, report that limit explicitly and distinguish code checks from visual acceptance.
+
+Report the direction, components and sources selected, dependencies added, and what was actually verified. This skill does not authorize deployment, publication or purchases.

package/README.md

@@ -3,7 +3,7 @@
   <p><strong>Agent-agnostic skill catalog for Codex, Claude, Cursor, Grok, Copilot, Windsurf, Kiro, Hermes Agent, and other skill-aware tools.</strong></p>
   <p>
     <img src="https://img.shields.io/badge/license-MIT-16a34a" alt="MIT license">
-    <img src="https://img.shields.io/badge/skills-55-2563eb" alt="55 skills">
+    <img src="https://img.shields.io/badge/skills-56-2563eb" alt="56 skills">
     <img src="https://img.shields.io/badge/platforms-Codex%20%7C%20Claude%20%7C%20Cursor%20%7C%20Grok%20%7C%20Copilot%20%7C%20Windsurf%20%7C%20Kiro%20%7C%20Hermes-111827" alt="Codex Claude Cursor Grok Copilot Windsurf Kiro Hermes">
     <img src="https://img.shields.io/badge/status-public%20catalog-16a34a" alt="Public catalog">
   </p>
@@ -135,7 +135,7 @@ cd agent-skills
 ./scripts/install-hermes-symlinks.sh
 ```
 
-The installer links all 55 canonical skill packages under
+The installer links all 56 canonical skill packages under
 `${HERMES_HOME:-$HOME/.hermes}/skills/olko-agent-skills/`. It leaves existing paths untouched and
 fails on a collision. It reports obsolete catalog-owned links without removing them; after
 reviewing those links, run `./scripts/install-hermes-symlinks.sh --prune` to remove them.
@@ -264,7 +264,7 @@ Ship a release: semantic-release setup, changelogs, store listing copy, release-
 | [changelog-generator](plugins/olko-release/skills/changelog-generator/SKILL.md) | Transforms git commits into polished user-facing changelogs by categorising changes and rewriting technical commit messages | Preparing release notes, a CHANGELOG entry, or "what changed since the last release"; for setting up the release pipeline itself use semantic-release-beta |
 | [store-listing-copy](plugins/olko-release/skills/store-listing-copy/SKILL.md) | Generates platform-validated App Store, Google Play, and Connect IQ store listing copy (title, subtitle, description, what's new, keywords) from a git changelog | Writing store copy before submitting to apple-store-submit or the garmin-watchface store workflow |
 
-### olko-product (5)
+### olko-product (6)
 
 Take a product idea to a shippable build: MVP passes, full-stack scaffolds, UX/UI quality loops, launch plans.
 
@@ -273,6 +273,7 @@ Take a product idea to a shippable build: MVP passes, full-stack scaffolds, UX/U
 | [product-builder](plugins/olko-product/skills/product-builder/SKILL.md) | Builds a full-stack web app or SaaS product from a user description using production-oriented defaults | Building a complete app, SaaS, dashboard, or product rather than a prototype |
 | [mvp-oneshot](plugins/olko-product/skills/mvp-oneshot/SKILL.md) | Takes a rough product idea and produces a scoped, testable MVP plan and initial implementation in a single pass | Going from idea to a shippable one-week MVP without losing scope |
 | [ux-ui-audit-loop](plugins/olko-product/skills/ux-ui-audit-loop/SKILL.md) | Audits and improves a web UI through browser evidence, severity triage, minimal fixes, and before/after verification | The user says "audit this UI", "fix the UX", "review this page visually", "make this page polished", or asks for an autonomous screenshot-and-fix loop |
+| [frontend-direction](plugins/olko-product/skills/frontend-direction/SKILL.md) | Chooses a distinctive, coherent visual direction and source-backed components before writing frontend code | Building a new page or a substantial UI redesign, or making an interface less generic; small fixes keep the existing design |
 | [starter-rules](plugins/olko-product/skills/starter-rules/SKILL.md) | Loads and enforces hard rules for every oleg-koval/* starter | Ensuring 300-line files, E2E tests, pre-commit hooks, Vertical Slice architecture, and KISS/DRY/SOLID |
 | [viral-launch](plugins/olko-product/skills/viral-launch/SKILL.md) | Sets up a project repository and launch plan for shareable marketing, public launch readiness, and growth loops | Preparing a repo, product, or package for public launch ("prep for Product Hunt", "write the launch post", "make this shareable"); for building the thing itself use mvp-oneshot or product-builder |
 
@@ -511,8 +512,8 @@ Never edit one by hand: CI regenerates and fails on any difference.
 The maintained `scripts/install-hermes-symlinks.sh` makes the Hermes pointers usable by its skills loader.
 
 Coverage is per skill, not uniform. Each skill's `adapters` array in `catalog/skills.json`
-decides which targets it ships to, so the file counts differ per target: Claude 55, Grok 53,
-Cursor 51, Copilot 51, Codex 49, Windsurf 40, Kiro 40, Pi 2, Hermes 55. A skill is absent from a
+decides which targets it ships to, so the file counts differ per target: Claude 56, Grok 54,
+Cursor 52, Copilot 52, Codex 50, Windsurf 41, Kiro 41, Pi 3, Hermes 56. A skill is absent from a
 target's tree when its catalog entry does not list that target.
 
 ## Local validation

package/adapters/claude/olko-product/skills/frontend-direction/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: frontend-direction
+description: Choose a distinctive, coherent visual direction and source-backed components before building a new frontend, page, or substantial UI redesign. Use for frontend implementation and requests to make an interface less generic; keep small fixes within the existing design.
+license: MIT
+metadata:
+  author: Oleg Koval
+  tags: frontend, design, components, art-direction
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+# Frontend direction
+
+For Pi, Codex, Claude Code and Hermes, using the existing frontend stack. Use the host's available file, shell, browsing and image-inspection tools; no provider-specific tool names or plugins are required. Resolve bundled reference paths relative to this skill folder. Browsing and browser inspection improve source selection and visual verification; their absence must be reported, not disguised as verification.
+
+Make a deliberate visual choice before writing interface code. Deliver a recognizable composition that serves this product's users, with components that belong together. Distinctiveness can come from typography, imagery, spatial hierarchy, content or interaction; it does not require animation or new dependencies.
+
+## Match the effort to the task
+
+For a new page or substantial redesign, use the workflow below. For a small fix, reuse the established components and tokens and verify the affected state. Do not turn a spacing correction into a redesign or browse libraries on every turn. If another design skill supplies an approved direction, use it and perform the component selection here without repeating discovery.
+
+Read the relevant application instructions, stack, existing components and visual conventions. Inspect the current screen when available. Infer the audience, primary action, content density and constraints from the task. Ask only when a missing decision materially changes the result; otherwise state the assumption and proceed within the user's authorization.
+
+## Choose the direction before the components
+
+For an open-ended brief, consider two or three genuinely different compositions and choose the strongest fit. A color swap is not a different direction. A buyer comparing evidence may need an inspection workspace; a photographer may need an image-led editorial sequence. Avoid defaulting every product to a centered hero followed by identical cards.
+
+Briefly state the choice and why it helps the primary task. Do not require approval unless the user requested a design checkpoint or the choice would change their scope or brand. Respect supplied designs and existing systems.
+
+Define the visual anchors: layout and hierarchy, typography roles, palette, density, image treatment, and motion purpose. Reuse tokens where possible. Choose one or two signature treatments for emphasis, such as an annotated comparison rail or an editorial image sequence. Keep frequent controls familiar. Treat these as a default attention budget, not a prohibition on expressive briefs.
+
+## Select a coherent component set
+
+Read [references/sources.md](references/sources.md) when external references would improve the result. If that file is not bundled with your copy of this skill, read the [published catalog](https://github.com/oleg-koval/agent-skills/blob/main/plugins/olko-product/skills/frontend-direction/references/sources.md) instead. The catalog is a starting point, not a required dependency list. Existing project components and a small custom implementation are valid choices.
+
+Start with at most three relevant candidates. Expand only if none fits. Judge task fit, visual coherence, stack compatibility, accessibility, dependency cost and reuse terms. Do not rank novelty above usability or invent numeric scores that imply measurement.
+
+Inspect the exact official component page and available source before copying or installing. Record the URL, intended adaptation, dependencies, and known license or paid-access boundary. Unknown terms mean do not copy that source until clarified; use existing primitives or an original implementation instead. A screenshot or a social recommendation does not verify source availability or accessibility. Inspect registry payloads and install commands before execution.
+
+Prefer one primary component family per surface. Borrow an isolated interaction from another source only when it can share the same typography, spacing, radius, color and motion conventions. Never add a framework merely to use a decorative component. If browsing fails, label references unverified, use local primitives, and continue without claiming live checks.
+
+Before substantial implementation, leave a compact decision record in the task's existing plan, or in the response if no plan exists:
+
+| UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
+| --- | --- | --- | --- | --- |
+| Primary comparison | Aligned comparison rows | Existing table primitive | Makes differences scanable | Shared column widths; no dependency |
+
+Record the chosen direction and the most relevant rejected alternative with its reason. Reuse this decision on later turns; revisit only when evidence or requirements change. Do not create a new document for every small edit.
+
+## Build the composition, then inspect it
+
+Implement one representative section with realistic content before repeating it across the page. Establish shared tokens, responsive behavior and meaningful hierarchy there. Keep the product's actual states, including loading, empty, error, long text and unknown data. Decorative charts and invented statistics are not a substitute for content.
+
+Use motion to explain a transition or provide feedback. Preserve keyboard focus, semantics and immediate response; support reduced motion and interruption. Never hide essential content behind hover or animation.
+
+Inspect the rendered screen at desktop and narrow mobile sizes when browser tools are available. Check the primary action, text hierarchy, contrast, keyboard use, overflow, long content and relevant failure states. Compare the result with the chosen direction: does its composition still express it, or did it collapse into repeated generic cards? Is the signature treatment useful and proportionate?
+
+Make one focused correction pass for observed issues. Continue only for a specific unresolved defect, rather than redesigning indefinitely. Run the project's relevant checks. If visual inspection is unavailable, report that limit explicitly and distinguish code checks from visual acceptance.
+
+Report the direction, components and sources selected, dependencies added, and what was actually verified. This skill does not authorize deployment, publication or purchases.

package/adapters/claude/olko-product/skills/frontend-direction/references/sources.md

@@ -0,0 +1,36 @@
+# Component discovery sources
+
+Seed: [Nero's resource post](https://x.com/neropursue/status/2109514246853677192), retrieved on 2026-10-12 through [FxTwitter](https://api.fxtwitter.com/status/2109514246853677192) after X returned 403. The categories below describe discovery uses, not guarantees about current features, compatibility, accessibility, pricing or licenses. Check the exact source before adoption.
+
+| Source | Start here when exploring |
+| --- | --- |
+| [Affect UI](https://affectui.com) | General visual component references |
+| [Kobra](https://kobra.systems) | Controls, navigation and product interactions |
+| [Arc UI](https://uiarc.dev) | UI composition and component ideas |
+| [EvilCharts](https://evilcharts.com) | Charts for real quantitative questions |
+| [Transitions.dev](https://transitions.dev) | State transitions and motion recipes |
+| [beUI](https://beui.dev) | Animated React component candidates |
+| [BoardUI](https://www.boardui.com) | Dashboard component candidates |
+
+The official Kobra, Transitions.dev and beUI sites were accessible during this skill's creation. The other entries are retained as discovery links from the post, not independently verified endorsements. No upstream component source or recipe is bundled here.
+
+For each selected candidate, inspect its exact documentation and source, not only its homepage. Verify framework/version requirements, dependencies, responsive states, keyboard behavior, reduced-motion handling where relevant, and reuse terms. Paid sections and free sections may have different conditions.
+
+Use the source that answers the task. A native HTML app can implement an original CSS interaction; a chart library is unnecessary when a comparison table is clearer. If no candidate fits, retain local components and derive distinctiveness from composition, content and typography.
+
+Seed: [Aman Singh's resource post](https://x.com/amananimates/status/2111848675811225980?s=46), retrieved on 2026-10-19 through [FxTwitter](https://api.fxtwitter.com/status/2111848675811225980) after X returned 403. The categories below describe discovery uses, not guarantees about current features, compatibility, accessibility, pricing or licenses. Check the exact source before adoption.
+
+| Source | Start here when exploring |
+| --- | --- |
+| [Scrolltide](https://scrolltide.co) | Prompts and source-code resources for interface design |
+| [Mobbin](https://mobbin.com) | Real-world UI patterns from iOS and Android apps |
+| [Fontshare](https://fontshare.com) | Free, high-quality fonts for commercial use |
+| [Coolors](https://coolors.co) | Fast color scheme generation and exploration |
+| [Spline](https://spline.design) | Interactive 3D design and web publishing |
+| [LottieFiles](https://lottiefiles.com) | Lottie animations for web and mobile |
+| [Three.js Journey](https://threejs-journey.com) | Step-by-step Three.js tutorials and examples |
+| [3Dicons](https://3dicons.co) | Free 3D icons for websites and applications |
+
+For each selected candidate, inspect its exact documentation and source, not only its homepage. Verify framework/version requirements, dependencies, responsive states, keyboard behavior, reduced-motion handling where relevant, and reuse terms. Paid sections and free sections may have different conditions.
+
+Use the source that answers the task. A native HTML app can implement an original CSS interaction; a chart library is unnecessary when a comparison table is clearer. If no candidate fits, retain local components and derive distinctiveness from composition, content and typography.

package/adapters/codex/olko-product/README.md

@@ -7,5 +7,6 @@ Use the canonical skills directly:
 - `plugins/olko-product/skills/product-builder/SKILL.md`
 - `plugins/olko-product/skills/mvp-oneshot/SKILL.md`
 - `plugins/olko-product/skills/ux-ui-audit-loop/SKILL.md`
+- `plugins/olko-product/skills/frontend-direction/SKILL.md`
 - `plugins/olko-product/skills/starter-rules/SKILL.md`
 - `plugins/olko-product/skills/viral-launch/SKILL.md`

package/adapters/cursor/olko-product/skills/frontend-direction/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: frontend-direction
+description: Choose a distinctive, coherent visual direction and source-backed components before building a new frontend, page, or substantial UI redesign. Use for frontend implementation and requests to make an interface less generic; keep small fixes within the existing design.
+license: MIT
+metadata:
+  author: Oleg Koval
+  tags: frontend, design, components, art-direction
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+# Frontend direction
+
+For Pi, Codex, Claude Code and Hermes, using the existing frontend stack. Use the host's available file, shell, browsing and image-inspection tools; no provider-specific tool names or plugins are required. Resolve bundled reference paths relative to this skill folder. Browsing and browser inspection improve source selection and visual verification; their absence must be reported, not disguised as verification.
+
+Make a deliberate visual choice before writing interface code. Deliver a recognizable composition that serves this product's users, with components that belong together. Distinctiveness can come from typography, imagery, spatial hierarchy, content or interaction; it does not require animation or new dependencies.
+
+## Match the effort to the task
+
+For a new page or substantial redesign, use the workflow below. For a small fix, reuse the established components and tokens and verify the affected state. Do not turn a spacing correction into a redesign or browse libraries on every turn. If another design skill supplies an approved direction, use it and perform the component selection here without repeating discovery.
+
+Read the relevant application instructions, stack, existing components and visual conventions. Inspect the current screen when available. Infer the audience, primary action, content density and constraints from the task. Ask only when a missing decision materially changes the result; otherwise state the assumption and proceed within the user's authorization.
+
+## Choose the direction before the components
+
+For an open-ended brief, consider two or three genuinely different compositions and choose the strongest fit. A color swap is not a different direction. A buyer comparing evidence may need an inspection workspace; a photographer may need an image-led editorial sequence. Avoid defaulting every product to a centered hero followed by identical cards.
+
+Briefly state the choice and why it helps the primary task. Do not require approval unless the user requested a design checkpoint or the choice would change their scope or brand. Respect supplied designs and existing systems.
+
+Define the visual anchors: layout and hierarchy, typography roles, palette, density, image treatment, and motion purpose. Reuse tokens where possible. Choose one or two signature treatments for emphasis, such as an annotated comparison rail or an editorial image sequence. Keep frequent controls familiar. Treat these as a default attention budget, not a prohibition on expressive briefs.
+
+## Select a coherent component set
+
+Read [references/sources.md](references/sources.md) when external references would improve the result. If that file is not bundled with your copy of this skill, read the [published catalog](https://github.com/oleg-koval/agent-skills/blob/main/plugins/olko-product/skills/frontend-direction/references/sources.md) instead. The catalog is a starting point, not a required dependency list. Existing project components and a small custom implementation are valid choices.
+
+Start with at most three relevant candidates. Expand only if none fits. Judge task fit, visual coherence, stack compatibility, accessibility, dependency cost and reuse terms. Do not rank novelty above usability or invent numeric scores that imply measurement.
+
+Inspect the exact official component page and available source before copying or installing. Record the URL, intended adaptation, dependencies, and known license or paid-access boundary. Unknown terms mean do not copy that source until clarified; use existing primitives or an original implementation instead. A screenshot or a social recommendation does not verify source availability or accessibility. Inspect registry payloads and install commands before execution.
+
+Prefer one primary component family per surface. Borrow an isolated interaction from another source only when it can share the same typography, spacing, radius, color and motion conventions. Never add a framework merely to use a decorative component. If browsing fails, label references unverified, use local primitives, and continue without claiming live checks.
+
+Before substantial implementation, leave a compact decision record in the task's existing plan, or in the response if no plan exists:
+
+| UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
+| --- | --- | --- | --- | --- |
+| Primary comparison | Aligned comparison rows | Existing table primitive | Makes differences scanable | Shared column widths; no dependency |
+
+Record the chosen direction and the most relevant rejected alternative with its reason. Reuse this decision on later turns; revisit only when evidence or requirements change. Do not create a new document for every small edit.
+
+## Build the composition, then inspect it
+
+Implement one representative section with realistic content before repeating it across the page. Establish shared tokens, responsive behavior and meaningful hierarchy there. Keep the product's actual states, including loading, empty, error, long text and unknown data. Decorative charts and invented statistics are not a substitute for content.
+
+Use motion to explain a transition or provide feedback. Preserve keyboard focus, semantics and immediate response; support reduced motion and interruption. Never hide essential content behind hover or animation.
+
+Inspect the rendered screen at desktop and narrow mobile sizes when browser tools are available. Check the primary action, text hierarchy, contrast, keyboard use, overflow, long content and relevant failure states. Compare the result with the chosen direction: does its composition still express it, or did it collapse into repeated generic cards? Is the signature treatment useful and proportionate?
+
+Make one focused correction pass for observed issues. Continue only for a specific unresolved defect, rather than redesigning indefinitely. Run the project's relevant checks. If visual inspection is unavailable, report that limit explicitly and distinguish code checks from visual acceptance.
+
+Report the direction, components and sources selected, dependencies added, and what was actually verified. This skill does not authorize deployment, publication or purchases.

package/adapters/cursor/olko-product/skills/frontend-direction/references/sources.md

@@ -0,0 +1,36 @@
+# Component discovery sources
+
+Seed: [Nero's resource post](https://x.com/neropursue/status/2109514246853677192), retrieved on 2026-10-12 through [FxTwitter](https://api.fxtwitter.com/status/2109514246853677192) after X returned 403. The categories below describe discovery uses, not guarantees about current features, compatibility, accessibility, pricing or licenses. Check the exact source before adoption.
+
+| Source | Start here when exploring |
+| --- | --- |
+| [Affect UI](https://affectui.com) | General visual component references |
+| [Kobra](https://kobra.systems) | Controls, navigation and product interactions |
+| [Arc UI](https://uiarc.dev) | UI composition and component ideas |
+| [EvilCharts](https://evilcharts.com) | Charts for real quantitative questions |
+| [Transitions.dev](https://transitions.dev) | State transitions and motion recipes |
+| [beUI](https://beui.dev) | Animated React component candidates |
+| [BoardUI](https://www.boardui.com) | Dashboard component candidates |
+
+The official Kobra, Transitions.dev and beUI sites were accessible during this skill's creation. The other entries are retained as discovery links from the post, not independently verified endorsements. No upstream component source or recipe is bundled here.
+
+For each selected candidate, inspect its exact documentation and source, not only its homepage. Verify framework/version requirements, dependencies, responsive states, keyboard behavior, reduced-motion handling where relevant, and reuse terms. Paid sections and free sections may have different conditions.
+
+Use the source that answers the task. A native HTML app can implement an original CSS interaction; a chart library is unnecessary when a comparison table is clearer. If no candidate fits, retain local components and derive distinctiveness from composition, content and typography.
+
+Seed: [Aman Singh's resource post](https://x.com/amananimates/status/2111848675811225980?s=46), retrieved on 2026-10-19 through [FxTwitter](https://api.fxtwitter.com/status/2111848675811225980) after X returned 403. The categories below describe discovery uses, not guarantees about current features, compatibility, accessibility, pricing or licenses. Check the exact source before adoption.
+
+| Source | Start here when exploring |
+| --- | --- |
+| [Scrolltide](https://scrolltide.co) | Prompts and source-code resources for interface design |
+| [Mobbin](https://mobbin.com) | Real-world UI patterns from iOS and Android apps |
+| [Fontshare](https://fontshare.com) | Free, high-quality fonts for commercial use |
+| [Coolors](https://coolors.co) | Fast color scheme generation and exploration |
+| [Spline](https://spline.design) | Interactive 3D design and web publishing |
+| [LottieFiles](https://lottiefiles.com) | Lottie animations for web and mobile |
+| [Three.js Journey](https://threejs-journey.com) | Step-by-step Three.js tutorials and examples |
+| [3Dicons](https://3dicons.co) | Free 3D icons for websites and applications |
+
+For each selected candidate, inspect its exact documentation and source, not only its homepage. Verify framework/version requirements, dependencies, responsive states, keyboard behavior, reduced-motion handling where relevant, and reuse terms. Paid sections and free sections may have different conditions.
+
+Use the source that answers the task. A native HTML app can implement an original CSS interaction; a chart library is unnecessary when a comparison table is clearer. If no candidate fits, retain local components and derive distinctiveness from composition, content and typography.

package/adapters/grok/olko-product/skills/frontend-direction/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: frontend-direction
+description: Choose a distinctive, coherent visual direction and source-backed components before building a new frontend, page, or substantial UI redesign. Use for frontend implementation and requests to make an interface less generic; keep small fixes within the existing design.
+license: MIT
+metadata:
+  author: Oleg Koval
+  tags: frontend, design, components, art-direction
+---
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+# Frontend direction
+
+For Pi, Codex, Claude Code and Hermes, using the existing frontend stack. Use the host's available file, shell, browsing and image-inspection tools; no provider-specific tool names or plugins are required. Resolve bundled reference paths relative to this skill folder. Browsing and browser inspection improve source selection and visual verification; their absence must be reported, not disguised as verification.
+
+Make a deliberate visual choice before writing interface code. Deliver a recognizable composition that serves this product's users, with components that belong together. Distinctiveness can come from typography, imagery, spatial hierarchy, content or interaction; it does not require animation or new dependencies.
+
+## Match the effort to the task
+
+For a new page or substantial redesign, use the workflow below. For a small fix, reuse the established components and tokens and verify the affected state. Do not turn a spacing correction into a redesign or browse libraries on every turn. If another design skill supplies an approved direction, use it and perform the component selection here without repeating discovery.
+
+Read the relevant application instructions, stack, existing components and visual conventions. Inspect the current screen when available. Infer the audience, primary action, content density and constraints from the task. Ask only when a missing decision materially changes the result; otherwise state the assumption and proceed within the user's authorization.
+
+## Choose the direction before the components
+
+For an open-ended brief, consider two or three genuinely different compositions and choose the strongest fit. A color swap is not a different direction. A buyer comparing evidence may need an inspection workspace; a photographer may need an image-led editorial sequence. Avoid defaulting every product to a centered hero followed by identical cards.
+
+Briefly state the choice and why it helps the primary task. Do not require approval unless the user requested a design checkpoint or the choice would change their scope or brand. Respect supplied designs and existing systems.
+
+Define the visual anchors: layout and hierarchy, typography roles, palette, density, image treatment, and motion purpose. Reuse tokens where possible. Choose one or two signature treatments for emphasis, such as an annotated comparison rail or an editorial image sequence. Keep frequent controls familiar. Treat these as a default attention budget, not a prohibition on expressive briefs.
+
+## Select a coherent component set
+
+Read [references/sources.md](references/sources.md) when external references would improve the result. If that file is not bundled with your copy of this skill, read the [published catalog](https://github.com/oleg-koval/agent-skills/blob/main/plugins/olko-product/skills/frontend-direction/references/sources.md) instead. The catalog is a starting point, not a required dependency list. Existing project components and a small custom implementation are valid choices.
+
+Start with at most three relevant candidates. Expand only if none fits. Judge task fit, visual coherence, stack compatibility, accessibility, dependency cost and reuse terms. Do not rank novelty above usability or invent numeric scores that imply measurement.
+
+Inspect the exact official component page and available source before copying or installing. Record the URL, intended adaptation, dependencies, and known license or paid-access boundary. Unknown terms mean do not copy that source until clarified; use existing primitives or an original implementation instead. A screenshot or a social recommendation does not verify source availability or accessibility. Inspect registry payloads and install commands before execution.
+
+Prefer one primary component family per surface. Borrow an isolated interaction from another source only when it can share the same typography, spacing, radius, color and motion conventions. Never add a framework merely to use a decorative component. If browsing fails, label references unverified, use local primitives, and continue without claiming live checks.
+
+Before substantial implementation, leave a compact decision record in the task's existing plan, or in the response if no plan exists:
+
+| UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
+| --- | --- | --- | --- | --- |
+| Primary comparison | Aligned comparison rows | Existing table primitive | Makes differences scanable | Shared column widths; no dependency |
+
+Record the chosen direction and the most relevant rejected alternative with its reason. Reuse this decision on later turns; revisit only when evidence or requirements change. Do not create a new document for every small edit.
+
+## Build the composition, then inspect it
+
+Implement one representative section with realistic content before repeating it across the page. Establish shared tokens, responsive behavior and meaningful hierarchy there. Keep the product's actual states, including loading, empty, error, long text and unknown data. Decorative charts and invented statistics are not a substitute for content.
+
+Use motion to explain a transition or provide feedback. Preserve keyboard focus, semantics and immediate response; support reduced motion and interruption. Never hide essential content behind hover or animation.
+
+Inspect the rendered screen at desktop and narrow mobile sizes when browser tools are available. Check the primary action, text hierarchy, contrast, keyboard use, overflow, long content and relevant failure states. Compare the result with the chosen direction: does its composition still express it, or did it collapse into repeated generic cards? Is the signature treatment useful and proportionate?
+
+Make one focused correction pass for observed issues. Continue only for a specific unresolved defect, rather than redesigning indefinitely. Run the project's relevant checks. If visual inspection is unavailable, report that limit explicitly and distinguish code checks from visual acceptance.
+
+Report the direction, components and sources selected, dependencies added, and what was actually verified. This skill does not authorize deployment, publication or purchases.

package/adapters/grok/olko-product/skills/frontend-direction/references/sources.md

@@ -0,0 +1,36 @@
+# Component discovery sources
+
+Seed: [Nero's resource post](https://x.com/neropursue/status/2109514246853677192), retrieved on 2026-10-12 through [FxTwitter](https://api.fxtwitter.com/status/2109514246853677192) after X returned 403. The categories below describe discovery uses, not guarantees about current features, compatibility, accessibility, pricing or licenses. Check the exact source before adoption.
+
+| Source | Start here when exploring |
+| --- | --- |
+| [Affect UI](https://affectui.com) | General visual component references |
+| [Kobra](https://kobra.systems) | Controls, navigation and product interactions |
+| [Arc UI](https://uiarc.dev) | UI composition and component ideas |
+| [EvilCharts](https://evilcharts.com) | Charts for real quantitative questions |
+| [Transitions.dev](https://transitions.dev) | State transitions and motion recipes |
+| [beUI](https://beui.dev) | Animated React component candidates |
+| [BoardUI](https://www.boardui.com) | Dashboard component candidates |
+
+The official Kobra, Transitions.dev and beUI sites were accessible during this skill's creation. The other entries are retained as discovery links from the post, not independently verified endorsements. No upstream component source or recipe is bundled here.
+
+For each selected candidate, inspect its exact documentation and source, not only its homepage. Verify framework/version requirements, dependencies, responsive states, keyboard behavior, reduced-motion handling where relevant, and reuse terms. Paid sections and free sections may have different conditions.
+
+Use the source that answers the task. A native HTML app can implement an original CSS interaction; a chart library is unnecessary when a comparison table is clearer. If no candidate fits, retain local components and derive distinctiveness from composition, content and typography.
+
+Seed: [Aman Singh's resource post](https://x.com/amananimates/status/2111848675811225980?s=46), retrieved on 2026-10-19 through [FxTwitter](https://api.fxtwitter.com/status/2111848675811225980) after X returned 403. The categories below describe discovery uses, not guarantees about current features, compatibility, accessibility, pricing or licenses. Check the exact source before adoption.
+
+| Source | Start here when exploring |
+| --- | --- |
+| [Scrolltide](https://scrolltide.co) | Prompts and source-code resources for interface design |
+| [Mobbin](https://mobbin.com) | Real-world UI patterns from iOS and Android apps |
+| [Fontshare](https://fontshare.com) | Free, high-quality fonts for commercial use |
+| [Coolors](https://coolors.co) | Fast color scheme generation and exploration |
+| [Spline](https://spline.design) | Interactive 3D design and web publishing |
+| [LottieFiles](https://lottiefiles.com) | Lottie animations for web and mobile |
+| [Three.js Journey](https://threejs-journey.com) | Step-by-step Three.js tutorials and examples |
+| [3Dicons](https://3dicons.co) | Free 3D icons for websites and applications |
+
+For each selected candidate, inspect its exact documentation and source, not only its homepage. Verify framework/version requirements, dependencies, responsive states, keyboard behavior, reduced-motion handling where relevant, and reuse terms. Paid sections and free sections may have different conditions.
+
+Use the source that answers the task. A native HTML app can implement an original CSS interaction; a chart library is unnecessary when a comparison table is clearer. If no candidate fits, retain local components and derive distinctiveness from composition, content and typography.

package/adapters/hermes/olko-product/README.md

@@ -8,5 +8,6 @@ into the active Hermes profile. The canonical packages are:
 - `plugins/olko-product/skills/product-builder/SKILL.md`
 - `plugins/olko-product/skills/mvp-oneshot/SKILL.md`
 - `plugins/olko-product/skills/ux-ui-audit-loop/SKILL.md`
+- `plugins/olko-product/skills/frontend-direction/SKILL.md`
 - `plugins/olko-product/skills/starter-rules/SKILL.md`
 - `plugins/olko-product/skills/viral-launch/SKILL.md`

package/adapters/pi/olko-product/README.md

@@ -0,0 +1,7 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+# Pi adapter: olko-product
+
+Use the canonical skills directly:
+
+- `plugins/olko-product/skills/frontend-direction/SKILL.md`

package/catalog/skills.json

@@ -587,6 +587,30 @@
             "hermes"
           ]
         },
+        {
+          "name": "frontend-direction",
+          "lookupName": "olko:frontend-direction",
+          "path": "plugins/olko-product/skills/frontend-direction",
+          "description": "Choose a distinctive, coherent visual direction and source-backed components before building a new frontend, page, or substantial UI redesign. Use for frontend implementation and requests to make an interface less generic; keep small fixes within the existing design.",
+          "tags": [
+            "frontend",
+            "design",
+            "components",
+            "art-direction",
+            "ui"
+          ],
+          "adapters": [
+            "codex",
+            "claude",
+            "cursor",
+            "copilot",
+            "windsurf",
+            "kiro",
+            "grok",
+            "hermes",
+            "pi"
+          ]
+        },
         {
           "name": "starter-rules",
           "lookupName": "olko:starter-rules",

package/docs/skill-anatomy.md

@@ -145,7 +145,7 @@ Current adapter targets:
 | `windsurf` | n/a | `.windsurf/rules/{name}.md` |
 | `kiro` | n/a | `.kiro/steering/{name}.md` |
 
-Adapter coverage is not uniform across the catalog; a skill only ships the adapters listed in its `adapters` array in `catalog/skills.json`. Current coverage: claude 55, grok 53, cursor 51, copilot 51, codex 49, windsurf 40, kiro 40, pi 2, hermes 55 (out of 55 canonical skills). Hermes uses `scripts/install-hermes-symlinks.sh` to expose the canonical packages to its skills loader.
+Adapter coverage is not uniform across the catalog; a skill only ships the adapters listed in its `adapters` array in `catalog/skills.json`. Current coverage: claude 56, grok 54, cursor 52, copilot 52, codex 50, windsurf 41, kiro 41, pi 3, hermes 56 (out of 56 canonical skills). Hermes uses `scripts/install-hermes-symlinks.sh` to expose the canonical packages to its skills loader.
 
 Claude plugin and marketplace identifiers must be kebab-case. Keep `olko:*` names for Codex and Cursor lookup names, but do not use colons or spaces in Claude marketplace/plugin names.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@olegkoval/agent-skills",
-  "version": "1.56.1",
+  "version": "1.57.0",
   "private": false,
   "publishConfig": {
     "access": "public"

package/plugins/olko-apple-kit/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-apple-kit",
   "description": "Build and ship Apple platform apps: macOS menubar apps, App Store submissions.",
-  "version": "1.56.1",
+  "version": "1.57.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-creative/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-creative",
   "description": "Creative and personal projects: photo galleries, music players, listings, wiki editing.",
-  "version": "1.56.1",
+  "version": "1.57.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-garmin-kit/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-garmin-kit",
   "description": "Build, test and publish Garmin Connect IQ watch faces.",
-  "version": "1.56.1",
+  "version": "1.57.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-git-tools/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-git-tools",
   "description": "Everyday git and GitHub CLI operations: conventional commits, branch hygiene.",
-  "version": "1.56.1",
+  "version": "1.57.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-github-pr/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-github-pr",
   "description": "Drive GitHub pull requests to merge-ready: review-bot loops, CI fixes, descriptions, dependency triage.",
-  "version": "1.56.1",
+  "version": "1.57.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-obsidian/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-obsidian",
   "description": "Keep an Obsidian vault in sync with work: PR sync, task rollover, morning routine.",
-  "version": "1.56.1",
+  "version": "1.57.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-product/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-product",
   "description": "Take a product idea to a shippable build: MVP passes, full-stack scaffolds, UX/UI quality loops, launch plans.",
-  "version": "1.56.1",
+  "version": "1.57.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-product/skills/frontend-direction/README.md

@@ -0,0 +1,54 @@
+# Frontend direction (beta)
+
+Give your coding agent a visual direction before it writes the frontend.
+
+For new pages and substantial redesigns, this skill chooses a composition, selects compatible components, records the decisions and checks the rendered result. Small UI fixes stay within the existing design. The reference catalog includes the seven resources from [Nero's post](https://x.com/neropursue/status/2109514246853677192).
+
+Status: experimental. Skill structure is validated; comparative visual-quality evaluation and end-to-end trials in all four agents are still pending.
+
+## Install
+
+The skill ships in the `olko-product` plugin. In Claude Code:
+
+```
+/plugin marketplace add oleg-koval/agent-skills
+/plugin install olko-product@olko-agent-skills
+```
+
+For Codex, Pi, Hermes and the other agents, follow the install steps for that agent in the [repository README](../../../../README.md).
+
+## Activate before frontend work
+
+Start a new session after installation. Explicit invocation avoids relying on the model to select the skill:
+
+| Agent | Prompt |
+| --- | --- |
+| Pi | `/skill:frontend-direction Build this page; choose the direction before coding.` |
+| Codex | `$frontend-direction Build this page; choose the direction before coding.` |
+| Claude Code | `/olko-product:frontend-direction Build this page; choose the direction before coding.` |
+| Hermes | `/frontend-direction Build this page; choose the direction before coding.` |
+
+For routine use, add this instruction to the project's active agent instructions: `AGENTS.md` for Codex and Pi, `CLAUDE.md` for Claude Code, and the active project context file for Hermes. Hermes can prioritize `.hermes.md` or `AGENTS.override.md` over `AGENTS.md`; put the rule in the file actually loaded.
+
+> Before implementing a frontend page or substantial UI redesign, load and follow the installed frontend-direction skill. State the chosen visual direction and component sources before coding. For small UI fixes, use its lightweight path and preserve the existing design. If the skill is unavailable, report that and use the project's existing design guidance.
+
+This is an instruction-level requirement, not a runtime enforcement hook. Check that the agent actually loads the skill and states a direction on the first frontend task. Do not assume discovery proves usage or visual quality. Installing the plugin does not modify project instructions.
+
+## Compatibility sources
+
+One portable skill folder serves all four agents. The workflow uses capabilities rather than vendor tool names, and keeps automatic discovery enabled. Browsing and browser inspection remain optional capabilities with explicit verification limits.
+
+- [Pi skill discovery and explicit invocation](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/docs/skills.md)
+- [Pi configuration directory](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/src/config.ts)
+- [Codex skills](https://developers.openai.com/codex/skills/)
+- [Claude Code skills](https://code.claude.com/docs/en/skills)
+- [Hermes skills and profiles](https://hermes-agent.nousresearch.com/docs/user-guide/features/skills/)
+- [Hermes project context](https://hermes-agent.nousresearch.com/docs/user-guide/features/context-files/)
+
+Record the installed plugin version when reporting results. For reproducible trials, keep the same installed copy throughout the comparison.
+
+## What to evaluate
+
+Use the same brief, content, model and budget with and without the skill. Compare hierarchy, coherence, task clarity, distinctiveness, mobile behavior and dependency cost. Save the selected direction and screenshots. Include a small-edit case to check that the skill does not force a redesign. Report browser-verification limits honestly.
+
+Only this skill folder is installed; no component library or paid resource is installed automatically.

package/plugins/olko-product/skills/frontend-direction/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: frontend-direction
+description: Choose a distinctive, coherent visual direction and source-backed components before building a new frontend, page, or substantial UI redesign. Use for frontend implementation and requests to make an interface less generic; keep small fixes within the existing design.
+license: MIT
+metadata:
+  author: Oleg Koval
+  tags: frontend, design, components, art-direction
+---
+
+# Frontend direction
+
+For Pi, Codex, Claude Code and Hermes, using the existing frontend stack. Use the host's available file, shell, browsing and image-inspection tools; no provider-specific tool names or plugins are required. Resolve bundled reference paths relative to this skill folder. Browsing and browser inspection improve source selection and visual verification; their absence must be reported, not disguised as verification.
+
+Make a deliberate visual choice before writing interface code. Deliver a recognizable composition that serves this product's users, with components that belong together. Distinctiveness can come from typography, imagery, spatial hierarchy, content or interaction; it does not require animation or new dependencies.
+
+## Match the effort to the task
+
+For a new page or substantial redesign, use the workflow below. For a small fix, reuse the established components and tokens and verify the affected state. Do not turn a spacing correction into a redesign or browse libraries on every turn. If another design skill supplies an approved direction, use it and perform the component selection here without repeating discovery.
+
+Read the relevant application instructions, stack, existing components and visual conventions. Inspect the current screen when available. Infer the audience, primary action, content density and constraints from the task. Ask only when a missing decision materially changes the result; otherwise state the assumption and proceed within the user's authorization.
+
+## Choose the direction before the components
+
+For an open-ended brief, consider two or three genuinely different compositions and choose the strongest fit. A color swap is not a different direction. A buyer comparing evidence may need an inspection workspace; a photographer may need an image-led editorial sequence. Avoid defaulting every product to a centered hero followed by identical cards.
+
+Briefly state the choice and why it helps the primary task. Do not require approval unless the user requested a design checkpoint or the choice would change their scope or brand. Respect supplied designs and existing systems.
+
+Define the visual anchors: layout and hierarchy, typography roles, palette, density, image treatment, and motion purpose. Reuse tokens where possible. Choose one or two signature treatments for emphasis, such as an annotated comparison rail or an editorial image sequence. Keep frequent controls familiar. Treat these as a default attention budget, not a prohibition on expressive briefs.
+
+## Select a coherent component set
+
+Read [references/sources.md](references/sources.md) when external references would improve the result. If that file is not bundled with your copy of this skill, read the [published catalog](https://github.com/oleg-koval/agent-skills/blob/main/plugins/olko-product/skills/frontend-direction/references/sources.md) instead. The catalog is a starting point, not a required dependency list. Existing project components and a small custom implementation are valid choices.
+
+Start with at most three relevant candidates. Expand only if none fits. Judge task fit, visual coherence, stack compatibility, accessibility, dependency cost and reuse terms. Do not rank novelty above usability or invent numeric scores that imply measurement.
+
+Inspect the exact official component page and available source before copying or installing. Record the URL, intended adaptation, dependencies, and known license or paid-access boundary. Unknown terms mean do not copy that source until clarified; use existing primitives or an original implementation instead. A screenshot or a social recommendation does not verify source availability or accessibility. Inspect registry payloads and install commands before execution.
+
+Prefer one primary component family per surface. Borrow an isolated interaction from another source only when it can share the same typography, spacing, radius, color and motion conventions. Never add a framework merely to use a decorative component. If browsing fails, label references unverified, use local primitives, and continue without claiming live checks.
+
+Before substantial implementation, leave a compact decision record in the task's existing plan, or in the response if no plan exists:
+
+| UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
+| --- | --- | --- | --- | --- |
+| Primary comparison | Aligned comparison rows | Existing table primitive | Makes differences scanable | Shared column widths; no dependency |
+
+Record the chosen direction and the most relevant rejected alternative with its reason. Reuse this decision on later turns; revisit only when evidence or requirements change. Do not create a new document for every small edit.
+
+## Build the composition, then inspect it
+
+Implement one representative section with realistic content before repeating it across the page. Establish shared tokens, responsive behavior and meaningful hierarchy there. Keep the product's actual states, including loading, empty, error, long text and unknown data. Decorative charts and invented statistics are not a substitute for content.
+
+Use motion to explain a transition or provide feedback. Preserve keyboard focus, semantics and immediate response; support reduced motion and interruption. Never hide essential content behind hover or animation.
+
+Inspect the rendered screen at desktop and narrow mobile sizes when browser tools are available. Check the primary action, text hierarchy, contrast, keyboard use, overflow, long content and relevant failure states. Compare the result with the chosen direction: does its composition still express it, or did it collapse into repeated generic cards? Is the signature treatment useful and proportionate?
+
+Make one focused correction pass for observed issues. Continue only for a specific unresolved defect, rather than redesigning indefinitely. Run the project's relevant checks. If visual inspection is unavailable, report that limit explicitly and distinguish code checks from visual acceptance.
+
+Report the direction, components and sources selected, dependencies added, and what was actually verified. This skill does not authorize deployment, publication or purchases.

package/plugins/olko-product/skills/frontend-direction/references/sources.md

@@ -0,0 +1,36 @@
+# Component discovery sources
+
+Seed: [Nero's resource post](https://x.com/neropursue/status/2109514246853677192), retrieved on 2026-10-12 through [FxTwitter](https://api.fxtwitter.com/status/2109514246853677192) after X returned 403. The categories below describe discovery uses, not guarantees about current features, compatibility, accessibility, pricing or licenses. Check the exact source before adoption.
+
+| Source | Start here when exploring |
+| --- | --- |
+| [Affect UI](https://affectui.com) | General visual component references |
+| [Kobra](https://kobra.systems) | Controls, navigation and product interactions |
+| [Arc UI](https://uiarc.dev) | UI composition and component ideas |
+| [EvilCharts](https://evilcharts.com) | Charts for real quantitative questions |
+| [Transitions.dev](https://transitions.dev) | State transitions and motion recipes |
+| [beUI](https://beui.dev) | Animated React component candidates |
+| [BoardUI](https://www.boardui.com) | Dashboard component candidates |
+
+The official Kobra, Transitions.dev and beUI sites were accessible during this skill's creation. The other entries are retained as discovery links from the post, not independently verified endorsements. No upstream component source or recipe is bundled here.
+
+For each selected candidate, inspect its exact documentation and source, not only its homepage. Verify framework/version requirements, dependencies, responsive states, keyboard behavior, reduced-motion handling where relevant, and reuse terms. Paid sections and free sections may have different conditions.
+
+Use the source that answers the task. A native HTML app can implement an original CSS interaction; a chart library is unnecessary when a comparison table is clearer. If no candidate fits, retain local components and derive distinctiveness from composition, content and typography.
+
+Seed: [Aman Singh's resource post](https://x.com/amananimates/status/2111848675811225980?s=46), retrieved on 2026-10-19 through [FxTwitter](https://api.fxtwitter.com/status/2111848675811225980) after X returned 403. The categories below describe discovery uses, not guarantees about current features, compatibility, accessibility, pricing or licenses. Check the exact source before adoption.
+
+| Source | Start here when exploring |
+| --- | --- |
+| [Scrolltide](https://scrolltide.co) | Prompts and source-code resources for interface design |
+| [Mobbin](https://mobbin.com) | Real-world UI patterns from iOS and Android apps |
+| [Fontshare](https://fontshare.com) | Free, high-quality fonts for commercial use |
+| [Coolors](https://coolors.co) | Fast color scheme generation and exploration |
+| [Spline](https://spline.design) | Interactive 3D design and web publishing |
+| [LottieFiles](https://lottiefiles.com) | Lottie animations for web and mobile |
+| [Three.js Journey](https://threejs-journey.com) | Step-by-step Three.js tutorials and examples |
+| [3Dicons](https://3dicons.co) | Free 3D icons for websites and applications |
+
+For each selected candidate, inspect its exact documentation and source, not only its homepage. Verify framework/version requirements, dependencies, responsive states, keyboard behavior, reduced-motion handling where relevant, and reuse terms. Paid sections and free sections may have different conditions.
+
+Use the source that answers the task. A native HTML app can implement an original CSS interaction; a chart library is unnecessary when a comparison table is clearer. If no candidate fits, retain local components and derive distinctiveness from composition, content and typography.

package/plugins/olko-reflection/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-reflection",
   "description": "Look back and improve: self-critique, retrospectives, performance review, rapid learning.",
-  "version": "1.56.1",
+  "version": "1.57.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-release/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-release",
   "description": "Ship a release: semantic-release setup, changelogs, store listing copy, release-day routine.",
-  "version": "1.56.1",
+  "version": "1.57.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-skill-meta/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-skill-meta",
   "description": "Author and maintain agent skills and the AI toolchain itself.",
-  "version": "1.56.1",
+  "version": "1.57.0",
   "author": {
     "name": "Oleg Koval"
   },

package/plugins/olko-web-ops/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-web-ops",
   "description": "Operate a website: WAF rules, search console audits, analytics bootstrap, docs indexes.",
-  "version": "1.56.1",
+  "version": "1.57.0",
   "author": {
     "name": "Oleg Koval"
   },

package/scripts/lib/catalog.mjs

@@ -20,7 +20,7 @@ export const PLUGIN_ASSIGNMENT = {
   },
   'olko-product': {
     description: 'Take a product idea to a shippable build: MVP passes, full-stack scaffolds, UX/UI quality loops, launch plans.',
-    skills: ['product-builder', 'mvp-oneshot', 'ux-ui-audit-loop', 'starter-rules', 'viral-launch'],
+    skills: ['product-builder', 'mvp-oneshot', 'ux-ui-audit-loop', 'frontend-direction', 'starter-rules', 'viral-launch'],
   },
   'olko-skill-meta': {
     description: 'Author and maintain agent skills and the AI toolchain itself.',