mngr

Address review comments on a pull request -- apply CLAUDE:/SCULPTOR:-prefixed instructions, and critically evaluate feedback from automated reviewers (Vet, Copilot, or any bot)

Prune code comments down to what helps future maintainers. Reviews comments on the current branch's diff and removes incidental history, defensive justification, and correctness arguments. Invoke with /crispy-comments.

End-to-end dev workflow for the minds app stack -- first-time bring-up, every-startup vendor/mngr sync, and the iteration loop against a running Docker agent. Use this when starting or restarting the dev Electron app, or after changing any minds component (mngr, the system interface, the default workspace template).

Create a new PRIVATE GitHub repo that is a full-history copy of imbue-ai/default-workspace-template's current main branch, clone it to <parent-dir>/<repo-name> (default $HOME/project), and push. Use when the user asks to "spin up a new default-workspace-template clone", "fork the default-workspace-template as a private repo", "make me a new private copy of default-workspace-template", or similar.

Use the root justfile as the canonical entry point for ANY minds task -- minds app (desktop client), pool hosts, minds environments (activate/deploy/destroy), minds deployments, and minds tests. Before running ad-hoc `uv run minds ...` / `mngr imbue_cloud ...` commands, check the justfile for a named recipe; if none exists for the task, ADD one. Use whenever the request involves the minds app, pool/leased hosts, a minds env/tier (dev/staging/production), or a minds deploy.

Cut a new production release of the minds app (version bump, FALLBACK_BRANCH, vendor/mngr sync, and minds-v<version> tags on both mngr and default-workspace-template, proven green on CI). The full procedure lives in apps/minds/docs/release.md in the mngr checkout; this skill defers to it. Use when the user asks to "release a new version of minds", "cut a minds release", "bump the minds version", "update the vendored mngr in default-workspace-template", or anything of that shape.

Match tutorial script blocks to e2e pytest functions and add missing tests

Identify places under the $1 path where the docs and code disagree

Identify inconsistencies under the $1 path

Identify outdated docstrings under the $1 path

Identify divergences from the style guide under the $1 path

Identify suspicious edge-case handling (over-broad catches, fallback else branches, defensive guards) under the $1 path

Identify low-quality or fragile tests (weak/tautological assertions, missing cases, mock misuse, flakiness, mis-placement) under the $1 path

Audit recent CI runs for anomalies (warnings, uncached docker builds, flaky/slow tests, regressions).

Write ratchet tests to prevent accumulation of code anti-patterns. Use when asked to create a "ratchet test" for tracking and preventing specific code patterns (e.g., TODO comments, inline imports, broad exception handling).

Interactively triage the user's local engineering backlog file into GitHub issues. Use when the user wants to process their raw thought notes / ticket backlog into proper GitHub issues.

Fix a GitHub issue given its number or URL. Replicates the bug, finds root cause, implements a fix, and opens a PR.

Convert triaged autoclaude GitHub issues into FIXMEs in the codebase. Use when you want to process issues that have been triaged by authorized users.

Create a prompt from a short task description in a JSON file

Create FIXME's in the codebase for each of the issues in the given input file.

Convert a file containing identified issues into GitHub issues. Use after running identify-* commands to create corresponding GitHub issues.

Fix a random FIXME in the codebase (in the given scope, use "." for the whole codebase)

Convert a file containing identified issues into a tracked file in current_tasks/. Use after running identify-* commands to create a local record of current issues.

Create 1-3 short asciinema demo recordings (5-20 seconds each) that demonstrate completed work. Use only when explicitly instructed to create demos.

Write high quality, user-facing documentation. Use any time you need to write, improve, or update a significant amount of user-facing documentation (e.g., files in a "docs/" folder or README file).

Write high quality specifications or design docs for a program. Use any time you are asked to write, improve, or update specs / design docs (e.g., files in a `specs/` folder).

Come up with good ideas about what to fix. Use when you have to fix something, but you're not sure what.