# Skillshare Release

Prepare and review skillshare releases using the Release Please PR, verify the proposed...

- Repository: https://github.com/runkids/skillshare (2879 stars)
- Category: Git and review
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add runkids/skillshare --skill skillshare-release -g -a claude-code -y`
Codex: `npx skills add runkids/skillshare --skill skillshare-release -g -a codex -y`
Cursor: `npx skills add runkids/skillshare --skill skillshare-release -g -a cursor -y`
Gemini CLI: `npx skills add runkids/skillshare --skill skillshare-release -g -a gemini-cli -y`

## Description

Prepare and review skillshare releases using the Release Please PR, verify the proposed version and changelog, inspect draft assets, and publish through the manual Publish Release workflow when explicitly authorized. Use when the user says "release", "prepare release", "cut a release", or asks to publish a new version. For changelog-only tasks, use /changelog instead.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

Prepare or review a skillshare release. An optional version argument is an explicit requested version, not permission to commit, merge, tag, push, or publish.

Before acting, run `python3 scripts/ai-context.py release testing`. These topics are the source of truth for authorization, version policy, automation and verification.

## Workflow

### 1. Identify the release

Inspect Git status, the latest published release and the open Release PR. Preserve unrelated work. The manifest at `.github/release-please-manifest.json` is the release version source; the development CLI still defaults to `dev`.

Pushes to `main` create or update a Release PR. If one is missing, report the workflow state and required repository permissions. Dispatch the Release Please workflow only when the user authorizes that external action.

For `0.x`, `fix` and `perf` increment patch; `feat` and breaking changes increment minor. A breaking change needs migration notes. Moving to `1.0.0` requires an explicit version decision. For an override, use a `Release-As: X.Y.Z` commit footer or a reviewed `release-as` configuration value; remove a configuration override after it has been consumed. Do not edit the tracking manifest by itself to request a release.

#### Explicit version requests

When the user requests a version such as `0.23.3`, prepare a `Release-As: 0.23.3` footer on a normal development commit that will reach `main` before the Release PR is merged. For a batch with multiple commits, adding it once to the final commit is sufficient; the override chooses the version for the entire pending release, including the earlier changes. Intermediate versions do not need to be published.

```text
fix: correct sync behavior

Release-As: 0.23.3
```

The rest: https://github.com/runkids/skillshare/blob/HEAD/.skillshare/skills/skillshare-release/SKILL.md