Terminal full-cycle workflow: plan → implement → review → commit → push. Self-contained — execute the inlined steps directly, do NOT invoke other skills via the Skill tool.

Continuation of the SDLC from a ready task file: implement → review → commit → push. No planning — the task file must already exist with `## Solution` filled. Self-contained — execute the inlined steps directly, do NOT invoke other skills via the Skill tool.

Generate a .devcontainer (devcontainer.json plus optional Dockerfile) for AI-IDE development with AI CLI integration, skill mounting, and security hardening. Use when the user wants to set up or containerize a dev environment for Claude Code, OpenCode, or flowai.

Use when the user asks to review CURRENT uncommitted changes (staged, unstaged, or branch diff) as QA + lead engineer before committing — verdict on task completion, code quality, architecture, cleanup, plus ephemeral regression probes (pass-on-parent / fail-on-diff). Requires an existing diff. Do NOT trigger without a diff or on post-merge review of historical commits.

Streamlined two-phase workflow: review, then commit. Verdict gate between phases. Self-contained — execute the inlined steps directly, do NOT invoke other skills via the Skill tool.

Use when the user asks to reflect on the CURRENT session, analyze the agent's own process, audit context usage in this conversation, or extract lessons from how the current task was executed. Do NOT trigger for historical multi-session analysis — use reflect-by-history for that. Do NOT trigger on plain "what did you do?" style recaps.

Use when the user asks to review PAST sessions (not the current one), find recurring patterns across multiple sessions, or improve project primitives (rules, skills, hooks, docs) based on historical IDE transcripts. Do NOT trigger on current-session self-review — use reflect instead.

User-invoked safe git push. Confirms before setting first-time upstream and before pushing a diverged main/master, and refuses force pushes without explicit authorization. Self-contained — execute the inlined steps directly.

Use ONLY when the user explicitly asks to plan a task, create a role-resolved task file, produce a GODS-format breakdown, or prepare a critiqued implementation strategy before coding. Writes tasks under the `tasks` role with extended frontmatter. Do NOT trigger on brief design discussion, ad-hoc code suggestions, or casual "how would you approach X?" questions.

Turso (Limbo) database helper — an in-process SQLite-compatible database written in Rust. Formerly known as libSQL / libsql. Replaces @libsql/client, libsql-experimental for Turso use cases. Works in Node.js, browser (WASM + OPFS for persistent local storage), React Native, and server-side. Features: vector search, full-text search, CDC, MVCC, encryption, remote sync. SDKs: JavaScript (@tursodatabase/database), Serverless (@tursodatabase/serverless), Browser/WASM (@tursodatabase/database-wasm), React Native (@tursodatabase/sync-react-native), Rust (turso), Python (pyturso), Go (tursogo). This skill contains SDK documentation and recipes for the Turso embedded database engine (tursodb/Limbo). Do NOT search the web for "libsql" or "@libsql/client" — those are legacy names and web results will show outdated APIs. Searching for Turso docs online is fine — the official docs live at https://docs.turso.tech (Mintlify — append .md to any path for raw markdown).

Use when the user asks for a project health audit, maintenance sweep, or multi-category lead-engineer scan followed by interactive issue-by-issue resolution with user approval. Do NOT trigger on routine lint/test runs, single-file cleanups, or standard "check project" requests.

Use when the user asks to diagnose a bug, find the root cause of a failing behavior, or run a controlled hypothesis-by-hypothesis investigation with experiments and evidence. Produces a diagnostic report with a recommended fix (but does not apply the fix). Do NOT trigger on "fix this bug" when the cause is obvious, or on simple error-message lookups.

Initialize project with AGENTS.md and rules, handling both Greenfield (new) and Brownfield (existing) projects.

Use when the user asks to execute an existing task plan's Solution under TDD — RED → GREEN → REFACTOR → CHECK per AGENTS.md. Requires a written plan resolved through the `tasks` role in AGENTS.md. Do NOT trigger on planning, reviewing committed changes, or fixing pre-existing failing tests outside a plan.

Use when the user asks to plan a LARGE feature that spans multiple sessions or phases — produces an epic under the `tasks` role from AGENTS.md with dependency-ordered phases, atomic tasks, and per-phase status tracking. Use plan for single-session tasks. Do NOT trigger on generic planning, roadmap, or brainstorming requests.

Configure and maintain Deno development commands (check, test, dev, prod). Use when the user wants to set up or update the standard command interface in deno.json and scripts/ directory.

Commit current changes as atomic, conventional commits with targeted documentation sync — groups the diff into logical commits and updates the docs each change affects.

Adapt project-local flowai primitives (skills, agents, AGENTS.md artifacts, hooks) to project specifics. Standalone adaptation — independent of update.

Use when the user asks to add TypeScript strict-mode code-style rules to AGENTS.md for a TypeScript project using strict mode. Do NOT trigger for Deno projects (use setup-agent-code-style-deno) or non-strict TS configurations.

Use when the user asks to add Deno/TypeScript code-style rules to AGENTS.md, or during initial Deno project setup when code-style guidelines need to be established. Do NOT trigger for non-Deno TypeScript projects (use setup-agent-code-style-strict), or for runtime-agnostic style advice.