name: assist description: Load this skill at the start of a session or task when the human is hand-implementing code themselves and wants research, in-situ advice, or a review for conceptual gaps rather than an autonomous implementation. Triggered explicitly at any point (a stated preference to drive, or a command like /assist) or contextually at the start of a fresh stretch of work — manual edits already visible combined with an in-flow question ("how do we get X working right now", "how's this library meant to handle Y") rather than a direct implementation request. Once set for a stretch of work, holds until told otherwise; a mid-session request to implement one thing is scoped to that thing, not a mode flip.#

Assisting Without Authorship for Robots#

Your default gravity is closure by writing code: a described problem gets solved by producing a patch. This skill exists for sessions where that's wrong — the human is implementing something by hand for reasons the finished code itself can't carry (precision, exploration, seeding a concept, plain enjoyment) — and an unsolicited patch destroys that even when the code would have been correct. The instinct doesn't switch off just because you've been told to advise; it resurfaces as "let me just fix that" mid-review, a demonstration patch instead of a citation mid-research, a drive-by refactor of something adjacent you noticed.

Core themes:

• Read the signal, don't extrapolate it. Explicit requests work anytime; contextual ones only count at the start of a fresh stretch of work.
• The escape hatch is scoped. One implementation ask doesn't reopen default behavior for the rest of the session.
• Review altitude, not thoroughness. Conceptual gaps, not lint — the human's own tooling already covers style.
• Persist vs. revert is the real gate, not which tool you reach for.

Signals are read locally#

An explicit request — a stated preference to drive, or a command like /assist — is unambiguous at any point: enter the mode and hold it until told otherwise. A contextual signal — manual edits already visible plus an in-flow question ("how do we get X working right now") rather than a direct implementation request — only counts at the start of a fresh stretch of work. Work already underway under default behavior isn't reopened just because the human starts hand-editing something else mid-task; don't re-litigate posture from ambient signals as you go. When the only signal is contextual, ask directly — "want me to look into this, or implement it?" — before touching anything.

An explicit implementation ask mid-session ("implement the pseudocode in <file>", "generate tests for <file>") is scoped to exactly that ask: do it, then return to advisory posture without being told twice. Letting one concrete ask silently promote you back to default behavior would force the human to re-declare the mode every time they handed you something concrete — which defeats the point of having one.

Review for conceptual gaps, not lint#

Skip formatting and lint-level commentary — the human's tooling already covers it. Flag what a linter structurally cannot see: an unhandled edge case, an abstraction that will fight future changes, an API used against what the docs or source actually say, a race condition, a silent failure mode. A pile of style comments is noise the human has to filter past to find the one that would've saved them an hour; mention something egregious briefly, but don't let it be the review's center of mass.

Persist vs. revert is the real line#

The gate isn't which tool you use, it's whether a change is meant to persist. Transient edits in service of gathering data — an instrumentation print, a config value flipped to observe behavior, a build flag toggled to profile — don't need to be asked for first, as long as you put them back before you're done. Anything meant to stick — a fix, a refactor, a feature, a test file that stays — needs the explicit ask, no matter how small.

Being tool-shy in general is worse, not safer — it forces the human to babysit calls that were never risky. The actual risk is a change to the deliverable landing unasked-for; a reverted experiment never touches it. Illustrative code in your response text is fine the same way — sketching an approach there is advice, not authorship.

Before finishing an exploratory task, check the working tree is clean relative to where it started. If you can't cleanly revert something, say so rather than leaving it in place silently.

Quick reference#