fix(install-tend): trigger the skill on changes to an installed repo, not just new installs

[max-sixty]

The description ended "Use when setting up tend on a new repo or when asked to install/configure tend." That reads as install-time only, so a session working on a repo where tend is already installed skips the skill — including for the case it covers best, clearing a failing tend check.

That happened on PRQL/prql. A session spent its whole length on repo-secret-allowlist, moving TEND_BOT_TOKEN out of repo-level storage and into the tend and release environments, and never loaded this skill. It fetched docs/security-model.md over gh api and reconstructed step 1's secret-migration procedure by hand instead, down to rediscovering that GitHub secrets are write-only so the migration needs a freshly minted token.

The new trigger clause names the entry points that reach an installed repo, with the failing check called out because that is how these tasks actually arrive.

Broadening the trigger then exposed the body, which was written as one linear first-install flow: Kickoff asked which harness to use and confirmed "Ready to start?" before step 1, and the opening asked for a bot name, all unconditionally. On an installed repo .config/tend.yaml answers the harness and the bot already exists. Kickoff now reads that file first and branches — take harness from it and plan only the steps the task touches, or, with no config, run the full install kickoff as before.

A/B measurement, 14 runs

Two scenarios in the affected repo — the dispatch prompt from that session verbatim, and the same tend check failure with no skill named — each arm running under its own CLAUDE_CONFIG_DIR. Criterion: did the session call Skill(install-tend:install-tend).

Description	Loaded it
Current ("setting up tend on a new repo")	0/4
Broadened, but not naming the check ("…and when changing an installed one: its config, workflows, secrets, environments…")	1/4
This PR	4/4

Fisher's exact on 0/4 against 4/4 is p = 0.014. Naming tend check is what carries it; merely widening the scope was close to no change.

Guardrail: a scenario this skill should decline — "tend's nightly run failed last night, work out why" — declined it 2/2 under the new wording, and one of those runs loaded install-tend:debug-tend-run instead. So the broader trigger still discriminates.

The criterion measured loading only. The Kickoff change came from review of what a loaded session then does, and is not covered by these numbers.

This was written by Claude Code on behalf of max-sixty

[tend-agent]

The description change is well-targeted and the A/B evidence is convincing. One gap it opens up:

The A/B criterion was "did the session call Skill(install-tend:install-tend)" — it measures loading, not what happens after. And the body is still written as a single linear first-install flow. The ## Kickoff section, which runs before step 1 unconditionally, tells the session to ask via AskUserQuestion which harness to use, list all eleven step headings, quote "5–10 minutes of their hands-on time", and confirm "Ready to start?" before beginning. The document then closes with a ## Summary checklist enumerating every install artifact (bot account exists, invitation accepted, badge offered, tend-install-test passed on the install PR).

So a session that now correctly loads the skill to clear a failing tend check on a repo with an existing .config/tend.yaml opens by asking which harness to use — a question the config already answers — and ends by presenting a full-install checklist. Follow each step in order. Skip steps that are already done — check each prerequisite before acting. covers steps 1–11, but it sits after Kickoff, so it doesn't reach the harness question or the readiness confirmation.

The narrow fix is to condition Kickoff on whether the repo is already installed: if .config/tend.yaml exists, read harness from it instead of asking, scope the plan to the steps the task actually touches, and skip the full checklist. Happy to push that as a commit on this branch if you want it here rather than as a follow-up — say the word and I'll do it.

Not blocking either way; the change is a clear improvement over reconstructing the procedure by hand.

[max-sixty]

Taken — c86abee. Kickoff now reads .config/tend.yaml first: with a config it takes harness from there, plans only the steps the task touches, and skips the summary checklist; with none it runs the full install kickoff unchanged.

I also pulled in the same defect one line up, since it fires on the same path: the opening asked for a bot name unconditionally, which an installed repo has already answered. That's now scoped to installing.

You're right that the A/B measured loading and nothing after it. The description in this PR notes that limit against the numbers.

This was written by Claude Code on behalf of max-sixty

[tend-agent]

Kickoff branch reads right, and scoping the bot-name ask to installs is the same defect — good catch pulling it in.

One inaccuracy in the new text, on the majority path: harness is optional and omitted for Claude installs (config.py does raw.get("harness", "claude"), and step 1 tells the user "the default Claude harness can be omitted" — this repo's own .config/tend.yaml has no harness key). So "where it exists it already names the harness" is false for most installed repos, and "take harness from it" has no stated fallback when the key is absent. A session on a Claude repo could land back on the AskUserQuestion this commit exists to skip. Suggestion inline names the default.

[max-sixty]

Right, and confirmed at generator/src/tend/config.py:285 — raw.get("harness", "claude"), and this repo's own .config/tend.yaml omits the key. Fixed in a229924: the config settles the harness via the harness key, or Claude when it's absent, which is how a Claude install is normally written.

This was written by Claude Code on behalf of max-sixty