Agent-agnostic skill collection for Codex, Claude, Cursor, Grok, and other skill-aware tools.

Browse the catalog: skills.olegkoval.com

These skills are opinionated by design. They encode working defaults, preferred tools, and repeatable workflows instead of trying to be neutral snippets. Treat them as starting points with taste: useful out of the box, easy to inspect, and specific enough for an agent to execute consistently.

  PR & GIT        BUILD         OPERATE        IMPROVE        PERSONAL
 ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
 │ github-pr  │ │  product   │ │  web-ops   │ │ skill-meta │ │  creative  │
 │ git-tools  │ │ apple-kit  │ │  obsidian  │ │ reflection │ │            │
 │  release   │ │ garmin-kit │ │            │ │            │ │            │
 └────────────┘ └────────────┘ └────────────┘ └────────────┘ └────────────┘

Start here

Ten skills across different plugins that cover the most common jobs. Full catalog is below.

Quick Start

/plugin marketplace add oleg-koval/agent-skills

/plugin install olko-github-pr@olko-agent-skills
/plugin install olko-git-tools@olko-agent-skills
/plugin install olko-release@olko-agent-skills
/plugin install olko-product@olko-agent-skills
/plugin install olko-skill-meta@olko-agent-skills
/plugin install olko-reflection@olko-agent-skills
/plugin install olko-obsidian@olko-agent-skills
/plugin install olko-apple-kit@olko-agent-skills
/plugin install olko-garmin-kit@olko-agent-skills
/plugin install olko-creative@olko-agent-skills
/plugin install olko-web-ops@olko-agent-skills

/plugin uninstall olko-agent-skills@olko-agent-skills

git clone https://github.com/oleg-koval/agent-skills.git
claude --plugin-dir /path/to/agent-skills

git clone https://github.com/oleg-koval/agent-skills.git
cd agent-skills
./scripts/install-codex-symlinks.sh

Use the olko:semantic-release-beta skill to add prereleases on a beta branch.

grok plugin marketplace add oleg-koval/agent-skills

grok agent --plugin-dir /path/to/agent-skills

plugins/{plugin}/skills/{skill}/SKILL.md

All 53 Skills

Each entry links to its SKILL.md. Reference any skill by its olko:* lookup name in a new agent session. Skills are grouped by the plugin that owns them.

olko-github-pr (11)

Drive GitHub pull requests to merge-ready: review-bot loops, CI fixes, descriptions, dependency triage.

lekker-review at a glance

Full write-up in the skill README.

olko-git-tools (3)

Everyday git and GitHub CLI operations: conventional commits, branch hygiene.

olko-release (5)

Ship a release: semantic-release setup, changelogs, store listing copy, release-day routine.

olko-product (5)

Take a product idea to a shippable build: MVP passes, full-stack scaffolds, UX/UI quality loops, launch plans.

olko-skill-meta (8)

Author and maintain agent skills and the AI toolchain itself.

olko-reflection (6)

Look back and improve: self-critique, retrospectives, performance review, rapid learning.

olko-obsidian (3)

Keep an Obsidian vault in sync with work: PR sync, task rollover, morning routine.

olko-apple-kit (2)

Build and ship Apple platform apps: macOS menubar apps, App Store submissions.

olko-garmin-kit (1)

Build, test and publish Garmin Connect IQ watch faces.

olko-creative (5)

Creative and personal projects: photo galleries, music players, Plex ingest, listings, wiki editing.

olko-web-ops (4)

Operate a website: WAF rules, search console audits, analytics bootstrap, docs indexes.

How Skills Work

Every skill package follows a consistent anatomy:

┌─────────────────────────────────────────────────────┐
│  SKILL.md                                            │
│                                                       │
│  ┌─ Frontmatter ─────────────────────────────────┐   │
│  │ name: lowercase-hyphen-name                    │   │
│  │ description: What this skill does. Use when…   │   │
│  │ license / allowed-tools / compatibility        │   │
│  └─────────────────────────────────────────────────┘  │
│  Body            → numbered steps or phases,          │
│                     specific to the task               │
│  Report          → what to hand back and how           │
└─────────────────────────────────────────────────────┘

Key design choices:

• Progressive disclosure. Only name and description load into an agent's context up front. The body loads on invocation, which is why every description also carries its own "Use when" clause: it is the only routing signal an agent sees before deciding whether to open the file.
• One canonical package per workflow. plugins/olko-{plugin}/skills/{skill}/SKILL.md is the single source; agent-specific wrappers wrap it, they never fork it.
• Description is the router. A skill's description must say what it does and name the phrases a user would actually type, because that sentence is what an agent matches against, not the body.
• Process over prose. Skills read as workflows to follow (numbered steps, phases, gates), not as reference essays.
• Adapters stay generated. Per-tool wrappers under adapters/, .windsurf/rules/, .kiro/steering/, .github/prompts/ and similar are built from catalog/skills.json; nothing there is hand-written.

Install the Codex symlinks, then mention a skill by its lookup name in a new agent session:

./scripts/install-codex-symlinks.sh

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.

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.

Use the olko:viral-launch skill to make this project launch-ready.

Each skill has a canonical SKILL.md under plugins/{plugin}/skills/{skill}/. Agent-specific wrappers live under that plugin's adapters/ directory.

Project Structure

agent-skills/
├── plugins/
│   └── olko-{plugin}/
│       ├── .claude-plugin/plugin.json   # generated
│       └── skills/{skill}/
│           ├── SKILL.md                 # canonical, source of truth for the skill
│           └── references/              # optional, loaded only when needed
├── catalog/
│   └── skills.json                      # source of truth for plugin/skill metadata
├── adapters/                            # generated, one tree per tool
│   ├── claude/
│   ├── codex/
│   ├── cursor/
│   ├── grok/
│   ├── pi/
│   └── hermes/
├── .claude-plugin/marketplace.json      # generated, lists all 11 plugins
├── .cursor-plugin/index.json            # generated
├── .grok-plugin/index.json              # generated
├── .windsurf/rules/                     # generated
├── .kiro/steering/                      # generated
├── .github/prompts/                     # generated
├── .github/copilot-instructions.md      # generated
├── docs/
│   ├── versioning.md                    # catalog/plugin versioning contract
│   ├── agent-context-store.md           # shared context store contract
│   ├── skill-anatomy.md                 # SKILL.md format spec
│   ├── backlog/                         # durable, non-obvious lessons
│   └── plans/completed/                 # finished planning docs
├── scripts/                             # sync, build, and validation helpers
├── site/                                # generator for skills.olegkoval.com
└── tests/                               # bash + node validators

Why this catalog?

AI agents left to their own defaults improvise a workflow every time, and that workflow drifts with whatever the model feels like doing that day. This catalog exists to pin the workflow down: a fixed set of steps, tools, and defaults for the jobs that come up often enough to be worth writing down once.

The guiding rules:

• One canonical skill package per workflow. No duplicated logic across tools.
• Agent-specific wrappers live in adapters/, not inside the skill. The canonical package never forks per tool.
• Catalogs stay neutral and machine-readable. catalog/skills.json is the one place metadata changes.
• Marketplace metadata sits on top of the canonical package, never instead of it.

And the catalog is opinionated on purpose. These are working defaults, preferred tools, and repeatable workflows, not neutral snippets meant to suit every team. Useful out of the box, easy to inspect, specific enough that an agent executes them the same way twice.

How it compares

addyosmani/agent-skills covers the software development lifecycle: spec, plan, build, test, review, ship. obra/superpowers is about process discipline while an agent works. This catalog sits next to both rather than competing with them: it is personal-workflow and operations oriented, built around the jobs that come up running a one-person shop across several codebases, not around building any single piece of software. That means PR review-bot loops and release-day orchestration, an Obsidian daily-note routine, retrospectives over what actually shipped, and skills for entirely personal projects (a watch face, a Vinted listing, a music player). Install this catalog alongside a lifecycle pack or a process-discipline pack; they cover different parts of the day.

Shared context store

retro-analysis and shared-knowledge-artifact share one private GitHub repository, resolved through the context-repo skill the first time either one runs. It finds a store before it creates one: private repositories are probed for a root ledger.json and a retro/ directory, and a match is adopted whatever it is called, so an existing store is never duplicated. Only when nothing matches does it ask, stating the owner, name, and every path it will write. The repository stays private; n keeps that run local-only and asks again next time, never stops the prompt for good, and a missing or unauthenticated gh falls back to local-only automatically.

The pointer lives at ${XDG_CONFIG_HOME:-$HOME/.config}/agent-context/config.json; the clone lives at ${XDG_DATA_HOME:-$HOME/.local/share}/agent-context/repo. See docs/agent-context-store.md for the repository layout, the first-run walkthrough, and the contract callers follow when writing to it.

Generated manifests

Every file above is generated from catalog/skills.json by ./scripts/build-adapters.sh. Never edit one by hand: CI regenerates and fails on any difference.

Coverage is per skill, not uniform. Each skill's adapters array in catalog/skills.json decides which targets it ships to, so the file counts differ per target: Claude 49, Grok 47, Cursor 45, Copilot 45, Codex 42, Windsurf 35, Kiro 35, Pi 2, Hermes 2. A skill is absent from a target's tree when its catalog entry does not list that target.

Local validation

Rebuild generated manifests:

npm run build

or directly:

./scripts/build-adapters.sh

Validate the neutral catalog and generated root manifests:

npm run validate

Run the full test suite (validators plus the bash tests in tests/):

npm test

Run both build and validate before pushing marketplace updates:

./scripts/build-adapters.sh && ./scripts/validate-catalog.sh

Contributing

Adding a skill:

1. Create plugins/olko-<plugin>/skills/<skill>/SKILL.md with valid frontmatter.
2. Register it under that plugin's skills array in catalog/skills.json.
3. Add it to PLUGIN_ASSIGNMENT in scripts/lib/catalog.mjs.
4. Add its row to this README's skill table.
5. Run ./scripts/build-adapters.sh && npm test.

The description rule is not optional: a skill's description must say what it does AND carry a "Use when" clause with the phrases a user would actually type. Because of progressive disclosure, that description is the only routing signal an agent sees before it decides whether to open the skill at all.

No em dashes in skill content or generated text. Commit messages are conventional (feat:, fix:, refactor:, docs:, test:, chore:); semantic-release parses them.

Team

	Name	GitHub	Role
	Oleg Koval	@oleg-koval	Creator

License

MIT. Use these skills in your own projects and tools.