Package any website or local web build into a lightweight desktop app using Pake (Tauri/Rust). Use when the user wants to: wrap a URL as a native app, build a desktop app from a website or a local dist/ folder, use Pake CLI to package a page, set up proxy for a packaged app, customize app icons or bundle IDs, or mentions 'pake', 'tauri package', 'website to app', 'wrap site'. Also trigger when the user asks about Pake CLI options, proxy configuration for packaged apps, or icon handling.

2026-07-1860.2k

code-review

tw93/Pake

Pake project adapter for Waza check/code-review. Use for TypeScript CLI, Rust/Tauri, release artifact, and CI review.

2026-07-1060.2k

GitHub Operations Skill

Use this skill when working with GitHub issues, PRs, and releases for Pake. It carries the project facts and boundaries; standard gh usage is assumed.

Golden Rule

Always use gh CLI and query live state before acting. Never assume state from memory or a previous turn.

Project Facts

Repo: tw93/Pake. Workflows: release.yml (V* tag, builds app assets), npm-publish.yml (npm Trusted Publishing; also workflow_dispatch from main for npm-only hotfixes), quality-and-test.yml (push CI), pake-cli.yaml / single-app.yaml (public build surfaces external users trigger from forks).

Poll CI with gh run view <run-id> --json status,conclusion. Never pipe gh run watch or build output through tail/head; pipes swallow the real exit code and misreport failures as green.

Verify npm state with npm view pake-cli@<version> version gitHead dist.tarball --json; gitHead ties the published package to the intended commit. Check the latest pointer separately with npm view pake-cli version; it can point at a different commit than the fix under review.

Inline PR review comments live at gh api repos/tw93/Pake/pulls/<n>/comments; gh pr view does not show them.

App-release truth is gh release view <tag> --json assets (asset count/state), not workflow names or source state.

Safety Rules

ALWAYS draft the reply first and show it to the user for approval before calling any write operation (gh issue comment, gh pr comment, gh pr merge, gh issue close, gh release create, etc.). Approval of one draft does not extend to future comments.

NEVER merge, close, or modify without explicit user request.

ALWAYS query current state before taking action — never assume.

Before replying to an issue or PR, read the body to confirm the author's language; match their language in the reply. This applies to the author, not to arbitrary thread commenters.

Before replying that a CLI fix is released, verify the exact artifact with npm view pake-cli@<version> version gitHead dist.tarball --json and confirm gitHead contains the fix. Check npm view pake-cli version separately for the latest pointer. For app releases, use gh release view <tag> --json assets.

Before closing an issue after release, confirm the target with gh issue view <id> --json number,title,state,author,url and include the concrete version or upgrade command in the comment.