soffner

Use ONLY when the user explicitly invokes `/brainstorming`. Never auto-trigger from keywords, and never enter it because a request looks like a feature. Turns an idea into a design by reading the repo first, carrying what is left over as explicit assumptions, and spending the user's attention in batches instead of one question per message. A rejected assumption rewinds the work to the last accepted checkpoint.

Use when the user asks for a video of something happening in a browser (record this, film the flow, mp4 of the demo), or when another skill needs its browser steps filmed. Records one real Chrome tab with aditor over the DevTools protocol, from a duplicate of the Claude profile that keeps the logins. Never opens a browser or starts a recording because a change "would look good on video".

Use ONLY when the user explicitly invokes `/browser-test`. Never auto-trigger from keywords, and never start a browser or a dev server because a change "should be checked visually". Validates an already-open pull request by exercising what it delivered in Chrome (Claude in Chrome MCP) against a dev server running from the PR's own worktree, with a permission gate on anything that changes the database beyond what a user of the feature would do.

Use when the user asks for a demo video of a pull request (record a demo, film the PR, put a video on the PR). Plans a shot list from what the PR delivers, reuses or starts the dev server of the PR's worktree, writes each shot as an executable Claude in Chrome choreography and rehearses it off camera so the take is a clean playback that needs almost no editing, films it in the recording Chrome with aditor, and writes a "### Demo" section at the top of the PR body with the video and a short pt-BR text explaining what it shows. Never opens a browser, a server or a PR edit on its own initiative.

Use ONLY when the user explicitly invokes `/dono`. Never auto-trigger from keywords. Takes ownership of a pull request for this session - resolves the PR, makes sure a worktree with the PR branch exists (creating one through the project's worktree flow when it does not), syncs with the remote, loads the PR context and, when the prompt carries a task, executes it inside that worktree. With no task, it stops after setup and the briefing.

Use ONLY when the user explicitly invokes `/handoff`. Never auto-trigger from keywords. Launches a new background agent (`claude --bg`) with a written brief, waits for that agent's understanding ACK, shows the ACK to the user and releases the work with GO. Scope ends at the GO, because following the work from there on belongs to the user, not to this session.

Created side of the session-to-session handshake. Triggered by the initial prompt of an agent launched with `claude --bg` by the `/handoff` skill, in the form `/handoff-accept <brief path>`. Reads the brief, creates the worktree, validates the premises against the code, sends HANDOFF-ACK with its understanding back to the creator and stops. It only works after receiving HANDOFF-GO.

Use ONLY when the user explicitly invokes `/itask`. Never auto-trigger from keywords or from a prompt that merely looks like the start of a task. Sanity-checks the opening prompt of a task by filling in worktree, base branch, new branch and next skill from the project's own conventions, then shows a compact table plus the goal and stops until the user confirms. It is pre-processing of the prompt, not an execution plan.

Use when the user pastes a message, note, Slack post, email or PR comment they wrote and asks to improve, tidy, review or "give it a polish" ("dá uma melhoradinha", "revisa esse texto", "arruma esse texto", "melhora isso"), or invokes `/polish-text`. Also use before handing the user any prose they will send to another human. Not for writing text from scratch or for translating.

Use when review feedback arrives and has to be acted on - a human reviewer on a PR, an inline comment thread, the findings of `/soffner:self-review`, or a suggestion pasted into chat - or when the user invokes `/receiving-code-review`. Triages every item by whether changing the code buys anything real, implements the ones that do, declines the ones that do not with technical reasoning, and never performs agreement.

Competitive self-review of your own changes - dynamic reviewers (one per rules file) plus a Panel plus a Judge, output always in the same shape (single findings table, scoreboard, and a gate to publish the review on the PR). Aimed at helping the author improve their own code before human review

Use when the user asks to update the current branch with its base, bring the base in, or resolve conflicts against it (`atualiza a branch`, `traz a develop pra ca`, `merge da base`, `resolve os conflitos com a base`), or invokes `/update-branch`. Merges the base INTO the current branch and resolves conflicts by reasoning about intent, never by rebasing, never by merging the branch into the base, and never with a push. Never starts a merge on its own initiative.