@olegkoval/agent-skills 1.3.1 → 1.3.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (5) hide show
  1. package/.claude-plugin/plugin.json +1 -1
  2. package/package.json +1 -1
  3. package/packages/software-development/open-source-publisher/SKILL.md +20 -8
  4. package/packages/software-development/open-source-publisher/adapters/claude/skills/open-source-publisher/SKILL.md +20 -8
  5. package/packages/software-development/open-source-publisher/adapters/cursor/skills/open-source-publisher/SKILL.md +20 -8
package/.claude-plugin/plugin.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "olko-agent-skills",
3
3
  "description": "Agent-agnostic skill catalog for Codex, Claude, Cursor, and other skill-aware tools.",
4
- "version": "1.3.0",
4
+ "version": "1.3.1",
5
5
  "author": {
6
6
  "name": "Oleg Koval"
7
7
  },
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@olegkoval/agent-skills",
3
- "version": "1.3.1",
3
+ "version": "1.3.2",
4
4
  "private": false,
5
5
  "publishConfig": {
6
6
  "access": "public"
package/packages/software-development/open-source-publisher/SKILL.md CHANGED
@@ -34,15 +34,19 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
34
34
  3. Classify the repository type before recommending changes:
35
35
  - `library`, `CLI`, `web app`, `framework`, `docs site`, or `other`
36
36
  - use the type to decide whether governance, packaging, or presentation work should come first
37
- 4. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
37
+ 4. Identify maintainer identity and public home information when they affect publishing:
38
+ - Ask for the GitHub handle or org name if the repo will have a public owner/maintainer identity, funding links, release notes, or badges
39
+ - Ask for a canonical website/homepage URL if the project needs a homepage, docs site, or public project URL
40
+ - If `homepage`, `author`, or org metadata already exists and looks current, do not ask again
41
+ 5. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
38
42
  - "You already have a terminal-style GitHub Pages site. Do you want to keep it or restyle it?"
39
43
  - "You already have an icon and social card. Do you want a refresh, or should I leave them as-is?"
40
44
  - "You already have release automation. Do you want me to audit only, or also tighten it?"
41
- 5. Ask only for choices needed to fix missing or weak pieces:
45
+ 6. Ask only for choices needed to fix missing or weak pieces:
42
46
  - If GitHub Pages is missing or weak, ask for style: `oldschool linux`, `terminal`, `modern`, `brutalist`, `glassmorphism`, `y2k`, `hacker`, or custom.
43
47
  - 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.
44
48
  - If the repo has no clear product essence, ask for a one-sentence positioning statement.
45
- 6. Implement only approved, missing, or weak work in this order:
49
+ 7. Implement only approved, missing, or weak work in this order:
46
50
  - OSS governance and support files
47
51
  - minimal icon
48
52
  - social preview image
@@ -50,8 +54,8 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
50
54
  - GitHub Pages landing page
51
55
  - CI/CD and release audit/fixes
52
56
  - donation wiring, if requested
53
- 7. Validate locally and with browser/screenshots when possible.
54
- 8. Commit/push only when the user asks or the current task explicitly requires it.
57
+ 8. Validate locally and with browser/screenshots when possible.
58
+ 9. Commit/push only when the user asks or the current task explicitly requires it.
55
59
 
56
60
  ## Readiness Audit
57
61
 
@@ -61,10 +65,13 @@ Publish-critical checklist:
61
65
 
62
66
  - repository identity: clear project name, description, topic/keywords, author, license
63
67
  - install path: package manager, release assets, source build, or direct download instructions
68
+ - maintainer identity: GitHub handle or org name when public identity is relevant
69
+ - public home: canonical website/homepage URL when the project needs one
70
+ - if either field does not exist, proceed without it and mark it as absent
64
71
  - OSS governance: `LICENSE`, `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, support policy, issue/PR templates, changelog or release notes path
65
72
  - README standard: centered shields, icon, title, short description, horizontal rule, essential sections
66
- - icon: simple SVG mark, renders at small sizes, committed in a predictable path
67
- - social image: 1200x630 image with matching metadata, committed source when practical
73
+ - icon: simple SVG mark plus rendered PNG, both committed in predictable paths
74
+ - social image: 1200x630 image with matching metadata, with both SVG source and rendered PNG committed when practical
68
75
  - GitHub Pages or docs site: essential install/examples/links/SEO/Open Graph metadata
69
76
  - CI quality gates: formatter, linter/static analysis, tests, build/package check
70
77
  - release automation: tags/releases/artifacts/package update flow, docs-only changes excluded where needed
@@ -89,6 +96,8 @@ Missing
89
96
 
90
97
  Questions
91
98
  - You already have a terminal-style GitHub Pages site. Keep it, or restyle it?
99
+ - What is the GitHub handle or org name for public attribution?
100
+ - What is the canonical website or homepage URL, if any?
92
101
  - Donations are not configured. Enable them or leave them off?
93
102
  ```
94
103
 
@@ -102,7 +111,7 @@ Rules:
102
111
 
103
112
  ## Minimal Icon
104
113
 
105
- Create a simple, recognizable SVG logo from the repository's essence. Prefer `logo.svg`; add `logo.png` only when a platform requires raster output.
114
+ 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.
106
115
 
107
116
  Icon rules:
108
117
 
@@ -112,6 +121,7 @@ Icon rules:
112
121
  - Use a simple rounded tile only when it improves favicon readability.
113
122
  - Avoid terminal window chrome, decorative dots, random badges, and center glyph clutter unless the project itself is a terminal/window tool.
114
123
  - Avoid generic AI tells: glass effects, bokeh/orbs, over-layered gradients, busy shadows, and unrelated emojis.
124
+ - If the repo has a website or homepage, ensure the icon fits that visual system.
115
125
 
116
126
  Good icon pattern for sync/migration tools:
117
127
 
@@ -150,6 +160,7 @@ Recommended files:
150
160
 
151
161
  - `social-card.svg` as the editable source
152
162
  - `social-card.png` rendered from the SVG when render tooling is available
163
+ - keep both files in the repo when practical so the preview can be updated without redrawing the whole asset
153
164
 
154
165
  Social image rules:
155
166
 
@@ -159,6 +170,7 @@ Social image rules:
159
170
  - Match the icon color system.
160
171
  - Keep all text inside a safe margin of at least 64px.
161
172
  - Use `og:image`, `twitter:image`, width/height meta tags, and meaningful alt text.
173
+ - If the repo has a homepage or canonical website, make the social card and metadata point to that URL consistently.
162
174
 
163
175
  Render checks:
164
176
 
package/packages/software-development/open-source-publisher/adapters/claude/skills/open-source-publisher/SKILL.md CHANGED
@@ -36,15 +36,19 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
36
36
  3. Classify the repository type before recommending changes:
37
37
  - `library`, `CLI`, `web app`, `framework`, `docs site`, or `other`
38
38
  - use the type to decide whether governance, packaging, or presentation work should come first
39
- 4. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
39
+ 4. Identify maintainer identity and public home information when they affect publishing:
40
+ - Ask for the GitHub handle or org name if the repo will have a public owner/maintainer identity, funding links, release notes, or badges
41
+ - Ask for a canonical website/homepage URL if the project needs a homepage, docs site, or public project URL
42
+ - If `homepage`, `author`, or org metadata already exists and looks current, do not ask again
43
+ 5. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
40
44
  - "You already have a terminal-style GitHub Pages site. Do you want to keep it or restyle it?"
41
45
  - "You already have an icon and social card. Do you want a refresh, or should I leave them as-is?"
42
46
  - "You already have release automation. Do you want me to audit only, or also tighten it?"
43
- 5. Ask only for choices needed to fix missing or weak pieces:
47
+ 6. Ask only for choices needed to fix missing or weak pieces:
44
48
  - If GitHub Pages is missing or weak, ask for style: `oldschool linux`, `terminal`, `modern`, `brutalist`, `glassmorphism`, `y2k`, `hacker`, or custom.
45
49
  - 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.
46
50
  - If the repo has no clear product essence, ask for a one-sentence positioning statement.
47
- 6. Implement only approved, missing, or weak work in this order:
51
+ 7. Implement only approved, missing, or weak work in this order:
48
52
  - OSS governance and support files
49
53
  - minimal icon
50
54
  - social preview image
@@ -52,8 +56,8 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
52
56
  - GitHub Pages landing page
53
57
  - CI/CD and release audit/fixes
54
58
  - donation wiring, if requested
55
- 7. Validate locally and with browser/screenshots when possible.
56
- 8. Commit/push only when the user asks or the current task explicitly requires it.
59
+ 8. Validate locally and with browser/screenshots when possible.
60
+ 9. Commit/push only when the user asks or the current task explicitly requires it.
57
61
 
58
62
  ## Readiness Audit
59
63
 
@@ -63,10 +67,13 @@ Publish-critical checklist:
63
67
 
64
68
  - repository identity: clear project name, description, topic/keywords, author, license
65
69
  - install path: package manager, release assets, source build, or direct download instructions
70
+ - maintainer identity: GitHub handle or org name when public identity is relevant
71
+ - public home: canonical website/homepage URL when the project needs one
72
+ - if either field does not exist, proceed without it and mark it as absent
66
73
  - OSS governance: `LICENSE`, `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, support policy, issue/PR templates, changelog or release notes path
67
74
  - README standard: centered shields, icon, title, short description, horizontal rule, essential sections
68
- - icon: simple SVG mark, renders at small sizes, committed in a predictable path
69
- - social image: 1200x630 image with matching metadata, committed source when practical
75
+ - icon: simple SVG mark plus rendered PNG, both committed in predictable paths
76
+ - social image: 1200x630 image with matching metadata, with both SVG source and rendered PNG committed when practical
70
77
  - GitHub Pages or docs site: essential install/examples/links/SEO/Open Graph metadata
71
78
  - CI quality gates: formatter, linter/static analysis, tests, build/package check
72
79
  - release automation: tags/releases/artifacts/package update flow, docs-only changes excluded where needed
@@ -91,6 +98,8 @@ Missing
91
98
 
92
99
  Questions
93
100
  - You already have a terminal-style GitHub Pages site. Keep it, or restyle it?
101
+ - What is the GitHub handle or org name for public attribution?
102
+ - What is the canonical website or homepage URL, if any?
94
103
  - Donations are not configured. Enable them or leave them off?
95
104
  ```
96
105
 
@@ -104,7 +113,7 @@ Rules:
104
113
 
105
114
  ## Minimal Icon
106
115
 
107
- Create a simple, recognizable SVG logo from the repository's essence. Prefer `logo.svg`; add `logo.png` only when a platform requires raster output.
116
+ 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.
108
117
 
109
118
  Icon rules:
110
119
 
@@ -114,6 +123,7 @@ Icon rules:
114
123
  - Use a simple rounded tile only when it improves favicon readability.
115
124
  - Avoid terminal window chrome, decorative dots, random badges, and center glyph clutter unless the project itself is a terminal/window tool.
116
125
  - Avoid generic AI tells: glass effects, bokeh/orbs, over-layered gradients, busy shadows, and unrelated emojis.
126
+ - If the repo has a website or homepage, ensure the icon fits that visual system.
117
127
 
118
128
  Good icon pattern for sync/migration tools:
119
129
 
@@ -152,6 +162,7 @@ Recommended files:
152
162
 
153
163
  - `social-card.svg` as the editable source
154
164
  - `social-card.png` rendered from the SVG when render tooling is available
165
+ - keep both files in the repo when practical so the preview can be updated without redrawing the whole asset
155
166
 
156
167
  Social image rules:
157
168
 
@@ -161,6 +172,7 @@ Social image rules:
161
172
  - Match the icon color system.
162
173
  - Keep all text inside a safe margin of at least 64px.
163
174
  - Use `og:image`, `twitter:image`, width/height meta tags, and meaningful alt text.
175
+ - If the repo has a homepage or canonical website, make the social card and metadata point to that URL consistently.
164
176
 
165
177
  Render checks:
166
178
 
package/packages/software-development/open-source-publisher/adapters/cursor/skills/open-source-publisher/SKILL.md CHANGED
@@ -36,15 +36,19 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
36
36
  3. Classify the repository type before recommending changes:
37
37
  - `library`, `CLI`, `web app`, `framework`, `docs site`, or `other`
38
38
  - use the type to decide whether governance, packaging, or presentation work should come first
39
- 4. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
39
+ 4. Identify maintainer identity and public home information when they affect publishing:
40
+ - Ask for the GitHub handle or org name if the repo will have a public owner/maintainer identity, funding links, release notes, or badges
41
+ - Ask for a canonical website/homepage URL if the project needs a homepage, docs site, or public project URL
42
+ - If `homepage`, `author`, or org metadata already exists and looks current, do not ask again
43
+ 5. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
40
44
  - "You already have a terminal-style GitHub Pages site. Do you want to keep it or restyle it?"
41
45
  - "You already have an icon and social card. Do you want a refresh, or should I leave them as-is?"
42
46
  - "You already have release automation. Do you want me to audit only, or also tighten it?"
43
- 5. Ask only for choices needed to fix missing or weak pieces:
47
+ 6. Ask only for choices needed to fix missing or weak pieces:
44
48
  - If GitHub Pages is missing or weak, ask for style: `oldschool linux`, `terminal`, `modern`, `brutalist`, `glassmorphism`, `y2k`, `hacker`, or custom.
45
49
  - 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.
46
50
  - If the repo has no clear product essence, ask for a one-sentence positioning statement.
47
- 6. Implement only approved, missing, or weak work in this order:
51
+ 7. Implement only approved, missing, or weak work in this order:
48
52
  - OSS governance and support files
49
53
  - minimal icon
50
54
  - social preview image
@@ -52,8 +56,8 @@ Use this skill to audit whether an OSS repository is ready to publish, then help
52
56
  - GitHub Pages landing page
53
57
  - CI/CD and release audit/fixes
54
58
  - donation wiring, if requested
55
- 7. Validate locally and with browser/screenshots when possible.
56
- 8. Commit/push only when the user asks or the current task explicitly requires it.
59
+ 8. Validate locally and with browser/screenshots when possible.
60
+ 9. Commit/push only when the user asks or the current task explicitly requires it.
57
61
 
58
62
  ## Readiness Audit
59
63
 
@@ -63,10 +67,13 @@ Publish-critical checklist:
63
67
 
64
68
  - repository identity: clear project name, description, topic/keywords, author, license
65
69
  - install path: package manager, release assets, source build, or direct download instructions
70
+ - maintainer identity: GitHub handle or org name when public identity is relevant
71
+ - public home: canonical website/homepage URL when the project needs one
72
+ - if either field does not exist, proceed without it and mark it as absent
66
73
  - OSS governance: `LICENSE`, `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, support policy, issue/PR templates, changelog or release notes path
67
74
  - README standard: centered shields, icon, title, short description, horizontal rule, essential sections
68
- - icon: simple SVG mark, renders at small sizes, committed in a predictable path
69
- - social image: 1200x630 image with matching metadata, committed source when practical
75
+ - icon: simple SVG mark plus rendered PNG, both committed in predictable paths
76
+ - social image: 1200x630 image with matching metadata, with both SVG source and rendered PNG committed when practical
70
77
  - GitHub Pages or docs site: essential install/examples/links/SEO/Open Graph metadata
71
78
  - CI quality gates: formatter, linter/static analysis, tests, build/package check
72
79
  - release automation: tags/releases/artifacts/package update flow, docs-only changes excluded where needed
@@ -91,6 +98,8 @@ Missing
91
98
 
92
99
  Questions
93
100
  - You already have a terminal-style GitHub Pages site. Keep it, or restyle it?
101
+ - What is the GitHub handle or org name for public attribution?
102
+ - What is the canonical website or homepage URL, if any?
94
103
  - Donations are not configured. Enable them or leave them off?
95
104
  ```
96
105
 
@@ -104,7 +113,7 @@ Rules:
104
113
 
105
114
  ## Minimal Icon
106
115
 
107
- Create a simple, recognizable SVG logo from the repository's essence. Prefer `logo.svg`; add `logo.png` only when a platform requires raster output.
116
+ 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.
108
117
 
109
118
  Icon rules:
110
119
 
@@ -114,6 +123,7 @@ Icon rules:
114
123
  - Use a simple rounded tile only when it improves favicon readability.
115
124
  - Avoid terminal window chrome, decorative dots, random badges, and center glyph clutter unless the project itself is a terminal/window tool.
116
125
  - Avoid generic AI tells: glass effects, bokeh/orbs, over-layered gradients, busy shadows, and unrelated emojis.
126
+ - If the repo has a website or homepage, ensure the icon fits that visual system.
117
127
 
118
128
  Good icon pattern for sync/migration tools:
119
129
 
@@ -152,6 +162,7 @@ Recommended files:
152
162
 
153
163
  - `social-card.svg` as the editable source
154
164
  - `social-card.png` rendered from the SVG when render tooling is available
165
+ - keep both files in the repo when practical so the preview can be updated without redrawing the whole asset
155
166
 
156
167
  Social image rules:
157
168
 
@@ -161,6 +172,7 @@ Social image rules:
161
172
  - Match the icon color system.
162
173
  - Keep all text inside a safe margin of at least 64px.
163
174
  - Use `og:image`, `twitter:image`, width/height meta tags, and meaningful alt text.
175
+ - If the repo has a homepage or canonical website, make the social card and metadata point to that URL consistently.
164
176
 
165
177
  Render checks:
166
178