@olegkoval/agent-skills 1.3.0 → 1.3.2

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

package/package.json

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

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

@@ -31,23 +31,31 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
    - `Weak`: existing pieces that are present but incomplete, stale, broken, inconsistent, or below the house standard
    - `Missing`: publish-critical pieces that do not exist
    - `Optional`: nice-to-have pieces such as donations or extra badges
-3. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
+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. 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?"
-4. 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.
-5. 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
    - CI/CD and release audit/fixes
    - donation wiring, if requested
-6. Validate locally and with browser/screenshots when possible.
-7. 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
 
@@ -57,9 +65,13 @@ 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
 - 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
@@ -84,6 +96,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?
 ```
 
@@ -97,7 +111,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:
 
@@ -107,6 +121,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:
 
@@ -145,6 +160,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:
 
@@ -154,6 +170,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:
 
@@ -227,6 +244,29 @@ Rules:
 - Do not claim coverage, license, support, CI, or releases that are not actually present.
 - Add or fix `LICENSE` before saying MIT/Apache/etc.
 
+## OSS Governance
+
+Treat governance files as first-class publishing work, not optional paperwork.
+
+Check for, or add when appropriate:
+
+- `LICENSE`
+- `CONTRIBUTING.md`
+- `SECURITY.md`
+- `CODE_OF_CONDUCT.md`
+- `SUPPORT.md`
+- `.github/ISSUE_TEMPLATE/*`
+- `.github/PULL_REQUEST_TEMPLATE.md`
+- `CHANGELOG.md` or a release notes workflow
+- package metadata for homepage, repository, bugs, and funding links
+
+Rules:
+
+- For libraries and CLIs, prioritize governance and release path before visual polish.
+- For web apps or product sites, keep the governance checks but allow branding and landing page work to happen earlier when the public-facing experience is the main product.
+- If a repo already has governance docs that are good enough, mark them `Ready` and move on.
+- If the project has no maintainer/support policy, ask whether support should be community-only, maintainer-only, or commercial.
+
 ## GitHub Pages
 
 Create a simple essential GitHub Pages site when the project lacks one or the existing one is weak.
@@ -272,9 +312,15 @@ Check whether the repository has:
 - linter/static analysis
 - tests
 - build/package check
+- dependency review / lockfile integrity checks
+- secret scanning or secret prevention
+- license scanning / OSS compliance scan
+- SBOM or provenance generation where appropriate
 - security scan or OpenSSF Scorecard where appropriate
 - release automation
 - docs/site-only path filters when release runs on `main`
+- docs link checker or markdown validation for repo/docs sites
+- package-specific smoke install / publish dry-run matrix
 
 For Go projects, prefer:
 
@@ -302,6 +348,8 @@ Release automation rules:
 - Make Homebrew/package formulas update from real release artifacts and checksums.
 - Use least-privilege secrets and document required secret names.
 - If automation pushes tags, guard against rerun/version reuse.
+- Prefer signed or attestable releases where the ecosystem supports it.
+- Prefer release notes generation from tags or merged PRs instead of hand-written release bodies when the repo is release-heavy.
 
 ## Donations
 

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

@@ -33,23 +33,31 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
    - `Weak`: existing pieces that are present but incomplete, stale, broken, inconsistent, or below the house standard
    - `Missing`: publish-critical pieces that do not exist
    - `Optional`: nice-to-have pieces such as donations or extra badges
-3. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
+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. 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?"
-4. 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.
-5. 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
    - CI/CD and release audit/fixes
    - donation wiring, if requested
-6. Validate locally and with browser/screenshots when possible.
-7. 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
 
@@ -59,9 +67,13 @@ 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
 - 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
@@ -86,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?
 ```
 
@@ -99,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:
 
@@ -109,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:
 
@@ -147,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:
 
@@ -156,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:
 
@@ -229,6 +246,29 @@ Rules:
 - Do not claim coverage, license, support, CI, or releases that are not actually present.
 - Add or fix `LICENSE` before saying MIT/Apache/etc.
 
+## OSS Governance
+
+Treat governance files as first-class publishing work, not optional paperwork.
+
+Check for, or add when appropriate:
+
+- `LICENSE`
+- `CONTRIBUTING.md`
+- `SECURITY.md`
+- `CODE_OF_CONDUCT.md`
+- `SUPPORT.md`
+- `.github/ISSUE_TEMPLATE/*`
+- `.github/PULL_REQUEST_TEMPLATE.md`
+- `CHANGELOG.md` or a release notes workflow
+- package metadata for homepage, repository, bugs, and funding links
+
+Rules:
+
+- For libraries and CLIs, prioritize governance and release path before visual polish.
+- For web apps or product sites, keep the governance checks but allow branding and landing page work to happen earlier when the public-facing experience is the main product.
+- If a repo already has governance docs that are good enough, mark them `Ready` and move on.
+- If the project has no maintainer/support policy, ask whether support should be community-only, maintainer-only, or commercial.
+
 ## GitHub Pages
 
 Create a simple essential GitHub Pages site when the project lacks one or the existing one is weak.
@@ -274,9 +314,15 @@ Check whether the repository has:
 - linter/static analysis
 - tests
 - build/package check
+- dependency review / lockfile integrity checks
+- secret scanning or secret prevention
+- license scanning / OSS compliance scan
+- SBOM or provenance generation where appropriate
 - security scan or OpenSSF Scorecard where appropriate
 - release automation
 - docs/site-only path filters when release runs on `main`
+- docs link checker or markdown validation for repo/docs sites
+- package-specific smoke install / publish dry-run matrix
 
 For Go projects, prefer:
 
@@ -304,6 +350,8 @@ Release automation rules:
 - Make Homebrew/package formulas update from real release artifacts and checksums.
 - Use least-privilege secrets and document required secret names.
 - If automation pushes tags, guard against rerun/version reuse.
+- Prefer signed or attestable releases where the ecosystem supports it.
+- Prefer release notes generation from tags or merged PRs instead of hand-written release bodies when the repo is release-heavy.
 
 ## Donations
 

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

@@ -33,23 +33,31 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
    - `Weak`: existing pieces that are present but incomplete, stale, broken, inconsistent, or below the house standard
    - `Missing`: publish-critical pieces that do not exist
    - `Optional`: nice-to-have pieces such as donations or extra badges
-3. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
+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. 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?"
-4. 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.
-5. 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
    - CI/CD and release audit/fixes
    - donation wiring, if requested
-6. Validate locally and with browser/screenshots when possible.
-7. 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
 
@@ -59,9 +67,13 @@ 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
 - 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
@@ -86,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?
 ```
 
@@ -99,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:
 
@@ -109,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:
 
@@ -147,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:
 
@@ -156,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:
 
@@ -229,6 +246,29 @@ Rules:
 - Do not claim coverage, license, support, CI, or releases that are not actually present.
 - Add or fix `LICENSE` before saying MIT/Apache/etc.
 
+## OSS Governance
+
+Treat governance files as first-class publishing work, not optional paperwork.
+
+Check for, or add when appropriate:
+
+- `LICENSE`
+- `CONTRIBUTING.md`
+- `SECURITY.md`
+- `CODE_OF_CONDUCT.md`
+- `SUPPORT.md`
+- `.github/ISSUE_TEMPLATE/*`
+- `.github/PULL_REQUEST_TEMPLATE.md`
+- `CHANGELOG.md` or a release notes workflow
+- package metadata for homepage, repository, bugs, and funding links
+
+Rules:
+
+- For libraries and CLIs, prioritize governance and release path before visual polish.
+- For web apps or product sites, keep the governance checks but allow branding and landing page work to happen earlier when the public-facing experience is the main product.
+- If a repo already has governance docs that are good enough, mark them `Ready` and move on.
+- If the project has no maintainer/support policy, ask whether support should be community-only, maintainer-only, or commercial.
+
 ## GitHub Pages
 
 Create a simple essential GitHub Pages site when the project lacks one or the existing one is weak.
@@ -274,9 +314,15 @@ Check whether the repository has:
 - linter/static analysis
 - tests
 - build/package check
+- dependency review / lockfile integrity checks
+- secret scanning or secret prevention
+- license scanning / OSS compliance scan
+- SBOM or provenance generation where appropriate
 - security scan or OpenSSF Scorecard where appropriate
 - release automation
 - docs/site-only path filters when release runs on `main`
+- docs link checker or markdown validation for repo/docs sites
+- package-specific smoke install / publish dry-run matrix
 
 For Go projects, prefer:
 
@@ -304,6 +350,8 @@ Release automation rules:
 - Make Homebrew/package formulas update from real release artifacts and checksums.
 - Use least-privilege secrets and document required secret names.
 - If automation pushes tags, guard against rerun/version reuse.
+- Prefer signed or attestable releases where the ecosystem supports it.
+- Prefer release notes generation from tags or merged PRs instead of hand-written release bodies when the repo is release-heavy.
 
 ## Donations