@olegkoval/agent-skills 1.3.2 → 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.1",
+  "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.2",
+  "version": "1.4.0",
   "private": false,
   "publishConfig": {
     "access": "public"

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

@@ -52,6 +52,7 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
    - 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
 8. Validate locally and with browser/screenshots when possible.
@@ -73,6 +74,7 @@ Publish-critical checklist:
 - 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
@@ -304,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

@@ -54,6 +54,7 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
    - 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
 8. Validate locally and with browser/screenshots when possible.
@@ -75,6 +76,7 @@ Publish-critical checklist:
 - 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
@@ -306,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

@@ -54,6 +54,7 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
    - 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
 8. Validate locally and with browser/screenshots when possible.
@@ -75,6 +76,7 @@ Publish-critical checklist:
 - 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
@@ -306,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