babs

Generate a production Dockerfile or align an existing one to the standard. Use whenever creating or substantially reworking a Dockerfile — when the user says "write a Dockerfile", "containerize/dockerize this", or asks to align an existing Dockerfile to the standard. Never write a Dockerfile from habit; invoke this skill instead.

Initialize a production-shaped FastAPI + PostgreSQL + React project (single OCI image — the SPA is built and served by the backend), or align an existing one to the standard. Use when starting a full-stack app, when the user says "new app with a database", "FastAPI + React", "app with a UI and Postgres", or asks to align an existing full-stack project. For an API with no UI and no database, use python-init instead.

Initialize a new Go HTTP service or align an existing one to the standard. Use when starting any new Go service or project — when the user says "new Go service", "bootstrap/init a Go app", or asks to align an existing Go service to the standard. Never scaffold a Go service from habit; invoke this skill instead.

Use when the user says "implement loop", "run the loop", "autonomously", "AFK", "without supervision", "take it from here", "do the whole thing", "build it all", "I'll check back later", or hands a handoff doc, plan, ticket, or spec and asks you to build it end-to-end on your own. Drives the multi-phase implementation through a disciplined autonomous dev-test-review-commit loop per phase, with a human checkpoint at merge. Mode not stated → ask one question, supervised (ship-feature) or autonomous (this skill); never default to either loop.

Iterate review + fix rounds on changed code until the tree is clean. Use before committing when changes are substantial or risky and a single pass isn't enough — when the user says "iterative review", "review until clean", "loop review and fix", or wants findings fixed and re-reviewed automatically. One of the accepted pre-commit reviews alongside /my-review and /swarm-review (prefer these when installed, otherwise an equivalent review skill), ahead of /smart-commit or an equivalent commit flow.

Render Markdown to HTML and load it into the system clipboard so it pastes as rich-formatted text in apps that don't accept Markdown (Teams, Slack, Outlook, Confluence WYSIWYG, Gmail, …). Use when the user asks to "copy as HTML", "paste this in Teams/Slack/Outlook", "convert markdown for clipboard", or hands over Markdown destined for a non-Markdown UI.

Thorough review of all project changes. Use BEFORE committing feature work — when an implementation is complete and changes are about to be committed, or when the user says "review this", "review my changes", "check the diff". Feature work must pass a review before committing — prefer this, /iterative-review, or /swarm-review when installed, otherwise an equivalent review skill; then commit via /smart-commit when installed, or an equivalent flow.

Use when the user asks to "paste to privatebin", "share via privatebin", "create a privatebin paste", or wants a quick self-destructing paste with a revocation handle. Uploads text or a file to a PrivateBin instance and returns one JSON object with the shareable view URL and the delete URL.

Initialize a new Python FastAPI service — no database, no UI — or align an existing one to the standard. Use when starting a plain Python service or API, when the user says "new Python project", "bootstrap FastAPI", "init a Python service", or asks to align an existing Python project to the standard. If the app needs PostgreSQL or a React UI, use fullstack-init instead. Never scaffold a Python service from habit; invoke this skill instead.

Use when the user says "implement the spec", "build feature NNN", "ship it", or asks to implement work that has a file in specs/ and has said they stay in the loop. Implements the approved spec phase by phase with the full quality loop (tests, review until clean, swarm-review for large features, smart-commit), human-paced. If the user asks for autonomous, unattended, or AFK execution, says "take it from here", "do the whole thing", "I'll check back later", or hands the work and leaves — use implement-loop instead, even when a specs/ file exists. Mode not stated → ask one question, supervised or autonomous; never default to either loop.

Interactive branch, conventional commit, push, and MR/PR creation with user validation. Use for EVERY git commit in interactive sessions — whenever you are about to run `git commit`, the user says "commit", "commit this", "commit and push", "save this work", or a task ends with changes worth committing. Never run `git commit` directly; invoke this skill instead. In headless/non-interactive runs, commit only under an explicit standing authorization.

Turn a feature request into a written spec at specs/NNN-slug.md — problem, scope, out-of-scope, acceptance criteria, and phases with a measurable definition-of-done — before any code is written. Use when the user proposes a feature, says "I want the app to do X", "add a feature", "spec this out", "write a spec", or hands a vague idea to implement. Never start coding a feature from a chat message alone; spec it first, get it validated, then implement with one of the two loops — ship-feature (the user stays and approves each fix scope) or implement-loop (runs every phase alone, the user reviews at the merge). Offer both; never pick one for the user.

Use when the user asks for a "swarm review", "multi-angle review", "parallel review", "review from all perspectives", or `/swarm-review` — or when a large or cross-cutting change warrants independent review from several angles at once before commit. Dispatches one focused agent per angle (security, resiliency, code quality, functional, documentation, global coherence, tests/coverage) and consolidates findings.