@olegkoval/agent-skills 1.3.1 → 1.4.0

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "olko-agent-skills",
   "description": "Agent-agnostic skill catalog for Codex, Claude, Cursor, and other skill-aware tools.",
-  "version": "1.3.0",
+  "version": "1.3.2",
   "author": {
     "name": "Oleg Koval"
   },
@@ -19,6 +19,7 @@
     "./packages/music/fill-music-player",
     "./packages/software-development/product-builder",
     "./packages/software-development/add-to-my-skills",
+    "./packages/software-development/starter-rules",
     "./packages/software-development/open-source-publisher",
     "./packages/marketing/viral-launch",
     "./packages/marketing/search-console-indexing-audit"

package/.cursor-plugin/index.json

@@ -51,6 +51,11 @@
       "source": "./packages/software-development/add-to-my-skills/adapters/cursor",
       "description": "Copy a newly created skill into this catalog, refresh manifests, and publish the change."
     },
+    {
+      "name": "olko:starter-rules",
+      "source": "./packages/software-development/starter-rules/adapters/cursor",
+      "description": "Load and enforce hard rules for every oleg-koval/* starter: 300-line files, E2E tests, pre-commit hooks, Vertical Slice architecture, no comments, KISS/DRY/SOLID."
+    },
     {
       "name": "olko:open-source-publisher",
       "source": "./packages/software-development/open-source-publisher/adapters/cursor",

package/catalog/skills.json

@@ -197,6 +197,28 @@
         "copilot"
       ]
     },
+    {
+      "name": "starter-rules",
+      "lookupName": "olko:starter-rules",
+      "category": "software-development",
+      "path": "packages/software-development/starter-rules",
+      "description": "Load and enforce hard rules for every oleg-koval/* starter: 300-line files, E2E tests, pre-commit hooks, Vertical Slice architecture, no comments, KISS/DRY/SOLID.",
+      "tags": [
+        "starters",
+        "rules",
+        "architecture",
+        "vertical-slice",
+        "linting",
+        "pre-commit",
+        "testing"
+      ],
+      "adapters": [
+        "codex",
+        "claude",
+        "cursor",
+        "copilot"
+      ]
+    },
     {
       "name": "open-source-publisher",
       "lookupName": "olko:open-source-publisher",

package/package.json

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

package/packages/software-development/open-source-publisher/SKILL.md

@@ -34,24 +34,29 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
 3. Classify the repository type before recommending changes:
    - `library`, `CLI`, `web app`, `framework`, `docs site`, or `other`
    - use the type to decide whether governance, packaging, or presentation work should come first
-4. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
+4. Identify maintainer identity and public home information when they affect publishing:
+   - Ask for the GitHub handle or org name if the repo will have a public owner/maintainer identity, funding links, release notes, or badges
+   - Ask for a canonical website/homepage URL if the project needs a homepage, docs site, or public project URL
+   - If `homepage`, `author`, or org metadata already exists and looks current, do not ask again
+5. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
    - "You already have a terminal-style GitHub Pages site. Do you want to keep it or restyle it?"
    - "You already have an icon and social card. Do you want a refresh, or should I leave them as-is?"
    - "You already have release automation. Do you want me to audit only, or also tighten it?"
-5. Ask only for choices needed to fix missing or weak pieces:
+6. Ask only for choices needed to fix missing or weak pieces:
    - If GitHub Pages is missing or weak, ask for style: `oldschool linux`, `terminal`, `modern`, `brutalist`, `glassmorphism`, `y2k`, `hacker`, or custom.
    - If donation wiring is missing, ask whether to enable it: `none`, `GitHub Sponsors`, `Ko-fi`, `Buy Me a Coffee`, `Open Collective`, `Thanks.dev`, or custom URL.
    - If the repo has no clear product essence, ask for a one-sentence positioning statement.
-6. Implement only approved, missing, or weak work in this order:
+7. Implement only approved, missing, or weak work in this order:
    - OSS governance and support files
    - minimal icon
    - social preview image
    - README standard
    - GitHub Pages landing page
+   - GitHub Pages analytics setup, if requested
    - CI/CD and release audit/fixes
    - donation wiring, if requested
-7. Validate locally and with browser/screenshots when possible.
-8. Commit/push only when the user asks or the current task explicitly requires it.
+8. Validate locally and with browser/screenshots when possible.
+9. Commit/push only when the user asks or the current task explicitly requires it.
 
 ## Readiness Audit
 
@@ -61,11 +66,15 @@ Publish-critical checklist:
 
 - repository identity: clear project name, description, topic/keywords, author, license
 - install path: package manager, release assets, source build, or direct download instructions
+- maintainer identity: GitHub handle or org name when public identity is relevant
+- public home: canonical website/homepage URL when the project needs one
+- if either field does not exist, proceed without it and mark it as absent
 - OSS governance: `LICENSE`, `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, support policy, issue/PR templates, changelog or release notes path
 - README standard: centered shields, icon, title, short description, horizontal rule, essential sections
-- icon: simple SVG mark, renders at small sizes, committed in a predictable path
-- social image: 1200x630 image with matching metadata, committed source when practical
+- icon: simple SVG mark plus rendered PNG, both committed in predictable paths
+- social image: 1200x630 image with matching metadata, with both SVG source and rendered PNG committed when practical
 - GitHub Pages or docs site: essential install/examples/links/SEO/Open Graph metadata
+- GitHub Pages analytics: optional setup to track visitor patterns and engagement
 - CI quality gates: formatter, linter/static analysis, tests, build/package check
 - release automation: tags/releases/artifacts/package update flow, docs-only changes excluded where needed
 - security posture: license, security notes or policy, OpenSSF Scorecard or equivalent when appropriate
@@ -89,6 +98,8 @@ Missing
 
 Questions
 - You already have a terminal-style GitHub Pages site. Keep it, or restyle it?
+- What is the GitHub handle or org name for public attribution?
+- What is the canonical website or homepage URL, if any?
 - Donations are not configured. Enable them or leave them off?
 ```
 
@@ -102,7 +113,7 @@ Rules:
 
 ## Minimal Icon
 
-Create a simple, recognizable SVG logo from the repository's essence. Prefer `logo.svg`; add `logo.png` only when a platform requires raster output.
+Create a simple, recognizable SVG logo from the repository's essence. Prefer `logo.svg` and also render `logo.png` so the icon can be reused in README assets, release artifacts, and platform-specific previews.
 
 Icon rules:
 
@@ -112,6 +123,7 @@ Icon rules:
 - Use a simple rounded tile only when it improves favicon readability.
 - Avoid terminal window chrome, decorative dots, random badges, and center glyph clutter unless the project itself is a terminal/window tool.
 - Avoid generic AI tells: glass effects, bokeh/orbs, over-layered gradients, busy shadows, and unrelated emojis.
+- If the repo has a website or homepage, ensure the icon fits that visual system.
 
 Good icon pattern for sync/migration tools:
 
@@ -150,6 +162,7 @@ Recommended files:
 
 - `social-card.svg` as the editable source
 - `social-card.png` rendered from the SVG when render tooling is available
+- keep both files in the repo when practical so the preview can be updated without redrawing the whole asset
 
 Social image rules:
 
@@ -159,6 +172,7 @@ Social image rules:
 - Match the icon color system.
 - Keep all text inside a safe margin of at least 64px.
 - Use `og:image`, `twitter:image`, width/height meta tags, and meaningful alt text.
+- If the repo has a homepage or canonical website, make the social card and metadata point to that URL consistently.
 
 Render checks:
 
@@ -292,6 +306,49 @@ Implementation defaults:
 - Avoid marketing fluff and oversized hero sections for developer tools. Make the first viewport useful.
 - Use system UI fonts for body text and monospace only for commands, labels, or terminal-specific elements.
 
+## GitHub Pages Analytics
+
+Add basic analytics to track site visitor patterns and user behavior when the project has a GitHub Pages site.
+
+Setup options:
+
+- **Google Analytics** (free, detailed): Add UA or GA4 tracking ID to site `<head>`
+- **Plausible** (simple, privacy-first, paid): Lightweight script alternative
+- **Simple counter** (basic): Visitor count badge using Shields.io or statically-generated endpoint
+
+Minimal Google Analytics setup for static sites:
+
+```html
+<script async src="https://www.googletagmanager.com/gtag/js?id=G-YOUR_ID"></script>
+<script>
+  window.dataLayer = window.dataLayer || [];
+  function gtag(){dataLayer.push(arguments);}
+  gtag('js', new Date());
+  gtag('config', 'G-YOUR_ID');
+</script>
+```
+
+Track these essential events:
+
+- **pageview** (automatic): Site visitors and page sections
+- **download_release**: Clicks on install/download links (track each platform/format)
+- **view_docs**: Navigation to documentation pages
+- **github_click**: Click through to GitHub repo
+- **copy_command**: Code snippet copies in examples
+
+Optional custom events for OSS projects:
+
+- **search_docs**: If docs site has search
+- **view_example**: Specific example/use-case sections viewed
+- **support_click**: Link clicks to issues, discussions, or support channels
+
+Rules:
+
+- Add analytics after publishing the site; do not gate site launch on analytics.
+- If the user prefers privacy-first or no analytics, skip this step.
+- Store analytics credentials as GitHub Pages environment secret or site config, never in git.
+- Review monthly to catch unusual patterns or broken tracking links.
+
 ## CI/CD And Release Audit
 
 Check whether the repository has:

package/packages/software-development/open-source-publisher/adapters/claude/skills/open-source-publisher/SKILL.md

@@ -36,24 +36,29 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
 3. Classify the repository type before recommending changes:
    - `library`, `CLI`, `web app`, `framework`, `docs site`, or `other`
    - use the type to decide whether governance, packaging, or presentation work should come first
-4. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
+4. Identify maintainer identity and public home information when they affect publishing:
+   - Ask for the GitHub handle or org name if the repo will have a public owner/maintainer identity, funding links, release notes, or badges
+   - Ask for a canonical website/homepage URL if the project needs a homepage, docs site, or public project URL
+   - If `homepage`, `author`, or org metadata already exists and looks current, do not ask again
+5. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
    - "You already have a terminal-style GitHub Pages site. Do you want to keep it or restyle it?"
    - "You already have an icon and social card. Do you want a refresh, or should I leave them as-is?"
    - "You already have release automation. Do you want me to audit only, or also tighten it?"
-5. Ask only for choices needed to fix missing or weak pieces:
+6. Ask only for choices needed to fix missing or weak pieces:
    - If GitHub Pages is missing or weak, ask for style: `oldschool linux`, `terminal`, `modern`, `brutalist`, `glassmorphism`, `y2k`, `hacker`, or custom.
    - If donation wiring is missing, ask whether to enable it: `none`, `GitHub Sponsors`, `Ko-fi`, `Buy Me a Coffee`, `Open Collective`, `Thanks.dev`, or custom URL.
    - If the repo has no clear product essence, ask for a one-sentence positioning statement.
-6. Implement only approved, missing, or weak work in this order:
+7. Implement only approved, missing, or weak work in this order:
    - OSS governance and support files
    - minimal icon
    - social preview image
    - README standard
    - GitHub Pages landing page
+   - GitHub Pages analytics setup, if requested
    - CI/CD and release audit/fixes
    - donation wiring, if requested
-7. Validate locally and with browser/screenshots when possible.
-8. Commit/push only when the user asks or the current task explicitly requires it.
+8. Validate locally and with browser/screenshots when possible.
+9. Commit/push only when the user asks or the current task explicitly requires it.
 
 ## Readiness Audit
 
@@ -63,11 +68,15 @@ Publish-critical checklist:
 
 - repository identity: clear project name, description, topic/keywords, author, license
 - install path: package manager, release assets, source build, or direct download instructions
+- maintainer identity: GitHub handle or org name when public identity is relevant
+- public home: canonical website/homepage URL when the project needs one
+- if either field does not exist, proceed without it and mark it as absent
 - OSS governance: `LICENSE`, `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, support policy, issue/PR templates, changelog or release notes path
 - README standard: centered shields, icon, title, short description, horizontal rule, essential sections
-- icon: simple SVG mark, renders at small sizes, committed in a predictable path
-- social image: 1200x630 image with matching metadata, committed source when practical
+- icon: simple SVG mark plus rendered PNG, both committed in predictable paths
+- social image: 1200x630 image with matching metadata, with both SVG source and rendered PNG committed when practical
 - GitHub Pages or docs site: essential install/examples/links/SEO/Open Graph metadata
+- GitHub Pages analytics: optional setup to track visitor patterns and engagement
 - CI quality gates: formatter, linter/static analysis, tests, build/package check
 - release automation: tags/releases/artifacts/package update flow, docs-only changes excluded where needed
 - security posture: license, security notes or policy, OpenSSF Scorecard or equivalent when appropriate
@@ -91,6 +100,8 @@ Missing
 
 Questions
 - You already have a terminal-style GitHub Pages site. Keep it, or restyle it?
+- What is the GitHub handle or org name for public attribution?
+- What is the canonical website or homepage URL, if any?
 - Donations are not configured. Enable them or leave them off?
 ```
 
@@ -104,7 +115,7 @@ Rules:
 
 ## Minimal Icon
 
-Create a simple, recognizable SVG logo from the repository's essence. Prefer `logo.svg`; add `logo.png` only when a platform requires raster output.
+Create a simple, recognizable SVG logo from the repository's essence. Prefer `logo.svg` and also render `logo.png` so the icon can be reused in README assets, release artifacts, and platform-specific previews.
 
 Icon rules:
 
@@ -114,6 +125,7 @@ Icon rules:
 - Use a simple rounded tile only when it improves favicon readability.
 - Avoid terminal window chrome, decorative dots, random badges, and center glyph clutter unless the project itself is a terminal/window tool.
 - Avoid generic AI tells: glass effects, bokeh/orbs, over-layered gradients, busy shadows, and unrelated emojis.
+- If the repo has a website or homepage, ensure the icon fits that visual system.
 
 Good icon pattern for sync/migration tools:
 
@@ -152,6 +164,7 @@ Recommended files:
 
 - `social-card.svg` as the editable source
 - `social-card.png` rendered from the SVG when render tooling is available
+- keep both files in the repo when practical so the preview can be updated without redrawing the whole asset
 
 Social image rules:
 
@@ -161,6 +174,7 @@ Social image rules:
 - Match the icon color system.
 - Keep all text inside a safe margin of at least 64px.
 - Use `og:image`, `twitter:image`, width/height meta tags, and meaningful alt text.
+- If the repo has a homepage or canonical website, make the social card and metadata point to that URL consistently.
 
 Render checks:
 
@@ -294,6 +308,49 @@ Implementation defaults:
 - Avoid marketing fluff and oversized hero sections for developer tools. Make the first viewport useful.
 - Use system UI fonts for body text and monospace only for commands, labels, or terminal-specific elements.
 
+## GitHub Pages Analytics
+
+Add basic analytics to track site visitor patterns and user behavior when the project has a GitHub Pages site.
+
+Setup options:
+
+- **Google Analytics** (free, detailed): Add UA or GA4 tracking ID to site `<head>`
+- **Plausible** (simple, privacy-first, paid): Lightweight script alternative
+- **Simple counter** (basic): Visitor count badge using Shields.io or statically-generated endpoint
+
+Minimal Google Analytics setup for static sites:
+
+```html
+<script async src="https://www.googletagmanager.com/gtag/js?id=G-YOUR_ID"></script>
+<script>
+  window.dataLayer = window.dataLayer || [];
+  function gtag(){dataLayer.push(arguments);}
+  gtag('js', new Date());
+  gtag('config', 'G-YOUR_ID');
+</script>
+```
+
+Track these essential events:
+
+- **pageview** (automatic): Site visitors and page sections
+- **download_release**: Clicks on install/download links (track each platform/format)
+- **view_docs**: Navigation to documentation pages
+- **github_click**: Click through to GitHub repo
+- **copy_command**: Code snippet copies in examples
+
+Optional custom events for OSS projects:
+
+- **search_docs**: If docs site has search
+- **view_example**: Specific example/use-case sections viewed
+- **support_click**: Link clicks to issues, discussions, or support channels
+
+Rules:
+
+- Add analytics after publishing the site; do not gate site launch on analytics.
+- If the user prefers privacy-first or no analytics, skip this step.
+- Store analytics credentials as GitHub Pages environment secret or site config, never in git.
+- Review monthly to catch unusual patterns or broken tracking links.
+
 ## CI/CD And Release Audit
 
 Check whether the repository has:

package/packages/software-development/open-source-publisher/adapters/cursor/skills/open-source-publisher/SKILL.md

@@ -36,24 +36,29 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
 3. Classify the repository type before recommending changes:
    - `library`, `CLI`, `web app`, `framework`, `docs site`, or `other`
    - use the type to decide whether governance, packaging, or presentation work should come first
-4. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
+4. Identify maintainer identity and public home information when they affect publishing:
+   - Ask for the GitHub handle or org name if the repo will have a public owner/maintainer identity, funding links, release notes, or badges
+   - Ask for a canonical website/homepage URL if the project needs a homepage, docs site, or public project URL
+   - If `homepage`, `author`, or org metadata already exists and looks current, do not ask again
+5. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
    - "You already have a terminal-style GitHub Pages site. Do you want to keep it or restyle it?"
    - "You already have an icon and social card. Do you want a refresh, or should I leave them as-is?"
    - "You already have release automation. Do you want me to audit only, or also tighten it?"
-5. Ask only for choices needed to fix missing or weak pieces:
+6. Ask only for choices needed to fix missing or weak pieces:
    - If GitHub Pages is missing or weak, ask for style: `oldschool linux`, `terminal`, `modern`, `brutalist`, `glassmorphism`, `y2k`, `hacker`, or custom.
    - If donation wiring is missing, ask whether to enable it: `none`, `GitHub Sponsors`, `Ko-fi`, `Buy Me a Coffee`, `Open Collective`, `Thanks.dev`, or custom URL.
    - If the repo has no clear product essence, ask for a one-sentence positioning statement.
-6. Implement only approved, missing, or weak work in this order:
+7. Implement only approved, missing, or weak work in this order:
    - OSS governance and support files
    - minimal icon
    - social preview image
    - README standard
    - GitHub Pages landing page
+   - GitHub Pages analytics setup, if requested
    - CI/CD and release audit/fixes
    - donation wiring, if requested
-7. Validate locally and with browser/screenshots when possible.
-8. Commit/push only when the user asks or the current task explicitly requires it.
+8. Validate locally and with browser/screenshots when possible.
+9. Commit/push only when the user asks or the current task explicitly requires it.
 
 ## Readiness Audit
 
@@ -63,11 +68,15 @@ Publish-critical checklist:
 
 - repository identity: clear project name, description, topic/keywords, author, license
 - install path: package manager, release assets, source build, or direct download instructions
+- maintainer identity: GitHub handle or org name when public identity is relevant
+- public home: canonical website/homepage URL when the project needs one
+- if either field does not exist, proceed without it and mark it as absent
 - OSS governance: `LICENSE`, `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, support policy, issue/PR templates, changelog or release notes path
 - README standard: centered shields, icon, title, short description, horizontal rule, essential sections
-- icon: simple SVG mark, renders at small sizes, committed in a predictable path
-- social image: 1200x630 image with matching metadata, committed source when practical
+- icon: simple SVG mark plus rendered PNG, both committed in predictable paths
+- social image: 1200x630 image with matching metadata, with both SVG source and rendered PNG committed when practical
 - GitHub Pages or docs site: essential install/examples/links/SEO/Open Graph metadata
+- GitHub Pages analytics: optional setup to track visitor patterns and engagement
 - CI quality gates: formatter, linter/static analysis, tests, build/package check
 - release automation: tags/releases/artifacts/package update flow, docs-only changes excluded where needed
 - security posture: license, security notes or policy, OpenSSF Scorecard or equivalent when appropriate
@@ -91,6 +100,8 @@ Missing
 
 Questions
 - You already have a terminal-style GitHub Pages site. Keep it, or restyle it?
+- What is the GitHub handle or org name for public attribution?
+- What is the canonical website or homepage URL, if any?
 - Donations are not configured. Enable them or leave them off?
 ```
 
@@ -104,7 +115,7 @@ Rules:
 
 ## Minimal Icon
 
-Create a simple, recognizable SVG logo from the repository's essence. Prefer `logo.svg`; add `logo.png` only when a platform requires raster output.
+Create a simple, recognizable SVG logo from the repository's essence. Prefer `logo.svg` and also render `logo.png` so the icon can be reused in README assets, release artifacts, and platform-specific previews.
 
 Icon rules:
 
@@ -114,6 +125,7 @@ Icon rules:
 - Use a simple rounded tile only when it improves favicon readability.
 - Avoid terminal window chrome, decorative dots, random badges, and center glyph clutter unless the project itself is a terminal/window tool.
 - Avoid generic AI tells: glass effects, bokeh/orbs, over-layered gradients, busy shadows, and unrelated emojis.
+- If the repo has a website or homepage, ensure the icon fits that visual system.
 
 Good icon pattern for sync/migration tools:
 
@@ -152,6 +164,7 @@ Recommended files:
 
 - `social-card.svg` as the editable source
 - `social-card.png` rendered from the SVG when render tooling is available
+- keep both files in the repo when practical so the preview can be updated without redrawing the whole asset
 
 Social image rules:
 
@@ -161,6 +174,7 @@ Social image rules:
 - Match the icon color system.
 - Keep all text inside a safe margin of at least 64px.
 - Use `og:image`, `twitter:image`, width/height meta tags, and meaningful alt text.
+- If the repo has a homepage or canonical website, make the social card and metadata point to that URL consistently.
 
 Render checks:
 
@@ -294,6 +308,49 @@ Implementation defaults:
 - Avoid marketing fluff and oversized hero sections for developer tools. Make the first viewport useful.
 - Use system UI fonts for body text and monospace only for commands, labels, or terminal-specific elements.
 
+## GitHub Pages Analytics
+
+Add basic analytics to track site visitor patterns and user behavior when the project has a GitHub Pages site.
+
+Setup options:
+
+- **Google Analytics** (free, detailed): Add UA or GA4 tracking ID to site `<head>`
+- **Plausible** (simple, privacy-first, paid): Lightweight script alternative
+- **Simple counter** (basic): Visitor count badge using Shields.io or statically-generated endpoint
+
+Minimal Google Analytics setup for static sites:
+
+```html
+<script async src="https://www.googletagmanager.com/gtag/js?id=G-YOUR_ID"></script>
+<script>
+  window.dataLayer = window.dataLayer || [];
+  function gtag(){dataLayer.push(arguments);}
+  gtag('js', new Date());
+  gtag('config', 'G-YOUR_ID');
+</script>
+```
+
+Track these essential events:
+
+- **pageview** (automatic): Site visitors and page sections
+- **download_release**: Clicks on install/download links (track each platform/format)
+- **view_docs**: Navigation to documentation pages
+- **github_click**: Click through to GitHub repo
+- **copy_command**: Code snippet copies in examples
+
+Optional custom events for OSS projects:
+
+- **search_docs**: If docs site has search
+- **view_example**: Specific example/use-case sections viewed
+- **support_click**: Link clicks to issues, discussions, or support channels
+
+Rules:
+
+- Add analytics after publishing the site; do not gate site launch on analytics.
+- If the user prefers privacy-first or no analytics, skip this step.
+- Store analytics credentials as GitHub Pages environment secret or site config, never in git.
+- Review monthly to catch unusual patterns or broken tracking links.
+
 ## CI/CD And Release Audit
 
 Check whether the repository has:

package/packages/software-development/starter-rules/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: starter-rules
+description: Load and enforce the hard rules every oleg-koval/* starter must obey. Use when starting or auditing work in saas-init, ts-npm-starter, go-starter, py-starter, or any future oleg-koval template repo. Covers functional style, 300-line file cap, E2E > unit tests, pre-commit hooks, no-comment policy, KISS/DRY/SOLID, and Vertical Slice as default architecture for SaaS/app starters.
+license: MIT
+compatibility: Codex, Claude Code, Cursor, and other Agent Skills compatible tools.
+metadata:
+  author: Oleg Koval
+  tags:
+    - starters
+    - rules
+    - architecture
+    - vertical-slice
+    - linting
+    - pre-commit
+---
+
+# Starter Rules
+
+## Overview
+
+Load the canonical hard rules for every `oleg-koval/*` starter repo and verify the current repo complies with them. Produces a compliance report and a list of gaps to fix.
+
+## When to Use
+
+- Starting a new coding session in any `oleg-koval/*` template repo
+- Auditing an existing starter for rule compliance before a release or PR merge
+- Onboarding a new contributor (human or AI) to a starter
+- After a large refactor, to verify rules have not been silently violated
+
+Do not use for repos outside the `oleg-koval` namespace unless they explicitly reference `RULES.md`.
+
+## Workflow
+
+1. **Load the rules** — read `RULES.md` from the repo root. If absent, fetch it from `https://github.com/oleg-koval/starters/blob/main/RULES.md` and note that the starter is missing a local copy.
+
+2. **Apply §2 hard rules** — for the current task or PR diff, verify:
+   - No file exceeds 300 lines (`find . -name '*.ts' -o -name '*.py' -o -name '*.go' | xargs wc -l | awk '$1 > 300 && $2 != "total"'`)
+   - No functions produce side effects outside of boundary layers
+   - New code has no WHAT-comments; WHY-comments are one line max
+   - Tests are E2E-first; unit tests only for pure logic with non-trivial branching
+
+3. **Verify hooks and lint** — check that pre-commit hooks are installed and configured:
+   - TypeScript: `cat .eslintrc* | grep max-lines` and `cat package.json | grep -A5 '"lint-staged"\|"husky"\|"lefthook"'`
+   - Python: `cat .pre-commit-config.yaml` and check for `ruff` + format hooks
+   - Go: `cat .golangci.yml` or `.pre-commit-config.yaml` and check for `golangci-lint` + `gofmt`
+
+4. **Check architecture** — for app/SaaS starters: confirm feature code is organized as vertical slices (feature directory contains handler + DTO + service + tests together). For library starters: skip.
+
+5. **Report gaps** — list any violations found in steps 2–4. For each gap:
+   - Name the rule (e.g., "§2.2 file length")
+   - Name the file and line count or violation
+   - Propose the minimal fix
+
+6. **Fix on request** — if the user asks to fix the gaps, apply them one at a time, smallest change first. Do not refactor beyond what the rule requires.
+
+## Reference
+
+Full rule details: [`RULES.md`](./RULES.md)
+
+Architecture options and future starters: `RULES.md §3`
+
+Unix principles: `RULES.md §4`
+
+## Verification
+
+- [ ] `RULES.md` was read from the repo root (or fetched and absence noted)
+- [ ] File length check ran with zero violations, or violations were listed
+- [ ] Pre-commit hooks verified as installed and configured
+- [ ] Compliance report produced listing passed checks and gaps
+- [ ] Any fixes applied do not exceed the scope of the violated rule

package/packages/software-development/starter-rules/adapters/claude/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "olko-starter-rules",
+  "description": "Load and enforce hard rules for every oleg-koval/* starter: 300-line files, E2E tests, pre-commit hooks, Vertical Slice architecture, no comments, KISS/DRY/SOLID.",
+  "skills": "./skills"
+}

package/packages/software-development/starter-rules/adapters/claude/skills/starter-rules/SKILL.md

@@ -0,0 +1,72 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+name: starter-rules
+description: Load and enforce the hard rules every oleg-koval/* starter must obey. Use when starting or auditing work in saas-init, ts-npm-starter, go-starter, py-starter, or any future oleg-koval template repo. Covers functional style, 300-line file cap, E2E > unit tests, pre-commit hooks, no-comment policy, KISS/DRY/SOLID, and Vertical Slice as default architecture for SaaS/app starters.
+license: MIT
+compatibility: Codex, Claude Code, Cursor, and other Agent Skills compatible tools.
+metadata:
+  author: Oleg Koval
+  tags:
+    - starters
+    - rules
+    - architecture
+    - vertical-slice
+    - linting
+    - pre-commit
+---
+
+# Starter Rules
+
+## Overview
+
+Load the canonical hard rules for every `oleg-koval/*` starter repo and verify the current repo complies with them. Produces a compliance report and a list of gaps to fix.
+
+## When to Use
+
+- Starting a new coding session in any `oleg-koval/*` template repo
+- Auditing an existing starter for rule compliance before a release or PR merge
+- Onboarding a new contributor (human or AI) to a starter
+- After a large refactor, to verify rules have not been silently violated
+
+Do not use for repos outside the `oleg-koval` namespace unless they explicitly reference `RULES.md`.
+
+## Workflow
+
+1. **Load the rules** — read `RULES.md` from the repo root. If absent, fetch it from `https://github.com/oleg-koval/starters/blob/main/RULES.md` and note that the starter is missing a local copy.
+
+2. **Apply §2 hard rules** — for the current task or PR diff, verify:
+   - No file exceeds 300 lines (`find . -name '*.ts' -o -name '*.py' -o -name '*.go' | xargs wc -l | awk '$1 > 300 && $2 != "total"'`)
+   - No functions produce side effects outside of boundary layers
+   - New code has no WHAT-comments; WHY-comments are one line max
+   - Tests are E2E-first; unit tests only for pure logic with non-trivial branching
+
+3. **Verify hooks and lint** — check that pre-commit hooks are installed and configured:
+   - TypeScript: `cat .eslintrc* | grep max-lines` and `cat package.json | grep -A5 '"lint-staged"\|"husky"\|"lefthook"'`
+   - Python: `cat .pre-commit-config.yaml` and check for `ruff` + format hooks
+   - Go: `cat .golangci.yml` or `.pre-commit-config.yaml` and check for `golangci-lint` + `gofmt`
+
+4. **Check architecture** — for app/SaaS starters: confirm feature code is organized as vertical slices (feature directory contains handler + DTO + service + tests together). For library starters: skip.
+
+5. **Report gaps** — list any violations found in steps 2–4. For each gap:
+   - Name the rule (e.g., "§2.2 file length")
+   - Name the file and line count or violation
+   - Propose the minimal fix
+
+6. **Fix on request** — if the user asks to fix the gaps, apply them one at a time, smallest change first. Do not refactor beyond what the rule requires.
+
+## Reference
+
+Full rule details: [`RULES.md`](./RULES.md)
+
+Architecture options and future starters: `RULES.md §3`
+
+Unix principles: `RULES.md §4`
+
+## Verification
+
+- [ ] `RULES.md` was read from the repo root (or fetched and absence noted)
+- [ ] File length check ran with zero violations, or violations were listed
+- [ ] Pre-commit hooks verified as installed and configured
+- [ ] Compliance report produced listing passed checks and gaps
+- [ ] Any fixes applied do not exceed the scope of the violated rule

package/packages/software-development/starter-rules/adapters/codex/README.md

@@ -0,0 +1,16 @@
+# Codex Adapter for starter-rules
+
+This is a Codex-specific adapter for the `olko:starter-rules` skill.
+The canonical skill definition is in `../../../SKILL.md`.
+
+## Usage
+
+Invoke in a Codex session:
+
+```
+Use the olko:starter-rules skill to load and enforce hard rules in this starter repo.
+```
+
+## Workflow
+
+See `../../../SKILL.md` for the full workflow.

package/packages/software-development/starter-rules/adapters/cursor/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "starter-rules",
+  "description": "Load and enforce hard rules for every oleg-koval/* starter: 300-line files, E2E tests, pre-commit hooks, Vertical Slice architecture, no comments, KISS/DRY/SOLID.",
+  "rules": ["packages/software-development/starter-rules/adapters/cursor/skills/starter-rules/SKILL.md"]
+}

package/packages/software-development/starter-rules/adapters/cursor/skills/starter-rules/SKILL.md

@@ -0,0 +1,72 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+name: starter-rules
+description: Load and enforce the hard rules every oleg-koval/* starter must obey. Use when starting or auditing work in saas-init, ts-npm-starter, go-starter, py-starter, or any future oleg-koval template repo. Covers functional style, 300-line file cap, E2E > unit tests, pre-commit hooks, no-comment policy, KISS/DRY/SOLID, and Vertical Slice as default architecture for SaaS/app starters.
+license: MIT
+compatibility: Codex, Claude Code, Cursor, and other Agent Skills compatible tools.
+metadata:
+  author: Oleg Koval
+  tags:
+    - starters
+    - rules
+    - architecture
+    - vertical-slice
+    - linting
+    - pre-commit
+---
+
+# Starter Rules
+
+## Overview
+
+Load the canonical hard rules for every `oleg-koval/*` starter repo and verify the current repo complies with them. Produces a compliance report and a list of gaps to fix.
+
+## When to Use
+
+- Starting a new coding session in any `oleg-koval/*` template repo
+- Auditing an existing starter for rule compliance before a release or PR merge
+- Onboarding a new contributor (human or AI) to a starter
+- After a large refactor, to verify rules have not been silently violated
+
+Do not use for repos outside the `oleg-koval` namespace unless they explicitly reference `RULES.md`.
+
+## Workflow
+
+1. **Load the rules** — read `RULES.md` from the repo root. If absent, fetch it from `https://github.com/oleg-koval/starters/blob/main/RULES.md` and note that the starter is missing a local copy.
+
+2. **Apply §2 hard rules** — for the current task or PR diff, verify:
+   - No file exceeds 300 lines (`find . -name '*.ts' -o -name '*.py' -o -name '*.go' | xargs wc -l | awk '$1 > 300 && $2 != "total"'`)
+   - No functions produce side effects outside of boundary layers
+   - New code has no WHAT-comments; WHY-comments are one line max
+   - Tests are E2E-first; unit tests only for pure logic with non-trivial branching
+
+3. **Verify hooks and lint** — check that pre-commit hooks are installed and configured:
+   - TypeScript: `cat .eslintrc* | grep max-lines` and `cat package.json | grep -A5 '"lint-staged"\|"husky"\|"lefthook"'`
+   - Python: `cat .pre-commit-config.yaml` and check for `ruff` + format hooks
+   - Go: `cat .golangci.yml` or `.pre-commit-config.yaml` and check for `golangci-lint` + `gofmt`
+
+4. **Check architecture** — for app/SaaS starters: confirm feature code is organized as vertical slices (feature directory contains handler + DTO + service + tests together). For library starters: skip.
+
+5. **Report gaps** — list any violations found in steps 2–4. For each gap:
+   - Name the rule (e.g., "§2.2 file length")
+   - Name the file and line count or violation
+   - Propose the minimal fix
+
+6. **Fix on request** — if the user asks to fix the gaps, apply them one at a time, smallest change first. Do not refactor beyond what the rule requires.
+
+## Reference
+
+Full rule details: [`RULES.md`](./RULES.md)
+
+Architecture options and future starters: `RULES.md §3`
+
+Unix principles: `RULES.md §4`
+
+## Verification
+
+- [ ] `RULES.md` was read from the repo root (or fetched and absence noted)
+- [ ] File length check ran with zero violations, or violations were listed
+- [ ] Pre-commit hooks verified as installed and configured
+- [ ] Compliance report produced listing passed checks and gaps
+- [ ] Any fixes applied do not exceed the scope of the violated rule