菜单
Apps/web release metadata and version-badge guidance for Tuturuuu platform work, including release-please-managed TUTURUUU_PLATFORM_VERSION metadata, blue/green runtime snapshot fallbacks, PLATFORM_BUILD metadata, and focused release verification.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Tuturuuu Flutter mobile task-board workflow guidance. Use when Codex changes apps/mobile task board behavior, task detail routing, task dates, overdue labels, assignees, task description view/edit mode, task list refreshes, workspace-aware navigation, mobile BLoC/Cubit code, or release-please-managed mobile release metadata.
Tuturuuu CLI task workflow guidance. Use when listing, reading, creating, templating, splitting, moving, closing, or marking Tuturuuu tasks through `ttr tasks` or `ttr task-templates`, including task board/list/label discovery, compact output, task mutation verification, and ttr-first task capture.
Tuturuuu browser and Vercel CLI development, production troubleshooting, verification, performance, and product-improvement guidance. Use when reproducing a deployed UI or API bug, correlating browser failures with Vercel runtime/build logs, checking satellite-domain routing and authentication, auditing responsive or i18n behavior, investigating Vercel cost or latency, or verifying a fix without modifying customer data.
Tuturuuu development tooling and shared-learning guidance. Use when improving Codex skills, plugin behavior, repo automation, validation scripts, docs runbooks, developer experience, agent workflows, or recurring learnings that should benefit future Tuturuuu contributors and assistants.
Tuturuuu platform monorepo workflow guidance. Use when Codex works in the tutur3u/platform repo or a local Tuturuuu platform checkout, especially for apps/web Next.js changes, packages/* shared code, apps/database Supabase migrations, apps/docs documentation, translations, navigation, TanStack Query data fetching, repo verification, or Conventional Commit/branch follow-through.
Use when any harness (Codex, Claude Code, or another assistant) works in a dirty or shared Tuturuuu checkout, spans separate git worktrees or branches, encounters active or archived coordination notes, needs ownership context, has overlapping paths, is handing off work between agents or tools, must protect uncommitted work from concurrent destructive Git, must archive completed coordination notes, or must coordinate staged paths and commit windows.
| name | tuturuuu-web-release |
| description | Apps/web release metadata and version-badge guidance for Tuturuuu platform work, including release-please-managed TUTURUUU_PLATFORM_VERSION metadata, blue/green runtime snapshot fallbacks, PLATFORM_BUILD metadata, and focused release verification. |
Use this skill when touching the apps/web version badge, platform release
metadata, Docker blue/green deployment metadata, release docs, or release-please
version metadata.
TUTURUUU_PLATFORM_VERSION in @tuturuuu/utils/platform-release as
the displayed platform badge version. Do not manually bump it for ordinary
authored commits; Release Please updates it from platform-version.txt.x-release-please-version comments on the platform version constant
and matching test expectation. The monorepo release-please config also keeps
platform-version.txt aligned for the platform release component.apps/web/package.json for badge/version display unless the user
explicitly asks for package metadata changes.@tuturuuu.com users can see/manage the
badge, and the user setting remains opt-in.prod/target-state.json, prod/active-color, prod/deployment-stamp,
watch/blue-green-auto-deploy.status.json, and
watch/blue-green-auto-deploy.history.json.For apps/web, keep metadata precedence stable:
PLATFORM_BUILD_* runtime environment values.PLATFORM_BLUE_GREEN_MONITORING_DIR,
with local tmp/docker-web fallbacks for development.Do not invent deployment URL, ref, or environment from active color, commit hash, or deployment stamp alone. Use those fields only when an explicit env, runtime row, status snapshot, or generated metadata provides them.
builtAt means the checked-out source commit timestamp. Do not populate it
from deployment start, finish, activation, promotion, or wall-clock time. Keep
those deployment timestamps in GitHub/Vercel records and blue/green history.
Read references/web-release-checklist.md when implementing or reviewing
release metadata changes. It lists the expected files, fallback selection order,
and focused verification commands.