@olegkoval/agent-skills 1.2.2 → 1.3.1

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.1",
+  "version": "1.3.0",
   "author": {
     "name": "Oleg Koval"
   },
@@ -18,6 +18,7 @@
     "./packages/software-development/promptctl",
     "./packages/music/fill-music-player",
     "./packages/software-development/product-builder",
+    "./packages/software-development/add-to-my-skills",
     "./packages/software-development/open-source-publisher",
     "./packages/marketing/viral-launch",
     "./packages/marketing/search-console-indexing-audit"

package/.cursor-plugin/index.json

@@ -46,6 +46,11 @@
       "source": "./packages/software-development/product-builder/adapters/cursor",
       "description": "Build a full-stack web application or SaaS product from a user description using production-oriented defaults."
     },
+    {
+      "name": "olko:add-to-my-skills",
+      "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:open-source-publisher",
       "source": "./packages/software-development/open-source-publisher/adapters/cursor",

package/README.md

@@ -3,7 +3,7 @@
   <p><strong>Agent-agnostic skill catalog for Codex, Claude, Cursor, and other skill-aware tools.</strong></p>
   <p>
     <img src="https://img.shields.io/badge/license-MIT-16a34a" alt="MIT license">
-    <img src="https://img.shields.io/badge/skills-11-2563eb" alt="11 skills">
+    <img src="https://img.shields.io/badge/skills-12-2563eb" alt="12 skills">
     <img src="https://img.shields.io/badge/platforms-Codex%20%7C%20Claude%20%7C%20Cursor%20%7C%20Copilot-111827" alt="Codex Claude Cursor Copilot">
     <img src="https://img.shields.io/badge/status-public%20catalog-16a34a" alt="Public catalog">
   </p>
@@ -116,7 +116,7 @@ packages/{category}/{skill}/adapters/
 
 </details>
 
-## All 11 Skills
+## All 12 Skills
 
 These packages are the entry points. Each one is a structured workflow with concrete trigger conditions and execution steps. You can reference any skill directly by its `olko:*` lookup name.
 
@@ -129,6 +129,7 @@ These packages are the entry points. Each one is a structured workflow with conc
 | [changelog-generator](packages/software-development/changelog-generator/SKILL.md) | Generates user-facing changelogs and release notes from git history | Preparing release notes, app store update text, customer changelogs, or internal release summaries |
 | [gh-cli](packages/software-development/gh-cli/SKILL.md) | Guides GitHub CLI usage for repos, PRs, Actions, releases, issues, and related GitHub operations | Working with GitHub from the command line and needing reliable `gh` commands |
 | [git-commit](packages/software-development/git-commit/SKILL.md) | Creates conventional commits with diff-aware staging and message generation | The user asks to commit changes or wants a conventional commit message from the current diff |
+| [add-to-my-skills](packages/software-development/add-to-my-skills/SKILL.md) | Copies a skill from another repo into this catalog, then refreshes docs, manifests, commit, and push | Bringing a newly created skill into this repository |
 | [promptctl](packages/software-development/promptctl/SKILL.md) | Uses `promptctl` for reusable prompt templates, scoring, and workflow automation | A project needs prompt conventions, prompt review, prompt scoring, or reusable prompt workflows |
 | [product-builder](packages/software-development/product-builder/SKILL.md) | Builds a full-stack web app or SaaS product from a user description using production-oriented defaults | The user asks to build a complete app, SaaS, dashboard, or product rather than a prototype |
 
@@ -167,6 +168,10 @@ Use the olko:semantic-release-beta skill to add prereleases on a beta branch.
 Use the olko:gallery skill to build a photo gallery from this image folder.
 ```
 
+```text
+Use the olko:add-to-my-skills skill to copy a skill from another repo into this catalog, update the README, and push the change.
+```
+
 ```text
 Use the olko:viral-launch skill to make this project launch-ready.
 ```
@@ -224,6 +229,7 @@ agent-skills/
 │   │   ├── changelog-generator/
 │   │   ├── gh-cli/
 │   │   ├── git-commit/
+│   │   ├── add-to-my-skills/
 │   │   ├── promptctl/
 │   │   └── product-builder/
 │   ├── music/
@@ -324,6 +330,11 @@ The following package workflows have been smoke-tested locally before first push
   - ran `semantic-release --dry-run --no-ci` on `beta`
   - verified prerelease calculation to `1.0.0-beta.1`
 
+- `add-to-my-skills`
+  - copied a source skill into `packages/software-development/`
+  - refreshed generated manifests with `./scripts/build-adapters.sh`
+  - validated catalog and generated files with `./scripts/validate-catalog.sh`
+
 The semantic-release smoke test was intentionally self-contained and used a local bare git remote plus a valid `file://` repository URL so dry-run behavior could be validated without real npm or GitHub publishing credentials.
 
 ## Licensing notes

package/catalog/skills.json

@@ -177,6 +177,26 @@
         "copilot"
       ]
     },
+    {
+      "name": "add-to-my-skills",
+      "lookupName": "olko:add-to-my-skills",
+      "category": "software-development",
+      "path": "packages/software-development/add-to-my-skills",
+      "description": "Copy a newly created skill into this catalog, refresh manifests, and publish the change.",
+      "tags": [
+        "skills",
+        "skillshare",
+        "catalog",
+        "git",
+        "push"
+      ],
+      "adapters": [
+        "codex",
+        "claude",
+        "cursor",
+        "copilot"
+      ]
+    },
     {
       "name": "open-source-publisher",
       "lookupName": "olko:open-source-publisher",

package/collections/software-development.json

@@ -8,6 +8,7 @@
     "gh-cli",
     "git-commit",
     "promptctl",
+    "add-to-my-skills",
     "open-source-publisher",
     "product-builder"
   ]

package/package.json

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

package/packages/software-development/add-to-my-skills/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: add-to-my-skills
+description: Copy a newly created skill from another repo into this catalog, refresh the README and generated manifests, then commit and push the change. Use when the user wants to bring a skill they built elsewhere into this repository.
+license: MIT
+compatibility: Codex, Claude Code, Cursor, and other Agent Skills compatible tools. Requires a writable git repository and access to the source skill repo.
+metadata:
+  author: Oleg Koval
+  tags:
+    - skills
+    - skillshare
+    - catalog
+    - git
+    - commit
+    - push
+---
+
+# Add to My Skills
+
+Use this skill when a skill was created in another repository and needs to be copied into this catalog as a first-class package.
+
+## Outcome
+
+Bring the source skill into `packages/software-development/`, register it in the catalog, refresh generated docs and adapters, and publish the change with a git commit and push.
+
+## When to Use
+
+- The user created a new `SKILL.md` in another repo and wants it added here
+- The user wants this catalog to become the canonical home for that skill
+- The user wants the README, generated manifests, commit, and push handled in one pass
+
+## Clarify Before Acting
+
+If any of these are unclear, ask up to 3 questions in one batch before editing:
+
+- Source repo or source skill path
+- Final skill name if it should differ from the source
+- Destination branch or remote if the push target is unclear
+
+Default assumptions when not specified:
+
+- Copy the source skill as a new canonical package in `packages/software-development/<skill-name>/`
+- Keep the source skill name unless the user asks to rename it
+- Use this repository as the destination
+- Commit with a conventional commit message and push to the current branch's upstream
+
+## Workflow
+
+1. Inspect the source skill:
+   - locate the source `SKILL.md`
+   - copy any supporting `references/`, `scripts/`, or `assets/` files that the skill needs
+   - note any repo-specific assumptions that need to be rewritten for this catalog
+2. Choose the package location:
+   - default to `packages/software-development/<skill-name>/`
+   - ensure the package directory name matches the `name` frontmatter value
+3. Create or update the canonical package:
+   - write `SKILL.md` first
+   - keep the frontmatter accurate and concise
+   - make the workflow explicit, actionable, and self-contained
+4. Register the package in the repository inventory:
+   - add the package to `catalog/skills.json`
+   - add it to the appropriate collection file if it belongs in a bundle
+   - update `README.md` so the package list, counts, and usage examples stay current
+5. Refresh generated outputs:
+   - run `./scripts/build-adapters.sh`
+   - run `./scripts/validate-catalog.sh`
+6. Verify the new package actually exists:
+   - confirm `packages/software-development/<skill-name>/SKILL.md`
+   - confirm generated adapter files and prompt files were created
+7. Commit and push:
+   - inspect `git status`
+   - commit the change with a conventional message
+   - push to the current upstream branch
+
+## Git Safety
+
+- Never overwrite unrelated changes
+- Never force push unless the user explicitly asks
+- Never commit secrets copied from the source repo
+- If the source skill is incomplete or ambiguous, stop and ask for clarification instead of guessing
+
+## Verification
+
+- `./scripts/build-adapters.sh` completes successfully
+- `./scripts/validate-catalog.sh` passes
+- `git status` shows only the intended package, catalog, README, and generated files
+- `git push` succeeds to the expected remote

package/packages/software-development/add-to-my-skills/adapters/claude/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "olko-add-to-my-skills",
+  "description": "Copy a newly created skill into this catalog, refresh manifests, and publish the change.",
+  "skills": "./skills"
+}

package/packages/software-development/add-to-my-skills/adapters/claude/skills/add-to-my-skills/SKILL.md

@@ -0,0 +1,88 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+name: add-to-my-skills
+description: Copy a newly created skill from another repo into this catalog, refresh the README and generated manifests, then commit and push the change. Use when the user wants to bring a skill they built elsewhere into this repository.
+license: MIT
+compatibility: Codex, Claude Code, Cursor, and other Agent Skills compatible tools. Requires a writable git repository and access to the source skill repo.
+metadata:
+  author: Oleg Koval
+  tags:
+    - skills
+    - skillshare
+    - catalog
+    - git
+    - commit
+    - push
+---
+
+# Add to My Skills
+
+Use this skill when a skill was created in another repository and needs to be copied into this catalog as a first-class package.
+
+## Outcome
+
+Bring the source skill into `packages/software-development/`, register it in the catalog, refresh generated docs and adapters, and publish the change with a git commit and push.
+
+## When to Use
+
+- The user created a new `SKILL.md` in another repo and wants it added here
+- The user wants this catalog to become the canonical home for that skill
+- The user wants the README, generated manifests, commit, and push handled in one pass
+
+## Clarify Before Acting
+
+If any of these are unclear, ask up to 3 questions in one batch before editing:
+
+- Source repo or source skill path
+- Final skill name if it should differ from the source
+- Destination branch or remote if the push target is unclear
+
+Default assumptions when not specified:
+
+- Copy the source skill as a new canonical package in `packages/software-development/<skill-name>/`
+- Keep the source skill name unless the user asks to rename it
+- Use this repository as the destination
+- Commit with a conventional commit message and push to the current branch's upstream
+
+## Workflow
+
+1. Inspect the source skill:
+   - locate the source `SKILL.md`
+   - copy any supporting `references/`, `scripts/`, or `assets/` files that the skill needs
+   - note any repo-specific assumptions that need to be rewritten for this catalog
+2. Choose the package location:
+   - default to `packages/software-development/<skill-name>/`
+   - ensure the package directory name matches the `name` frontmatter value
+3. Create or update the canonical package:
+   - write `SKILL.md` first
+   - keep the frontmatter accurate and concise
+   - make the workflow explicit, actionable, and self-contained
+4. Register the package in the repository inventory:
+   - add the package to `catalog/skills.json`
+   - add it to the appropriate collection file if it belongs in a bundle
+   - update `README.md` so the package list, counts, and usage examples stay current
+5. Refresh generated outputs:
+   - run `./scripts/build-adapters.sh`
+   - run `./scripts/validate-catalog.sh`
+6. Verify the new package actually exists:
+   - confirm `packages/software-development/<skill-name>/SKILL.md`
+   - confirm generated adapter files and prompt files were created
+7. Commit and push:
+   - inspect `git status`
+   - commit the change with a conventional message
+   - push to the current upstream branch
+
+## Git Safety
+
+- Never overwrite unrelated changes
+- Never force push unless the user explicitly asks
+- Never commit secrets copied from the source repo
+- If the source skill is incomplete or ambiguous, stop and ask for clarification instead of guessing
+
+## Verification
+
+- `./scripts/build-adapters.sh` completes successfully
+- `./scripts/validate-catalog.sh` passes
+- `git status` shows only the intended package, catalog, README, and generated files
+- `git push` succeeds to the expected remote

package/packages/software-development/add-to-my-skills/adapters/codex/README.md

@@ -0,0 +1,3 @@
+# Codex adapter
+
+Use the canonical skill directly from `packages/software-development/add-to-my-skills/SKILL.md`.

package/packages/software-development/add-to-my-skills/adapters/cursor/plugin.json

@@ -0,0 +1,6 @@
+{
+  "name": "olko:add-to-my-skills",
+  "version": "0.1.0",
+  "description": "Copy a newly created skill into this catalog, refresh manifests, and publish the change.",
+  "skills": "skills/"
+}

package/packages/software-development/add-to-my-skills/adapters/cursor/skills/add-to-my-skills/SKILL.md

@@ -0,0 +1,88 @@
+<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
+
+---
+name: add-to-my-skills
+description: Copy a newly created skill from another repo into this catalog, refresh the README and generated manifests, then commit and push the change. Use when the user wants to bring a skill they built elsewhere into this repository.
+license: MIT
+compatibility: Codex, Claude Code, Cursor, and other Agent Skills compatible tools. Requires a writable git repository and access to the source skill repo.
+metadata:
+  author: Oleg Koval
+  tags:
+    - skills
+    - skillshare
+    - catalog
+    - git
+    - commit
+    - push
+---
+
+# Add to My Skills
+
+Use this skill when a skill was created in another repository and needs to be copied into this catalog as a first-class package.
+
+## Outcome
+
+Bring the source skill into `packages/software-development/`, register it in the catalog, refresh generated docs and adapters, and publish the change with a git commit and push.
+
+## When to Use
+
+- The user created a new `SKILL.md` in another repo and wants it added here
+- The user wants this catalog to become the canonical home for that skill
+- The user wants the README, generated manifests, commit, and push handled in one pass
+
+## Clarify Before Acting
+
+If any of these are unclear, ask up to 3 questions in one batch before editing:
+
+- Source repo or source skill path
+- Final skill name if it should differ from the source
+- Destination branch or remote if the push target is unclear
+
+Default assumptions when not specified:
+
+- Copy the source skill as a new canonical package in `packages/software-development/<skill-name>/`
+- Keep the source skill name unless the user asks to rename it
+- Use this repository as the destination
+- Commit with a conventional commit message and push to the current branch's upstream
+
+## Workflow
+
+1. Inspect the source skill:
+   - locate the source `SKILL.md`
+   - copy any supporting `references/`, `scripts/`, or `assets/` files that the skill needs
+   - note any repo-specific assumptions that need to be rewritten for this catalog
+2. Choose the package location:
+   - default to `packages/software-development/<skill-name>/`
+   - ensure the package directory name matches the `name` frontmatter value
+3. Create or update the canonical package:
+   - write `SKILL.md` first
+   - keep the frontmatter accurate and concise
+   - make the workflow explicit, actionable, and self-contained
+4. Register the package in the repository inventory:
+   - add the package to `catalog/skills.json`
+   - add it to the appropriate collection file if it belongs in a bundle
+   - update `README.md` so the package list, counts, and usage examples stay current
+5. Refresh generated outputs:
+   - run `./scripts/build-adapters.sh`
+   - run `./scripts/validate-catalog.sh`
+6. Verify the new package actually exists:
+   - confirm `packages/software-development/<skill-name>/SKILL.md`
+   - confirm generated adapter files and prompt files were created
+7. Commit and push:
+   - inspect `git status`
+   - commit the change with a conventional message
+   - push to the current upstream branch
+
+## Git Safety
+
+- Never overwrite unrelated changes
+- Never force push unless the user explicitly asks
+- Never commit secrets copied from the source repo
+- If the source skill is incomplete or ambiguous, stop and ask for clarification instead of guessing
+
+## Verification
+
+- `./scripts/build-adapters.sh` completes successfully
+- `./scripts/validate-catalog.sh` passes
+- `git status` shows only the intended package, catalog, README, and generated files
+- `git push` succeeds to the expected remote

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

@@ -31,23 +31,27 @@ 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. 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:
+5. 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:
+6. 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.
+7. Validate locally and with browser/screenshots when possible.
+8. Commit/push only when the user asks or the current task explicitly requires it.
 
 ## Readiness Audit
 
@@ -57,6 +61,7 @@ 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
+- 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
@@ -227,6 +232,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 +300,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 +336,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,27 @@ 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. 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:
+5. 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:
+6. 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.
+7. Validate locally and with browser/screenshots when possible.
+8. Commit/push only when the user asks or the current task explicitly requires it.
 
 ## Readiness Audit
 
@@ -59,6 +63,7 @@ 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
+- 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
@@ -229,6 +234,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 +302,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 +338,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,27 @@ 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. 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:
+5. 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:
+6. 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.
+7. Validate locally and with browser/screenshots when possible.
+8. Commit/push only when the user asks or the current task explicitly requires it.
 
 ## Readiness Audit
 
@@ -59,6 +63,7 @@ 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
+- 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
@@ -229,6 +234,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 +302,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 +338,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