.agents/skills/desktop-release/SKILL.md
Perform a regular desktop release from the dev branch. Gather changes since the last desktop tag, update the changelog, choose the desktop release mode in release-plan.json, bump the version, and prepare the release PR.
npx skillsauth add rssnext/folo desktop-releaseInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Perform a regular desktop release from the dev branch.
This workflow is now file-driven:
apps/desktop/changelog/next.md is the human-edited changelog draft.apps/desktop/release-plan.json is the human-edited release intent.pnpm --dir apps/desktop bump applies both inputs, writes apps/desktop/release.json, resets apps/desktop/release-plan.json, bumps the version, creates release/desktop/{NEW_VERSION}, pushes it, and opens the PR.Important notes:
mainHash is still regenerated automatically, but it is not the OTA compatibility switch anymore. Do not use it as the release decision point.runtimeVersion in apps/desktop/package.json is the desktop OTA compatibility key. apps/desktop/scripts/apply-release-config.impl.ts writes it during bump.build and ota desktop release flow.build and ota.dev. If not, abort with a warning.git pull --rebase in the repo root to ensure the local branch is up to date.apps/desktop/package.jsonapps/desktop/release-plan.jsonapps/desktop/release.jsonapps/desktop/bump.config.tsversionruntimeVersionrelease-plan.json contentspnpm --dir apps/desktop bump will push a branch and open a PR. Do not run it without explicit user approval.git tag --sort=-creatordate | grep '^desktop/v' | head -1
git log <last-tag>..HEAD --oneline --no-merges
apps/desktop/changelog/next.md.apps/desktop/changelog/next.md using the existing template structure.NEXT_VERSION as the placeholder. apps/desktop/scripts/apply-changelog.ts replaces it during bump.This replaces the old mainHash decision.
Inspect runtime-affecting changes since the last desktop tag:
git diff <last-tag>..HEAD --name-only -- \
apps/desktop/layer/main/ \
apps/desktop/layer/preload/ \
apps/desktop/forge.config.cts \
apps/desktop/resources/ \
apps/desktop/scripts/ \
apps/desktop/package.json
Use this decision table:
build
Use this when the release requires a new binary.
Typical triggers:
ota
Use this when the release is renderer-compatible with an already-installed binary.
Typical triggers:
For ota, you must choose:
runtimeVersion: the newest installed desktop binary version that this renderer update is compatible withchannel: usually stableIf you are unsure whether a change is binary-compatible, prefer build.
Present the analysis to the user with:
build or otarelease-plan.jsonapps/desktop/changelog/next.md.apps/desktop/release-plan.json.apps/desktop/release.json directly. It is generated during bump.nbump requires a clean working tree, commit the release inputs before bump.Stage the inputs:
git add apps/desktop/changelog/next.md apps/desktop/release-plan.json
Commit them on dev:
git commit -m "docs(desktop): prepare release inputs"
If there are no changes to commit, continue.
Do not execute this step until the user explicitly approves pushing code.
Run:
pnpm --dir apps/desktop bump
This command currently does all of the following:
mainHashapps/desktop/scripts/apply-release-config.ts ${NEW_VERSION}apps/desktop/release.jsonapps/desktop/package.json runtimeVersionapps/desktop/release-plan.json back to the default build templaterelease(desktop): release v{NEW_VERSION}release/desktop/{NEW_VERSION}mainAfter bump completes, verify:
release/desktop/{NEW_VERSION}.apps/desktop/package.json has the expected:
versionruntimeVersionapps/desktop/release.json matches the intended mode and release settings.apps/desktop/release-plan.json was reset to the default template.Also note what will happen after merge:
main triggers .github/workflows/tag.ymltag.yml creates desktop/v{NEW_VERSION}tag.yml dispatches .github/workflows/build-desktop.ymlbuild-desktop.yml publishes the desktop release draftExpected release artifacts by mode:
build
publishes binary artifacts and desktop binary metadata (ota-release.json)
ota
publishes binary artifacts, desktop binary metadata, and renderer OTA assets such as:
apps/desktop/dist/manifest.ymlapps/desktop/dist/*.tar.gzapps/desktop/dist/ota-release.jsonapps/desktop/dist.tar.zstSummarize:
v{NEW_VERSION}build or otaruntimeVersionWhen mentioning mainHash, only describe it as "regenerated automatically", never as the release decision mechanism.
apps/desktop/bump.config.tsapps/desktop/changelog/apps/desktop/changelog/next.template.mdapps/desktop/scripts/apply-changelog.tsapps/desktop/release-plan.jsonapps/desktop/release.jsonapps/desktop/scripts/apply-release-config.impl.ts.github/scripts/resolve-desktop-release-config.mjs.github/scripts/build-ota-release.mjs.github/workflows/build-desktop.yml.github/workflows/tag.ymlapps/desktop/layer/main/src/updater/hot-updater.tstools
# Folo CLI Skill ## Trigger Conditions Use this skill when a user asks to: - Manage RSS subscriptions - Browse timeline entries - Read entry details or readability content - Mark entries as read/unread - Search feeds/lists or trending sources - Import/export OPML - Check unread counts ## Preconditions 1. Node.js and npm are installed so the CLI can be executed with `npx`. 2. Authentication is configured: - `npx --yes folocli@latest login` (recommended, opens browser and auto-logins) -
development
Update all dependencies across frontend and backend projects. Reads changelogs for breaking changes, checks affected code, runs tests, and provides a summary. Use when updating npm dependencies across the monorepo.
development
Self-test a mobile feature change or bug fix after implementation in `apps/mobile`. Use this whenever the user asks to verify a mobile change, run simulator acceptance, smoke-test a mobile PR, or provide screenshot proof for a mobile fix. This skill decides between prod vs local API mode, starts the local follow-server when needed, builds a release app, uses Maestro only to bootstrap registration for non-auth work, then switches to screenshot-driven visual validation and returns screenshot evidence.
development
Use when preparing a mobile release from the dev branch and deciding whether changes should ship through the app stores or through the OTA pipeline before creating the release PR to mobile-main.