Skip to content

feat(setup-steward): drive family pre-select from repo fit signals#242

Open
andreahlert wants to merge 1 commit into
apache:mainfrom
andreahlert:feat/setup-steward-evaluate
Open

feat(setup-steward): drive family pre-select from repo fit signals#242
andreahlert wants to merge 1 commit into
apache:mainfrom
andreahlert:feat/setup-steward-evaluate

Conversation

@andreahlert
Copy link
Copy Markdown
Collaborator

Why

setup-steward adopt Step 5 today picks default opt-in families (security, pr-management, issue) from prose the user typed in their adopt request. An operator that just says "adopt apache-steward" gets no pre-tick, and has to map repo health to families themselves. That is the single biggest piece of unhelpful friction in first-time adoption.

What

Adds Step 4b — Read fit signals (FRESH only) between the committed-lock write and the family prompt. Best-effort, time-boxed signal collection via gh against the canonical remote (upstream preferred over origin):

  • open issues, open PRs, security-labeled open count
  • oldest open PR age, 30-day merge ratio
  • plus filesystem markers: SECURITY.md, .asf.yaml

Rules that produce <signal-derived-families>:

  • security if SECURITY.md present or security-labeled count > 0
  • pr-management if open PRs >= 5 or oldest PR >= 30d or 30d merge ratio < 0.5
  • issue if open issues >= 10 or oldest issue >= 60d

Step 5's pre-select rule is amended to union prose-named families with <signal-derived-families>, and to surface in the prompt body why each tick is on (named or signal). The operator can untick anything that does not fit. The skill-families: flag still wins verbatim when passed.

Failure / skip behaviour

The whole step skips, and Step 5 falls back to today's prose-only default, when any of:

  • user passed skill-families:
  • gh missing, unauthenticated, or origin / upstream not a GitHub remote
  • any individual call errors or exceeds ~5 s (missing signal treated as zero, no retry)

Recommendation remains suggestion, never auto-decision.

Security

Includes the Pattern 4 injection-guard callout: counts and dates are the only fields consumed; free-text fields (titles, labels, logins) are discarded after extraction. No instructions are followed from gh content.

Scope

Single file change: .claude/skills/setup-steward/adopt.md. No new sub-action, no SKILL.md dispatch edit, no behaviour change for adopters that pass skill-families: or that have no GitHub remote.

How tested

prek run --files .claude/skills/setup-steward/adopt.md clean (markdownlint, typos, check-placeholders, skill-validate all pass).

Today Step 5's pre-selection of opt-in families (security,
pr-management, issue) is derived only from prose in the user's
adopt request. For an operator that just says 'adopt
apache-steward', no family is pre-ticked, and the operator
has to map repo health to families themselves.

Add Step 4b: a best-effort, time-boxed signal collection that
runs after the committed lock is written but before the
family prompt. It reads cheap fit signals via gh against the
canonical remote (open issues, open PRs, security-labeled
count, oldest PR age, 30d merge ratio) plus filesystem
markers (SECURITY.md, .asf.yaml), and produces
<signal-derived-families> using the existing family
descriptions as rules:

- security: SECURITY.md present OR security-labeled count > 0
- pr-management: open PRs >= 5, oldest PR >= 30d, or 30d
  merge ratio < 0.5
- issue: open issues >= 10 or oldest issue >= 60d

Step 5's pre-select rule is amended to union prose-named
families with <signal-derived-families>, and to surface in
the prompt body why each tick is on (named or signal). The
operator can untick anything that does not fit. The flag
skill-families: still wins when passed.

The step is strictly optional: it skips on missing gh,
unauthenticated gh, non-GitHub remote, or per-call timeout,
and treats each missing signal as zero. Recommendation
remains suggestion, never auto-decision.

Includes the Pattern 4 injection-guard callout for the
external content read via gh.
@andreahlert andreahlert requested a review from potiuk May 20, 2026 16:10
@andreahlert andreahlert self-assigned this May 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant