atmos

Refresh the Atmos landing-page changelog from the GitHub Releases page. Use when Codex needs to read `https://github.com/AruNi-01/atmos/releases`, extract release-note content, and rewrite `apps/landing/src/lib/changelog-data.ts` in the shape expected by the landing changelog UI. Supports generating a specific version on demand, or filling only versions that are still missing from the landing data file.

Handle an Atmos review fix run by reading review comments, marking run status with the installed `atmos review` CLI, editing code, replying to each comment, writing a run summary, and finalizing the run into a new review revision.

Write, improve, restructure, audit, or maintain Atmos user documentation. Use this whenever the user asks to create a new docs page, add a workflow guide, revise concepts or terminology, improve existing docs, refresh docs from code/spec/release evidence, sync bilingual docs, or update `apps/docs/content/docs`. Trigger for phrases like "帮我写 docs", "优化文档", "新增一篇 workflow", "调整概念说明", "发布后更新 docs", "docs for this feature", or "keep docs in sync". Reads existing docs and product evidence first, updates English and Chinese MDX together, keeps `meta.json` and `meta.zh.json` navigation aligned, verifies Fumadocs/Next checks, and avoids leaking internal implementation details into user docs.

This skill should be used when the user asks for "specs-view", "spec visualization", "visual HTML for BRAINSTORM/PRD/TECH/TEST", "interactive spec review", or a "specs dashboard". It generates a local, single-file interactive HTML view for one Atmos spec file, one full spec, or a current-session/user-specified specs dashboard. It outputs `index.html` plus `metadata.json` under `.atmos/specs/views/` and never scans the whole `specs/` tree unless the user explicitly names the target specs.

Run the standalone Atmos CLI release workflow for this repository. Use this whenever you need to cut an Atmos CLI release, verify `apps/cli/Cargo.toml`, create or dispatch the required `cli-<version>` GitHub Release, and publish CLI archives. Prefer this over local runtime or generic GitHub release flows for CLI releases.

Run the Atmos desktop release workflow for this repository. Use this whenever you need to cut an Atmos desktop release, bump the desktop version, create the required `desktop-<version>` tag, push the release-prep commit, and verify the GitHub Actions + Homebrew tap flow. Prefer this over a generic GitHub release process for Atmos desktop releases.

Run the Atmos local web runtime release workflow for this repository. Use this whenever you need to cut an Atmos local web runtime release, verify the local runtime version, create the required `local-web-runtime-<version>` tag, and publish the runtime archives. Prefer this over a generic GitHub release process for Atmos local web runtime releases.

Create, edit, or fix Lottie/Bodymovin JSON animations for the local Skia Skottie player. Use for text-to-Lottie, SVG/logo/type animation, loaders/icons, state feedback, UI microinteractions, lower thirds, diagrams, data/stat/chart animations, product promos, scene/camera motion, visual effects, scene edits, slots/controls, and Skottie debugging.

Create or revise premium, product-led Atmos marketing videos and social promo videos using HyperFrames, with an explicit audio generation decision and a strong design/storyboard pass. Use when Codex needs to build, move, render, or maintain video creative projects under marketing/creative, analyze a reference promo video, improve weak creative direction, generate landing-page or X/Threads video assets, decide whether to generate matching audio, sync generated artifacts into app public folders, or avoid known Atmos video mistakes such as generic AI-looking visuals, rainbow palettes, stale logos, graywashing product screenshots, thin/short content, repetitive scene animation, missing agent icons, writing source projects under apps/landing, creating renders/exports directories instead of artifacts, or forgetting deployment copies.

Create or revise clean continuous audio beds for Atmos marketing and HyperFrames videos, including cue maps that follow high-density editorial product videos. Use when generating synthetic WAV background music, adding or replacing promo video music, muxing audio into landing page videos, matching audio energy to video beats, or fixing issues like per-scene pause/play, cue-start stingers, chirpy bells, bird-like transition sounds, harsh high frequencies, or mid-track silence.

Implement an Atmos spec — turn the four spec docs (BRAINSTORM / PRD / TECH / TEST) at `specs/<ZONE>/<ZONE>-NNN_.../` into real production code changes in `crates/`, `apps/`, `packages/`. Use whenever the user says "implement APP-NNN", "ship this spec", "按照 spec 实现", "start coding the PRD", or otherwise transitions from spec authoring to actual engineering. Read all four files first, plan along TECH's rollout, respect Atmos's layered architecture (infra → core-engine → core-service → api → apps) and WebSocket-first transport. Keep existing tests green (regression gate) and run lint+compile on every chunk; delegate authoring new scenario-level tests to the `atmos-specs-test-run` skill. Writes production code (not specs, not new scenario tests); updates specs only when reality forces TECH to change.

Author the scenario-level test plan for an Atmos spec at `specs/<ZONE>/<ZONE>-NNN_.../TEST.md`. Use whenever the user wants to define WHAT to verify for a feature — Given/When/Then scenarios, acceptance criteria, regression checklist, performance budgets, Playwright/E2E coverage, agent-browser exploratory checks, or manual steps. Trigger on "test plan", "测试方案", "acceptance criteria", "验收标准", "how do we verify", "QA checklist", or after PRD/TECH has stabilized and you need to pin down what "done" looks like. This skill only writes the plan document; actually writing and running test code lives in the `atmos-specs-test-run` skill. Cover happy path, edge cases, and failure recovery at the scenario level — not individual unit tests. Only touch `TEST.md`.

Implement and execute the real tests for an Atmos spec — turn the scenarios in `specs/<ZONE>/<ZONE>-NNN_.../TEST.md` into actual Rust `#[cfg(test)]` modules, `bun test` specs, and Playwright/E2E tests under `e2e/` where warranted, then run them and report. Also run TEST.md-listed agent-browser exploratory checks when the external Agent Browser CLI/skill and local app are available. Use whenever the user says "write the tests", "实现测试", "跑测试", "run the tests for APP-NNN", "make TEST.md actually executable", or asks to verify that an implemented spec still works. Respect the project's test stack (`just test` = `bun test` + `cargo test --workspace`; E2E = `just test-e2e*`; per-crate/app filters via `cargo test --package <c>` and `bun run --filter <pkg> test`). Writes code in `tests/`, `#[cfg(test)]` mods, `apps/**/*.test.ts[x]`, or `e2e/tests/specs/*.e2e.ts`; may append short status lines to `TEST.md` per scenario. Does not write production code — that's the `atmos-specs-impl` skill.

Review an implemented Atmos spec and write or update `specs/<ZONE>/<ZONE>-NNN_.../REVIEW.md` with actionable post-implementation findings. Use this whenever the user asks to review whether a spec implementation is complete, ready to ship, functionally correct, aligned with PRD/TECH/TEST, or architecturally maintainable. Choose the functional review reference, quality review reference, or both based on the user's wording; if the request is ambiguous or asks for release readiness, use both.

Drive the user's open Atmos Canvas (tldraw whiteboard) via the `atmos canvas` CLI. Use whenever the user asks to sketch, draw, diagram, lay out, arrange, label, move, resize, recolor, or delete anything on the canvas — including architecture/flow diagrams, sticky notes, frames, geo shapes, arrows, grids of cards, or viewport changes.

Deploy the Atmos web app (`apps/web`) to Cloudflare Pages for this repository. Use when the user asks to deploy `app.atmos.land`, publish the web app, or create and push a `deploy-web-app-*` deployment tag.

Expert code review of current git changes with a senior engineer lens. Detects SOLID violations, security risks, and proposes actionable improvements.

This skill should be used when the user asks to review code, review my changes, code review, review this project, check code quality, security review, find bugs, or requests a comprehensive, structured code review covering both frontend and backend.

Expert code reviewer for TypeScript + React 19 applications. Use when reviewing React code, identifying anti-patterns, evaluating state management, or assessing code maintainability. Triggers: code review requests, PR reviews, React architecture evaluation, identifying code smells, TypeScript type safety checks, useEffect abuse detection, state management review.

Run a structured brainstorm for an Atmos spec and write it into `specs/<ZONE>/<ZONE>-NNN_.../BRAINSTORM.md`. Use this whenever the user wants to explore a new feature idea, sketch a rough direction, weigh multiple approaches, or dump unstructured thoughts into the Atmos specs tree — anything that belongs in the BRAINSTORM stage, before a PRD is written. Trigger also when the user says "brainstorm", "头脑风暴", "探索方向", "几种做法", or starts a new `APP-NNN` / `Landing-NNN` / `Docs-NNN` directory. Only touch `BRAINSTORM.md`; leave PRD/TECH/TEST alone.

Write or update the PRD (Product Requirements) for an Atmos spec at `specs/<ZONE>/<ZONE>-NNN_.../PRD.md`. Use whenever the user wants to lock in WHAT a feature is and WHY it matters — user stories, Must Have / Nice to Have, success metrics, explicit out-of-scope. Trigger when the user says "write a PRD", "产品文档", "需求文档", "定义范围", "user stories", mentions Must Have/Nice to Have, or asks to promote brainstorm output into a PRD. Focus strictly on user value and scope; leave HOW to the tech spec. Only touch `PRD.md`.

Write or update the technical design document for an Atmos spec at `specs/<ZONE>/<ZONE>-NNN_.../TECH.md`. Use whenever the user wants to turn a PRD into a HOW — architecture, data model, API/WebSocket messages, rollout plan, risks. Trigger on "tech spec", "技术方案", "架构设计", "data model", "WebSocket message", "crate layout", or when the user asks how to build a feature the PRD has already pinned down. Respect Atmos's layered architecture (infra → core-engine → core-service → api → apps) and WebSocket-first transport. Only touch `TECH.md`.

Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping

This skill should be used when the user asks to "generate project wiki", "create project documentation", "document the codebase", "generate a wiki for this project", "create docs from code", or wants to produce a comprehensive, navigable documentation set from source code stored locally as Markdown files in `.atmos/wiki/`.

This skill should be used when the user wants to add a specified topic to the Project Wiki. It generates a focused wiki article on a user-provided theme (e.g., "explore how X feature works", "research why X technology was chosen"), placing it in a dedicated Specify Wiki section separate from Getting Started and Deep Dive.

This skill should be used when the user wants to incrementally update an existing Project Wiki. It detects code changes since the wiki was generated, identifies affected wiki pages, and only regenerates those pages while preserving unchanged content.