Use when preparing a PlainTab release or bumping the PlainTab version, triggered by phrases like "更新版本", "bump version", "upgrade to vX.Y.Z", "发布新版本". Updates manifest.json, runtime UI/version constants, localized changelogs, store listings, release notes, validation notes, and current project docs.
Prepare and create PlainTab git commits with scoped Conventional Commit subjects and detailed commit bodies. Use when the user asks to commit, 提交, create a git commit, stage changes, or asks for precise Conventional Commits / Google-style commit messages; especially when the worktree may contain unrelated user changes.
Use when diagnosing PlainTab bugs, broken UI behavior, failing extension/web-mode flows, storage or wallpaper regressions, startup issues, or performance regressions.
Use when reviewing PlainTab architecture, looking for refactoring opportunities, reducing coupling, improving testability, or making modules easier for agents to understand without redesigning stable behavior.
Use before changing PlainTab persistent storage, including localStorage keys, IndexedDB keys or record formats, LSVERSION, DBVERSION, ptabschemaversion, migration code, backup/import/export storage shape, wallpaper cache cleanup, or any task that may affect old users upgrading across versions.
Use when implementing PlainTab features or bug fixes with test-first development, red-green-refactor, regression scripts, browser checks, or behavior-focused validation before production code changes.
Maintain PlainTab runtime UI translations and i18n language packs. Use when adding, editing, formatting, validating, or reviewing UI text in js/i18n/.js, js/languages.js, data-i18n markup, or t(key) calls; also use when onboarding/help copy or new settings need localized strings.
Use when an agent or user is unfamiliar with a PlainTab module, needs a higher-level map of related files and callers, or asks how a section fits into startup, wallpaper, settings, search, command palette, storage, or i18n flows.