一键导入
release
Release the screenpipe monorepo. Bumps versions, triggers GitHub Actions for app, CLI, MCP, and JS packages.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Release the screenpipe monorepo. Bumps versions, triggers GitHub Actions for app, CLI, MCP, and JS packages.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
| name | release |
| description | Release the screenpipe monorepo. Bumps versions, triggers GitHub Actions for app, CLI, MCP, and JS packages. |
| allowed-tools | Bash, Read, Edit, Grep, Write |
Automate releasing all components of the screenpipe monorepo.
| Component | Version File | Current Pattern | Workflow |
|---|---|---|---|
| Desktop App | apps/screenpipe-app-tauri/src-tauri/Cargo.toml | version = "X.Y.Z" | release-app.yml |
| CLI/Server | Cargo.toml (workspace.package) | version = "0.2.X" | release-cli.yml |
| MCP | packages/screenpipe-mcp/package.json | "version": "X.Y.Z" | release-mcp.yml |
Always release CLI when there are changes to core screenpipe code:
screenpipe-core/screenpipe-vision/screenpipe-audio/screenpipe-server/screenpipe-db/screenpipe-events/screenpipe-integrations/App-only release is fine when changes are only in:
apps/screenpipe-app-tauri/ (UI/frontend changes)#[tauri::command] handlers: from apps/screenpipe-app-tauri/, run bun run bindings:generate and verify bun run bindings:check before taggingTo check what changed since last CLI release:
# Find last CLI release commit
git log --oneline --all | grep -E "CLI to v" | head -1
# Check if core code changed since then
git diff <COMMIT>..HEAD --stat -- screenpipe-core screenpipe-vision screenpipe-audio screenpipe-server screenpipe-db screenpipe-events screenpipe-integrations
echo "=== App ===" && grep '^version' apps/screenpipe-app-tauri/src-tauri/Cargo.toml | head -1
echo "=== CLI ===" && grep '^version' Cargo.toml | head -1
echo "=== MCP ===" && grep '"version"' packages/screenpipe-mcp/package.json | head -1
Edit apps/screenpipe-app-tauri/src-tauri/Cargo.toml and bump the version = "X.Y.Z" line at the top of [package].
git add -A && git commit -m "Bump app to vX.Y.Z" && git pull --rebase && git push
Pushing a commit whose message starts with Bump app or release-app to main triggers release-app.yml automatically (check_commit job gates on the prefix). The build is a draft only — does NOT auto-publish. Use the release-app-publish prefix to auto-publish instead.
Do NOT also run gh workflow run release-app.yml — it fires a second workflow_dispatch run on the same SHA, doubling the build. The push handles it.
# Get latest run ID
gh run list --workflow=release-app.yml --limit=1
# Check status
gh run view <RUN_ID> --json status,conclusion,jobs --jq '{status: .status, conclusion: .conclusion, jobs: [.jobs[] | {name: (.name | split(",")[0]), status: .status, conclusion: .conclusion}]}'
After testing, publish via the Cloudflare R2 / backend dashboard, OR commit with magic words:
git commit --allow-empty -m "release-app-publish" && git push
# 1. Bump version in apps/apps/screenpipe-app-tauri/src-tauri/Cargo.toml
# 2. Commit and push — the "Bump app" prefix triggers release-app.yml automatically
git add -A && git commit -m "Bump app to vX.Y.Z" && git push
# 3. Monitor
sleep 5 && gh run list --workflow=release-app.yml --limit=1
Build <RUN_ID>:
| Platform | Status |
|----------|--------|
| macOS aarch64 | ✅ success / 🔄 in_progress / ❌ failure |
| macOS x86_64 | ✅ success / 🔄 in_progress / ❌ failure |
| Windows | ✅ success / 🔄 in_progress / ❌ failure |
gh run view <RUN_ID> --log-failed 2>&1 | tail -100
gh run cancel <RUN_ID>
gh run rerun <RUN_ID> --failed
The CI copies tauri.prod.conf.json to tauri.conf.json before building. If artifacts are missing:
tauri.prod.conf.json has "createUpdaterArtifacts": truetauri.conf.json - Dev config (identifier: screenpi.pe.dev)tauri.prod.conf.json - Prod config (identifier: screenpi.pe, updater enabled)CI automatically uses prod config for releases by copying it before build.
Bump app or release-app pushed to main → Draft releaserelease-app-publish pushed to main → Auto-publish after successful buildworkflow_dispatch (manual gh workflow run) → Draft release (redundant with the push trigger; avoid using both).tar.gz/.sig, Windows uses .nsis.zip/.sig基于 SOC 职业分类
Query the user's screen recordings, audio, UI elements, and usage analytics via the local Screenpipe REST API at localhost:3030. Use when the user asks about their screen activity, meetings, apps, productivity, media export, retranscription, or connected services.
Query the user's data via the local screenpipe REST API at localhost:3030 — screen recordings, audio, UI elements, usage analytics, meetings, connected services, and the user's persistent memory store. Use for questions about screen activity, meetings, apps, productivity, media export, retranscription, connections, OR to save / remember / store information for later (POST /memories — survives across sessions, queryable by external agents).
Produce a human-facing visual report — a chart, dashboard, scorecard, or styled summary — that renders as a live page in the screenpipe viewer instead of plain text. Use when the task asks for a visual/graphical output rather than a plain note; do NOT use for plain text or raw data (prefer a markdown note for those).
Manage screenpipe pipes (scheduled AI automations) and connections (Telegram, Slack, Discord, etc.) via the CLI. Use when the user asks to create, list, enable, disable, run, or debug pipes, or manage service connections from the command line.
Manage screenpipe pipes (scheduled AI automations) and connections (Telegram, Slack, Discord, etc.) via the CLI. Use when the user asks to create, list, enable, disable, run, or debug pipes, or manage service connections from the command line.
Add or change Tauri commands and TypeScript bindings in the screenpipe desktop app. Use when editing