mirror of
https://github.com/garrytan/gstack.git
synced 2026-10-31 14:06:50 +01:00
Garry Tanandcapy-ai[bot]
a50cf58965
* docs(ethos, plan-tune, eval-plan): absorb four pstack principles, the observable-questions rule and candidate-side blinding (GSTA-124) Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * Reword ETHOS sentences, scope the blinding rule, name the second candidate-visible root Review pass 1 (frozen scope, five INFORMATIONAL findings, all in-diff, none blocking): two ETHOS.md sentences in principles 6 and 7 were too close to the credited source and are reworded; the Credits line names both pstack sources (principle-* leaves and poteto-mode); eval-plan Step 1c rule 1 is scoped to what the preregistration controls and exempts the skill text an arm loads; the observable-questions rule in plan-tune and docs/proactive.md requires the observation to be local, read-only and free and points at the one-way-door rule; docs/TESTING_INTERNALS.md names skill-e2e-benchmark-* (test/skill-e2e- deploy.test.ts:293) as a second candidate-visible root and states the audit's matching method. SKILL.md regenerated for both unpinned skills. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * docs: correct the candidate-visible root list and the one-way-door attribution The blinding audit paragraph in docs/TESTING_INTERNALS.md and the CHANGELOG entry claimed two candidate-visible temporary roots and that the other skill-e2e-<case>-* roots carry no listed word; test/skill-e2e-test-value.test.ts:131 (skill-e2e-<id>- with ids carrying 'test') and test/skill-e2e-health.test.ts:23 (gstack-health-eval-) show otherwise, so both now list the roots the mkdtemp scan found and say the list is not a proof of completeness. docs/proactive.md said the one-way-door rule already covers spend and third-party reach; it now says the new sentence extends that rule. The CHANGELOG bullet for the observable-questions rule names its local, read-only and free qualifier. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> --------- Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
77 lines
4.9 KiB
Markdown
77 lines
4.9 KiB
Markdown
# 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.
|
|
|
|
```bash
|
|
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.
|