gstack/docs/proactive.md

Proactive skill suggestions

gstack notices what stage you are in (a new idea, a diff to review, "does this work?", time to land it) and can invoke the matching skill without you typing its slash command. The proactive config key says how far that goes.

Value	What auto-invokes	Who it is for
core (default)	/office-hours, /review, /qa and /ship only. Every other skill waits for you to type it, unless a skill you ran hands off to it (/office-hours offering the next review).	Most people, and anyone running gstack beside another skill pack: the four core skills are the ones users praise, and the others no longer compete with another pack's niche skills.
all	Any skill whose purpose matches your request.	You use gstack on its own and want the whole sprint suggested.
off	Nothing. gstack never suggests or auto-invokes a skill, not even by asking "want me to run /X?".	You type every command yourself.

true and false still work as the older spellings of all and off, so a config written before the core default keeps its behavior; gstack-skill-start reports them to the skill as all and off. A hand edit may be quoted, upper-case or commented (proactive: "OFF" # mine), and the YAML yes/no family (yes, on, 1; no, none, 0, disabled, never) reads as all or off, in gstack-config set as well, so a typed opt-out never fails open.

gstack-config get proactive          # core, all, off (or a legacy true/false)
gstack-config set proactive all      # suggest every matching skill
gstack-config set proactive off      # suggest nothing
gstack-config set proactive core     # back to the default

A skill you name is always invoked, whatever the setting, and so is a skill that a running skill invokes itself (/ship dispatching /document-release). The setting governs unasked suggestions, and an in-skill offer to run another skill is one: under off, /office-hours recommends the next review in one line instead of offering to launch it, and the one-time first-run tips stay quiet. The change takes effect on the next skill run; no ./setup is needed, because every skill reads PROACTIVE from gstack-skill-start at the start of each run and the router (/gstack) applies it to its routing rules. A value gstack does not know (a hand-edited proactive: maybe) reads as core.

Two surfaces follow the setting only in part. The first is the ## Skill routing section gstack offers to append to your project's CLAUDE.md. Under off the offer is not made, because those rules are the auto-invocation you turned off (a section already in CLAUDE.md stays; delete it yourself). Under core the offered section still lists every routing rule and tells the host to invoke any matching skill. If you accepted it before the core default, trim that section to the four core rules (or delete it and let gstack offer it again); making the offered section follow core is tracked in #3446.

The second is the full skill descriptions, which a --catalog-mode=full build and the non-Claude hosts keep. Non-core skills still say "Proactively suggest when ..." there, and that text does not change with the setting, so a host that picks skills from those descriptions can still reach them under core. The default Claude build uses one-line descriptions without that sentence. #3446 tracks that too.

gstack asks once, after the telemetry question, which of the three you want; if you stored off before that, it takes the answer as given and does not ask. "Say stop suggesting" in a session runs gstack-config set proactive off for you.

If collisions with other skill packs keep coming up under core, the fallback Garry approved on 2026-10-25 is off by default.

Questions a skill asks on its own

The setting above governs which skills gstack offers unasked. A second rule governs what a running skill may ask you unasked: a question whose answer the skill could observe is not yours to answer. Whether a change is faster, whether two renders differ, whether an endpoint accepts a payload, whether a test still fails: each of those is settled by running the thing (time it, render both, call it, run the test) and reporting the result, not by a prompt. That holds for observations that are local, read-only and free; a call that changes state, reaches a live or third-party system or spends money is still yours to approve. That extends the one-way-door rule in /plan-tune, which covers destructive, architectural and security questions, to spend and third-party reach. The only questions that come to you are product and preference calls (what the product should do, what you want, what you are willing to spend or risk), and they arrive with the observation already in hand so the choice is between measured options. /plan-tune applies the same rule when it audits the question log: an observable question is a defect in the asking skill, not a preference to tune.