メニュー
Prepare a MemoryLane release by updating the version and release notes, then creating and pushing the tagged release commit that triggers CI. Use when the user asks to release, ship, publish, bump version, or cut a stable or prerelease version.
Write step-by-step automation instructions for a workflow, tailored to your tool (Claude, n8n or Zapier). Best run right after discover-patterns or process-analyst.
(new) Find a person's repeated tasks from their screen activity, and what each one is worth automating, with the time and money saved. Outputs the numbers and data a report is built from, not the visual. Use to analyze processes, mine workflows, or see what is automatable and what it saves. Every figure is labelled and grounded, never made up.
(new) Turn a process analysis into a polished, client-ready report, first an HTML deck you review, then a matching PDF. Use to package an analysis into an exec report or PDF. Shows the deck for approval before making the PDF, and never makes up numbers.
Generate a time report grouped by client/project
Discover repeated workflow patterns from screen activity and suggest automations
Summarize what you've been doing in the last 30 minutes.
| name | release |
| description | Prepare a MemoryLane release by updating the version and release notes, then creating and pushing the tagged release commit that triggers CI. Use when the user asks to release, ship, publish, bump version, or cut a stable or prerelease version. |
Use this skill for both normal releases and prereleases. The GitHub Actions release pipeline builds macOS and Windows artifacts after the tagged commit is pushed. Tags without a suffix publish regular releases. Tags with a semver suffix such as -beta.1 publish GitHub prereleases.
git status shows nothing to commit)main branch, up to date with originnpm installnpm install
Always run this first so all workspace packages are present before any release edits, checks, or git operations.
Ask the user if not provided.
MAJOR.MINOR.PATCHMAJOR.MINOR.PATCH-label.NThe git tag format is always v<version>.
git log --oneline $(git describe --tags --abbrev=0)..HEAD
git diff --stat $(git describe --tags --abbrev=0)..HEAD
Summarize the key user-facing changes. This drives RELEASE_NOTES.md.
package.jsonUpdate the "version" field to the new version.
RELEASE_NOTES.mdFollow the existing format in the file. Keep the wording brief and current.
# MemoryLane vX.Y.Zcloses #4).README.md if neededCheck the "Coming Soon" and "Limitations" sections. If a released feature is listed there, move or remove it.
npm run format
npm run lint
Stage only the files you changed:
git add package.json package-lock.json RELEASE_NOTES.md
# Add README.md only if it changed for this release.
git add README.md
git commit -m "release: vX.Y.Z"
git tag vX.Y.Z
Create the tag only after the commit succeeds. Do not run git commit and git tag in parallel.
If the version is a prerelease, keep the same commit format and tag shape:
git commit -m "release: vX.Y.Z-label.N"
git tag vX.Y.Z-label.N
After tagging, verify it points at the release commit:
git rev-parse HEAD
git rev-parse vX.Y.Z
For prereleases:
git rev-parse HEAD
git rev-parse vX.Y.Z-label.N
These SHAs must match before pushing.
git push origin HEAD
git push origin vX.Y.Z
For a prerelease version, push the prerelease tag instead:
git push origin HEAD
git push origin vX.Y.Z-label.N
Pushing the tag triggers .github/workflows/release.yml. That workflow builds both platforms and creates the GitHub release automatically.
Before finishing, verify:
package.json version matches the new tagpackage-lock.json version matches the new tagRELEASE_NOTES.md title and changelog link reference the new versionREADME.md "Coming Soon" doesn't list shipped featuresnpm install has been run before release stepsnpm run format and npm run lint passv<version> tag is pushed to origin