@olegkoval/agent-skills 1.57.0 → 1.58.1

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

@@ -18,11 +18,22 @@ For a new page or substantial redesign, use the workflow below. For a small fix,
 
 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
+## State the direction and component choices before coding
+
+For a new page or substantial redesign, make a visible pre-code decision record before the first UI implementation edit. Put it in the existing task plan or in the response; when neither exists, state it in the response. This is a required workflow checkpoint, not a request for user approval: state the choice, then continue autonomously unless the user asked to review it first.
+
+The record must name:
+
+- the chosen composition and why it serves the task;
+- the visual anchors: hierarchy, typography, palette, density, image treatment, and motion purpose;
+- the component or pattern for the primary UI roles, with a source URL or local path and any dependency or licensing cost;
+- one relevant alternative considered and why it was rejected.
+
+Do not create or edit UI implementation files until this record is present. If the user requests immediate implementation, include the record immediately before making the first UI edit. For an existing task plan, update it instead of creating another document. Keep the record compact and skip details that do not apply.
 
 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.
+Respect supplied designs and existing systems. Do not require approval for an ordinary direction choice unless the user requested a design checkpoint or the choice would change their scope or brand.
 
 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.
 
@@ -36,7 +47,7 @@ Inspect the exact official component page and available source before copying or
 
 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:
+In the pre-code record, use a compact table for the component decisions when there are multiple UI roles:
 
 | UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
 | --- | --- | --- | --- | --- |

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

@@ -17,11 +17,22 @@ For a new page or substantial redesign, use the workflow below. For a small fix,
 
 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
+## State the direction and component choices before coding
+
+For a new page or substantial redesign, make a visible pre-code decision record before the first UI implementation edit. Put it in the existing task plan or in the response; when neither exists, state it in the response. This is a required workflow checkpoint, not a request for user approval: state the choice, then continue autonomously unless the user asked to review it first.
+
+The record must name:
+
+- the chosen composition and why it serves the task;
+- the visual anchors: hierarchy, typography, palette, density, image treatment, and motion purpose;
+- the component or pattern for the primary UI roles, with a source URL or local path and any dependency or licensing cost;
+- one relevant alternative considered and why it was rejected.
+
+Do not create or edit UI implementation files until this record is present. If the user requests immediate implementation, include the record immediately before making the first UI edit. For an existing task plan, update it instead of creating another document. Keep the record compact and skip details that do not apply.
 
 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.
+Respect supplied designs and existing systems. Do not require approval for an ordinary direction choice unless the user requested a design checkpoint or the choice would change their scope or brand.
 
 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.
 
@@ -35,7 +46,7 @@ Inspect the exact official component page and available source before copying or
 
 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:
+In the pre-code record, use a compact table for the component decisions when there are multiple UI roles:
 
 | UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
 | --- | --- | --- | --- | --- |

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

@@ -16,11 +16,22 @@ For a new page or substantial redesign, use the workflow below. For a small fix,
 
 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
+## State the direction and component choices before coding
+
+For a new page or substantial redesign, make a visible pre-code decision record before the first UI implementation edit. Put it in the existing task plan or in the response; when neither exists, state it in the response. This is a required workflow checkpoint, not a request for user approval: state the choice, then continue autonomously unless the user asked to review it first.
+
+The record must name:
+
+- the chosen composition and why it serves the task;
+- the visual anchors: hierarchy, typography, palette, density, image treatment, and motion purpose;
+- the component or pattern for the primary UI roles, with a source URL or local path and any dependency or licensing cost;
+- one relevant alternative considered and why it was rejected.
+
+Do not create or edit UI implementation files until this record is present. If the user requests immediate implementation, include the record immediately before making the first UI edit. For an existing task plan, update it instead of creating another document. Keep the record compact and skip details that do not apply.
 
 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.
+Respect supplied designs and existing systems. Do not require approval for an ordinary direction choice unless the user requested a design checkpoint or the choice would change their scope or brand.
 
 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.
 
@@ -34,7 +45,7 @@ Inspect the exact official component page and available source before copying or
 
 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:
+In the pre-code record, use a compact table for the component decisions when there are multiple UI roles:
 
 | UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
 | --- | --- | --- | --- | --- |

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

@@ -20,11 +20,22 @@ For a new page or substantial redesign, use the workflow below. For a small fix,
 
 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
+## State the direction and component choices before coding
+
+For a new page or substantial redesign, make a visible pre-code decision record before the first UI implementation edit. Put it in the existing task plan or in the response; when neither exists, state it in the response. This is a required workflow checkpoint, not a request for user approval: state the choice, then continue autonomously unless the user asked to review it first.
+
+The record must name:
+
+- the chosen composition and why it serves the task;
+- the visual anchors: hierarchy, typography, palette, density, image treatment, and motion purpose;
+- the component or pattern for the primary UI roles, with a source URL or local path and any dependency or licensing cost;
+- one relevant alternative considered and why it was rejected.
+
+Do not create or edit UI implementation files until this record is present. If the user requests immediate implementation, include the record immediately before making the first UI edit. For an existing task plan, update it instead of creating another document. Keep the record compact and skip details that do not apply.
 
 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.
+Respect supplied designs and existing systems. Do not require approval for an ordinary direction choice unless the user requested a design checkpoint or the choice would change their scope or brand.
 
 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.
 
@@ -38,7 +49,7 @@ Inspect the exact official component page and available source before copying or
 
 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:
+In the pre-code record, use a compact table for the component decisions when there are multiple UI roles:
 
 | UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
 | --- | --- | --- | --- | --- |

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

@@ -20,11 +20,22 @@ For a new page or substantial redesign, use the workflow below. For a small fix,
 
 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
+## State the direction and component choices before coding
+
+For a new page or substantial redesign, make a visible pre-code decision record before the first UI implementation edit. Put it in the existing task plan or in the response; when neither exists, state it in the response. This is a required workflow checkpoint, not a request for user approval: state the choice, then continue autonomously unless the user asked to review it first.
+
+The record must name:
+
+- the chosen composition and why it serves the task;
+- the visual anchors: hierarchy, typography, palette, density, image treatment, and motion purpose;
+- the component or pattern for the primary UI roles, with a source URL or local path and any dependency or licensing cost;
+- one relevant alternative considered and why it was rejected.
+
+Do not create or edit UI implementation files until this record is present. If the user requests immediate implementation, include the record immediately before making the first UI edit. For an existing task plan, update it instead of creating another document. Keep the record compact and skip details that do not apply.
 
 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.
+Respect supplied designs and existing systems. Do not require approval for an ordinary direction choice unless the user requested a design checkpoint or the choice would change their scope or brand.
 
 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.
 
@@ -38,7 +49,7 @@ Inspect the exact official component page and available source before copying or
 
 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:
+In the pre-code record, use a compact table for the component decisions when there are multiple UI roles:
 
 | UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
 | --- | --- | --- | --- | --- |

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

@@ -20,11 +20,22 @@ For a new page or substantial redesign, use the workflow below. For a small fix,
 
 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
+## State the direction and component choices before coding
+
+For a new page or substantial redesign, make a visible pre-code decision record before the first UI implementation edit. Put it in the existing task plan or in the response; when neither exists, state it in the response. This is a required workflow checkpoint, not a request for user approval: state the choice, then continue autonomously unless the user asked to review it first.
+
+The record must name:
+
+- the chosen composition and why it serves the task;
+- the visual anchors: hierarchy, typography, palette, density, image treatment, and motion purpose;
+- the component or pattern for the primary UI roles, with a source URL or local path and any dependency or licensing cost;
+- one relevant alternative considered and why it was rejected.
+
+Do not create or edit UI implementation files until this record is present. If the user requests immediate implementation, include the record immediately before making the first UI edit. For an existing task plan, update it instead of creating another document. Keep the record compact and skip details that do not apply.
 
 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.
+Respect supplied designs and existing systems. Do not require approval for an ordinary direction choice unless the user requested a design checkpoint or the choice would change their scope or brand.
 
 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.
 
@@ -38,7 +49,7 @@ Inspect the exact official component page and available source before copying or
 
 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:
+In the pre-code record, use a compact table for the component decisions when there are multiple UI roles:
 
 | UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
 | --- | --- | --- | --- | --- |

package/docs/frontend-direction-evaluation-2026-10-19.md

@@ -0,0 +1,30 @@
+# Frontend direction evaluation
+
+Date: 2026-10-19. This evaluation tests the released v1.57.0 skill. The pre-code checkpoint added in the current PR has not yet been behaviorally re-tested.
+
+## Runtime results
+
+| Agent | Skill discovery | Frontend build | Direction and component choices before first UI edit | Small UI fix |
+| --- | --- | --- | --- | --- |
+| Codex | Passed; transcript read installed skill | Passed | Passed | Passed; changed only the requested 8px to 12px spacing |
+| Claude Code | Passed; skill invoked | Passed | Not demonstrated; direction was reported after first UI edit | Passed; changed only the requested 8px to 12px spacing |
+| Pi | Passed; native loader found the skill | Deferred; no authenticated provider | Unknown | Deferred |
+| Hermes | Passed; native skill index found the skill | Deferred; no connected provider | Unknown | Deferred |
+
+Pi and Hermes model trials were explicitly deferred pending provider authentication. Their discovery checks do not establish behavior during a model run.
+
+## Controlled comparison
+
+The paired pages use the same fictional coffee storefront brief, content, tool permissions, model (`claude-sonnet-5-5`), medium effort, and run limits. The intended difference is skill availability. Neither generated page was hand-polished.
+
+![Before and after frontend-direction comparison](assets/frontend-direction-comparison-2026-10-19.png)
+
+Both pages passed browser checks for filtering, bag count, keyboard focus, and 390px mobile overflow. The skill-assisted page uses a more editorial composition and horizontal coffee rows, with additional scrolling. This is one paired demonstration, not a benchmark or evidence that the treatment is universally better; no blinded human preference test was run.
+
+The self-contained brief used no external assets or dependencies. This does not validate integration with an existing component library. Raw model transcripts are not included in the repository.
+
+## Follow-up validation
+
+- Re-run Claude against the updated skill and verify the required decision record appears before the first UI edit. An attempted rerun after this edit stopped immediately: the local Claude CLI returned `Not logged in` before generating a response or consuming model tokens.
+- Run authenticated Pi and Hermes trials when providers are available.
+- Repeat with a project that already uses a component library to assess source selection and compatibility.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@olegkoval/agent-skills",
-  "version": "1.57.0",
+  "version": "1.58.1",
   "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.57.0",
+  "version": "1.58.1",
   "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.57.0",
+  "version": "1.58.1",
   "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.57.0",
+  "version": "1.58.1",
   "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.57.0",
+  "version": "1.58.1",
   "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.57.0",
+  "version": "1.58.1",
   "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.57.0",
+  "version": "1.58.1",
   "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.57.0",
+  "version": "1.58.1",
   "author": {
     "name": "Oleg Koval"
   },

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

@@ -4,7 +4,7 @@ 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.
+Status: experimental beta. Discovery passes in all four agents. Codex and Claude Code produced functional pages and passed the small-fix case; Codex stated its direction before coding, while Claude did not demonstrate that checkpoint before its first UI edit. This update makes the checkpoint explicit. Pi and Hermes model trials remain deferred because provider authentication is unavailable. See the [evaluation and controlled comparison](../../../../docs/frontend-direction-evaluation-2026-10-19.md). The updated checkpoint still needs a Claude rerun; the current Claude CLI returned `Not logged in` before generating a response.
 
 ## Install
 
@@ -30,7 +30,7 @@ Start a new session after installation. Explicit invocation avoids relying on th
 
 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.
+> Before editing UI implementation files for a new page or substantial redesign, load and follow the installed frontend-direction skill. State the chosen composition, visual anchors, component choices and sources, and a relevant rejected alternative. Then continue without waiting for approval unless a design checkpoint was requested. 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.
 

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

@@ -19,11 +19,22 @@ For a new page or substantial redesign, use the workflow below. For a small fix,
 
 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
+## State the direction and component choices before coding
+
+For a new page or substantial redesign, make a visible pre-code decision record before the first UI implementation edit. Put it in the existing task plan or in the response; when neither exists, state it in the response. This is a required workflow checkpoint, not a request for user approval: state the choice, then continue autonomously unless the user asked to review it first.
+
+The record must name:
+
+- the chosen composition and why it serves the task;
+- the visual anchors: hierarchy, typography, palette, density, image treatment, and motion purpose;
+- the component or pattern for the primary UI roles, with a source URL or local path and any dependency or licensing cost;
+- one relevant alternative considered and why it was rejected.
+
+Do not create or edit UI implementation files until this record is present. If the user requests immediate implementation, include the record immediately before making the first UI edit. For an existing task plan, update it instead of creating another document. Keep the record compact and skip details that do not apply.
 
 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.
+Respect supplied designs and existing systems. Do not require approval for an ordinary direction choice unless the user requested a design checkpoint or the choice would change their scope or brand.
 
 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.
 
@@ -37,7 +48,7 @@ Inspect the exact official component page and available source before copying or
 
 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:
+In the pre-code record, use a compact table for the component decisions when there are multiple UI roles:
 
 | UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
 | --- | --- | --- | --- | --- |

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.57.0",
+  "version": "1.58.1",
   "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.57.0",
+  "version": "1.58.1",
   "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.57.0",
+  "version": "1.58.1",
   "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.57.0",
+  "version": "1.58.1",
   "author": {
     "name": "Oleg Koval"
   },