@olegkoval/agent-skills 1.2.0 → 1.2.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 (6) 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 +62 -7
  4. package/packages/software-development/open-source-publisher/adapters/claude/skills/open-source-publisher/SKILL.md +62 -7
  5. package/packages/software-development/open-source-publisher/adapters/cursor/skills/open-source-publisher/SKILL.md +62 -7
  6. package/packages/software-development/open-source-publisher/agents/openai.yaml +1 -1
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.1.0",
4
+ "version": "1.2.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.2.0",
3
+ "version": "1.2.2",
4
4
  "private": false,
5
5
  "publishConfig": {
6
6
  "access": "public"
package/packages/software-development/open-source-publisher/SKILL.md CHANGED
@@ -18,7 +18,7 @@ metadata:
18
18
 
19
19
  # open-source-publisher
20
20
 
21
- Use this skill to turn a useful OSS repository into a clean public package: recognizable icon, shareable social image, GitHub Pages site, standardized README, CI/CD hygiene, release readiness, and optional donation links.
21
+ Use this skill to audit whether an OSS repository is ready to publish, then help only with missing or weak pieces: recognizable icon, shareable social image, GitHub Pages site, standardized README, CI/CD hygiene, release readiness, and optional donation links.
22
22
 
23
23
  ## Workflow
24
24
 
@@ -26,19 +26,74 @@ Use this skill to turn a useful OSS repository into a clean public package: reco
26
26
  - package/tooling files: `go.mod`, `package.json`, `pyproject.toml`, `Cargo.toml`, `Makefile`, etc.
27
27
  - current README, docs, website files, images, workflows, releases, license, funding files
28
28
  - existing product purpose, author, install paths, examples, and public URLs
29
- 2. Ask only the choices that cannot be inferred:
30
- - GitHub Pages style: `oldschool linux`, `terminal`, `modern`, `brutalist`, `glassmorphism`, `y2k`, `hacker`, or a custom style.
31
- - Donations: `none`, `GitHub Sponsors`, `Ko-fi`, `Buy Me a Coffee`, `Open Collective`, `Thanks.dev`, or custom URL.
29
+ 2. Produce a readiness audit before asking for changes:
30
+ - `Ready`: publish-critical pieces that already exist and look usable
31
+ - `Weak`: existing pieces that are present but incomplete, stale, broken, inconsistent, or below the house standard
32
+ - `Missing`: publish-critical pieces that do not exist
33
+ - `Optional`: nice-to-have pieces such as donations or extra badges
34
+ 3. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
35
+ - "You already have a terminal-style GitHub Pages site. Do you want to keep it or restyle it?"
36
+ - "You already have an icon and social card. Do you want a refresh, or should I leave them as-is?"
37
+ - "You already have release automation. Do you want me to audit only, or also tighten it?"
38
+ 4. Ask only for choices needed to fix missing or weak pieces:
39
+ - If GitHub Pages is missing or weak, ask for style: `oldschool linux`, `terminal`, `modern`, `brutalist`, `glassmorphism`, `y2k`, `hacker`, or custom.
40
+ - 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.
32
41
  - If the repo has no clear product essence, ask for a one-sentence positioning statement.
33
- 3. Implement in this order:
42
+ 5. Implement only approved, missing, or weak work in this order:
34
43
  - minimal icon
35
44
  - social preview image
36
45
  - README standard
37
46
  - GitHub Pages landing page
38
47
  - CI/CD and release audit/fixes
39
48
  - donation wiring, if requested
40
- 4. Validate locally and with browser/screenshots when possible.
41
- 5. Commit/push only when the user asks or the current task explicitly requires it.
49
+ 6. Validate locally and with browser/screenshots when possible.
50
+ 7. Commit/push only when the user asks or the current task explicitly requires it.
51
+
52
+ ## Readiness Audit
53
+
54
+ Treat this skill as an OSS publishing readiness checker first and an implementer second. The first response after inspection should be a concise audit with concrete evidence from the repo.
55
+
56
+ Publish-critical checklist:
57
+
58
+ - repository identity: clear project name, description, topic/keywords, author, license
59
+ - install path: package manager, release assets, source build, or direct download instructions
60
+ - README standard: centered shields, icon, title, short description, horizontal rule, essential sections
61
+ - icon: simple SVG mark, renders at small sizes, committed in a predictable path
62
+ - social image: 1200x630 image with matching metadata, committed source when practical
63
+ - GitHub Pages or docs site: essential install/examples/links/SEO/Open Graph metadata
64
+ - CI quality gates: formatter, linter/static analysis, tests, build/package check
65
+ - release automation: tags/releases/artifacts/package update flow, docs-only changes excluded where needed
66
+ - security posture: license, security notes or policy, OpenSSF Scorecard or equivalent when appropriate
67
+ - contribution path: issues/PR guidance, support expectations, project status
68
+ - donations: explicitly absent, declined, or configured
69
+
70
+ Audit output format:
71
+
72
+ ```md
73
+ ## OSS Publish Readiness
74
+
75
+ Ready
76
+ - README uses the house top block with test, Go Report Card, and OpenSSF shields.
77
+ - Release workflow builds darwin arm64/amd64 binaries and updates the Homebrew tap.
78
+
79
+ Weak
80
+ - Direct download examples point at a fixed release tag; latest-release URLs would age better.
81
+
82
+ Missing
83
+ - No `.github/FUNDING.yml`; donations are not configured.
84
+
85
+ Questions
86
+ - You already have a terminal-style GitHub Pages site. Keep it, or restyle it?
87
+ - Donations are not configured. Enable them or leave them off?
88
+ ```
89
+
90
+ Rules:
91
+
92
+ - Do not ask for style, donations, or redesign choices before the audit.
93
+ - Do not overwrite existing icon, social image, README, site, workflows, or funding files unless the user approves a change or the audit classifies the item as weak.
94
+ - If everything publish-critical is ready, say so and offer only optional improvements.
95
+ - If the user asks to "run the skill" without more detail, audit first, then wait for approval before making non-trivial visual or workflow changes.
96
+ - Keep the audit evidence-based. Reference filenames, workflow names, package metadata, or command outputs.
42
97
 
43
98
  ## Minimal Icon
44
99
 
package/packages/software-development/open-source-publisher/adapters/claude/skills/open-source-publisher/SKILL.md CHANGED
@@ -20,7 +20,7 @@ metadata:
20
20
 
21
21
  # open-source-publisher
22
22
 
23
- Use this skill to turn a useful OSS repository into a clean public package: recognizable icon, shareable social image, GitHub Pages site, standardized README, CI/CD hygiene, release readiness, and optional donation links.
23
+ Use this skill to audit whether an OSS repository is ready to publish, then help only with missing or weak pieces: recognizable icon, shareable social image, GitHub Pages site, standardized README, CI/CD hygiene, release readiness, and optional donation links.
24
24
 
25
25
  ## Workflow
26
26
 
@@ -28,19 +28,74 @@ Use this skill to turn a useful OSS repository into a clean public package: reco
28
28
  - package/tooling files: `go.mod`, `package.json`, `pyproject.toml`, `Cargo.toml`, `Makefile`, etc.
29
29
  - current README, docs, website files, images, workflows, releases, license, funding files
30
30
  - existing product purpose, author, install paths, examples, and public URLs
31
- 2. Ask only the choices that cannot be inferred:
32
- - GitHub Pages style: `oldschool linux`, `terminal`, `modern`, `brutalist`, `glassmorphism`, `y2k`, `hacker`, or a custom style.
33
- - Donations: `none`, `GitHub Sponsors`, `Ko-fi`, `Buy Me a Coffee`, `Open Collective`, `Thanks.dev`, or custom URL.
31
+ 2. Produce a readiness audit before asking for changes:
32
+ - `Ready`: publish-critical pieces that already exist and look usable
33
+ - `Weak`: existing pieces that are present but incomplete, stale, broken, inconsistent, or below the house standard
34
+ - `Missing`: publish-critical pieces that do not exist
35
+ - `Optional`: nice-to-have pieces such as donations or extra badges
36
+ 3. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
37
+ - "You already have a terminal-style GitHub Pages site. Do you want to keep it or restyle it?"
38
+ - "You already have an icon and social card. Do you want a refresh, or should I leave them as-is?"
39
+ - "You already have release automation. Do you want me to audit only, or also tighten it?"
40
+ 4. Ask only for choices needed to fix missing or weak pieces:
41
+ - If GitHub Pages is missing or weak, ask for style: `oldschool linux`, `terminal`, `modern`, `brutalist`, `glassmorphism`, `y2k`, `hacker`, or custom.
42
+ - 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.
34
43
  - If the repo has no clear product essence, ask for a one-sentence positioning statement.
35
- 3. Implement in this order:
44
+ 5. Implement only approved, missing, or weak work in this order:
36
45
  - minimal icon
37
46
  - social preview image
38
47
  - README standard
39
48
  - GitHub Pages landing page
40
49
  - CI/CD and release audit/fixes
41
50
  - donation wiring, if requested
42
- 4. Validate locally and with browser/screenshots when possible.
43
- 5. Commit/push only when the user asks or the current task explicitly requires it.
51
+ 6. Validate locally and with browser/screenshots when possible.
52
+ 7. Commit/push only when the user asks or the current task explicitly requires it.
53
+
54
+ ## Readiness Audit
55
+
56
+ Treat this skill as an OSS publishing readiness checker first and an implementer second. The first response after inspection should be a concise audit with concrete evidence from the repo.
57
+
58
+ Publish-critical checklist:
59
+
60
+ - repository identity: clear project name, description, topic/keywords, author, license
61
+ - install path: package manager, release assets, source build, or direct download instructions
62
+ - README standard: centered shields, icon, title, short description, horizontal rule, essential sections
63
+ - icon: simple SVG mark, renders at small sizes, committed in a predictable path
64
+ - social image: 1200x630 image with matching metadata, committed source when practical
65
+ - GitHub Pages or docs site: essential install/examples/links/SEO/Open Graph metadata
66
+ - CI quality gates: formatter, linter/static analysis, tests, build/package check
67
+ - release automation: tags/releases/artifacts/package update flow, docs-only changes excluded where needed
68
+ - security posture: license, security notes or policy, OpenSSF Scorecard or equivalent when appropriate
69
+ - contribution path: issues/PR guidance, support expectations, project status
70
+ - donations: explicitly absent, declined, or configured
71
+
72
+ Audit output format:
73
+
74
+ ```md
75
+ ## OSS Publish Readiness
76
+
77
+ Ready
78
+ - README uses the house top block with test, Go Report Card, and OpenSSF shields.
79
+ - Release workflow builds darwin arm64/amd64 binaries and updates the Homebrew tap.
80
+
81
+ Weak
82
+ - Direct download examples point at a fixed release tag; latest-release URLs would age better.
83
+
84
+ Missing
85
+ - No `.github/FUNDING.yml`; donations are not configured.
86
+
87
+ Questions
88
+ - You already have a terminal-style GitHub Pages site. Keep it, or restyle it?
89
+ - Donations are not configured. Enable them or leave them off?
90
+ ```
91
+
92
+ Rules:
93
+
94
+ - Do not ask for style, donations, or redesign choices before the audit.
95
+ - Do not overwrite existing icon, social image, README, site, workflows, or funding files unless the user approves a change or the audit classifies the item as weak.
96
+ - If everything publish-critical is ready, say so and offer only optional improvements.
97
+ - If the user asks to "run the skill" without more detail, audit first, then wait for approval before making non-trivial visual or workflow changes.
98
+ - Keep the audit evidence-based. Reference filenames, workflow names, package metadata, or command outputs.
44
99
 
45
100
  ## Minimal Icon
46
101
 
package/packages/software-development/open-source-publisher/adapters/cursor/skills/open-source-publisher/SKILL.md CHANGED
@@ -20,7 +20,7 @@ metadata:
20
20
 
21
21
  # open-source-publisher
22
22
 
23
- Use this skill to turn a useful OSS repository into a clean public package: recognizable icon, shareable social image, GitHub Pages site, standardized README, CI/CD hygiene, release readiness, and optional donation links.
23
+ Use this skill to audit whether an OSS repository is ready to publish, then help only with missing or weak pieces: recognizable icon, shareable social image, GitHub Pages site, standardized README, CI/CD hygiene, release readiness, and optional donation links.
24
24
 
25
25
  ## Workflow
26
26
 
@@ -28,19 +28,74 @@ Use this skill to turn a useful OSS repository into a clean public package: reco
28
28
  - package/tooling files: `go.mod`, `package.json`, `pyproject.toml`, `Cargo.toml`, `Makefile`, etc.
29
29
  - current README, docs, website files, images, workflows, releases, license, funding files
30
30
  - existing product purpose, author, install paths, examples, and public URLs
31
- 2. Ask only the choices that cannot be inferred:
32
- - GitHub Pages style: `oldschool linux`, `terminal`, `modern`, `brutalist`, `glassmorphism`, `y2k`, `hacker`, or a custom style.
33
- - Donations: `none`, `GitHub Sponsors`, `Ko-fi`, `Buy Me a Coffee`, `Open Collective`, `Thanks.dev`, or custom URL.
31
+ 2. Produce a readiness audit before asking for changes:
32
+ - `Ready`: publish-critical pieces that already exist and look usable
33
+ - `Weak`: existing pieces that are present but incomplete, stale, broken, inconsistent, or below the house standard
34
+ - `Missing`: publish-critical pieces that do not exist
35
+ - `Optional`: nice-to-have pieces such as donations or extra badges
36
+ 3. For existing usable pieces, do not propose replacement by default. Ask a change-oriented question only when useful, for example:
37
+ - "You already have a terminal-style GitHub Pages site. Do you want to keep it or restyle it?"
38
+ - "You already have an icon and social card. Do you want a refresh, or should I leave them as-is?"
39
+ - "You already have release automation. Do you want me to audit only, or also tighten it?"
40
+ 4. Ask only for choices needed to fix missing or weak pieces:
41
+ - If GitHub Pages is missing or weak, ask for style: `oldschool linux`, `terminal`, `modern`, `brutalist`, `glassmorphism`, `y2k`, `hacker`, or custom.
42
+ - 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.
34
43
  - If the repo has no clear product essence, ask for a one-sentence positioning statement.
35
- 3. Implement in this order:
44
+ 5. Implement only approved, missing, or weak work in this order:
36
45
  - minimal icon
37
46
  - social preview image
38
47
  - README standard
39
48
  - GitHub Pages landing page
40
49
  - CI/CD and release audit/fixes
41
50
  - donation wiring, if requested
42
- 4. Validate locally and with browser/screenshots when possible.
43
- 5. Commit/push only when the user asks or the current task explicitly requires it.
51
+ 6. Validate locally and with browser/screenshots when possible.
52
+ 7. Commit/push only when the user asks or the current task explicitly requires it.
53
+
54
+ ## Readiness Audit
55
+
56
+ Treat this skill as an OSS publishing readiness checker first and an implementer second. The first response after inspection should be a concise audit with concrete evidence from the repo.
57
+
58
+ Publish-critical checklist:
59
+
60
+ - repository identity: clear project name, description, topic/keywords, author, license
61
+ - install path: package manager, release assets, source build, or direct download instructions
62
+ - README standard: centered shields, icon, title, short description, horizontal rule, essential sections
63
+ - icon: simple SVG mark, renders at small sizes, committed in a predictable path
64
+ - social image: 1200x630 image with matching metadata, committed source when practical
65
+ - GitHub Pages or docs site: essential install/examples/links/SEO/Open Graph metadata
66
+ - CI quality gates: formatter, linter/static analysis, tests, build/package check
67
+ - release automation: tags/releases/artifacts/package update flow, docs-only changes excluded where needed
68
+ - security posture: license, security notes or policy, OpenSSF Scorecard or equivalent when appropriate
69
+ - contribution path: issues/PR guidance, support expectations, project status
70
+ - donations: explicitly absent, declined, or configured
71
+
72
+ Audit output format:
73
+
74
+ ```md
75
+ ## OSS Publish Readiness
76
+
77
+ Ready
78
+ - README uses the house top block with test, Go Report Card, and OpenSSF shields.
79
+ - Release workflow builds darwin arm64/amd64 binaries and updates the Homebrew tap.
80
+
81
+ Weak
82
+ - Direct download examples point at a fixed release tag; latest-release URLs would age better.
83
+
84
+ Missing
85
+ - No `.github/FUNDING.yml`; donations are not configured.
86
+
87
+ Questions
88
+ - You already have a terminal-style GitHub Pages site. Keep it, or restyle it?
89
+ - Donations are not configured. Enable them or leave them off?
90
+ ```
91
+
92
+ Rules:
93
+
94
+ - Do not ask for style, donations, or redesign choices before the audit.
95
+ - Do not overwrite existing icon, social image, README, site, workflows, or funding files unless the user approves a change or the audit classifies the item as weak.
96
+ - If everything publish-critical is ready, say so and offer only optional improvements.
97
+ - If the user asks to "run the skill" without more detail, audit first, then wait for approval before making non-trivial visual or workflow changes.
98
+ - Keep the audit evidence-based. Reference filenames, workflow names, package metadata, or command outputs.
44
99
 
45
100
  ## Minimal Icon
46
101
 
package/packages/software-development/open-source-publisher/agents/openai.yaml CHANGED
@@ -1,4 +1,4 @@
1
1
  interface:
2
2
  display_name: "Open Source Publisher"
3
3
  short_description: "Prepare an OSS repository for polished public publishing."
4
- default_prompt: "Use open-source-publisher to prepare this repository for public release with a minimal icon, social image, GitHub Pages site, README standardization, CI/CD checks, and optional donation setup."
4
+ default_prompt: "Use open-source-publisher to audit OSS publishing readiness first, then help only with missing or weak pieces such as icon, social image, GitHub Pages, README standardization, CI/CD checks, release automation, and optional donations."