name: scope-need description: Use when a user brings a new capability, feature request, or enhancement need for greater in vague terms. Interviews conversationally and produces a scoped-need document. Applies Gate 1 (greater-mission alignment), Gate 2 (narrowest scope with API stability), Gate 3 (specialist routing).

Scope a need

A need arrives fuzzy. A feature arrives sharp. This skill is the conversation that turns fuzzy into sharp, with three specific filters: greater-mission alignment, narrowest-scope discipline with API stability, and specialist-skill routing.

Your posture

You are interviewing, not pitching. greater is a Svelte 5 Fediverse UI component library — components for Fediverse apps, accessible by default, protocol-aware via pinned adapter contracts, distributed shadcn-style via CLI. Scope is bounded.

The scoping question is three-part:

1. Is this greater-mission work — component / primitive / headless / face / adapter / token / icon / CLI / registry / docs / playground, with accessibility + Mastodon-compat discipline — or is it scope growth outside that mission?
2. If it's in-mission, what is the narrowest scope that preserves component API stability, contract-sync, accessibility baseline, registry integrity, theming contract, release-flow discipline, and Mastodon-compat where feature sets overlap?
3. Does the change touch the component API, theming tokens, an adapter, accessibility semantics, the CLI / registry, release automation, or an advisor-dispatched brief? If yes, route to the appropriate specialist skill before enumeration.

The default for Gate 1 for new components, accessibility improvements, adapter additions (with contract sync), theming additions, docs / playground expansions, upstream dependency bumps, and bug fixes is "yes, evaluate at Gate 2." The default for net-new capability outside the Fediverse UI component library mission is "no."

Start with memory and the architecture

• Read README.md, AGENTS.md, CONTRIBUTING.md, and docs/ for canonical patterns.
• memory_recent — has this or adjacent work been scoped?
• query_knowledge — do Lesser / Lesser Host / FaceTheory already cover this concept?

If tools unavailable, surface and ask the user to re-auth.

The interview

Ask, one or two at a time:

1. Who is asking and why now? sim / host web / external Mastodon consumer / CVE / advisor-dispatched / Aron-direct?
2. What problem does it solve? Current pain, not speculative.
3. Which surface does it touch? Component primitive / headless / face / adapter / token / icon / CLI / registry / docs / playground / release automation.
4. Is this a new component? If yes, identify primitive vs headless vs face suite.
5. Is this an adapter change? If yes, identify the upstream Lesser / Lesser Host surface and whether a contract-sync is needed.
6. Is this an accessibility improvement? If yes, evaluate baseline shift.
7. Is this a token / theming change? If yes, evaluate stability impact.
8. Is this a CLI / registry / release-flow change? If yes, gate through release-components.
9. Does this break existing consumers? If yes, major-version discipline; coordination with sim / host / external consumers.
10. Does this affect Mastodon baseline? If yes, document the drop or evaluate whether the baseline can be preserved.
11. What does success look like? Observable, testable.
12. What is explicitly out of scope?

The three gating questions

Gate 1: Is this greater-mission work?

Seven verdicts:

1. Yes — new component / primitive / headless / face addition. Accepted with evolve-component-surface walk.
2. Yes — component API evolution (minor / patch). Accepted with evolve-component-surface walk.
3. Yes — adapter change (with contract sync). Accepted with sync-contracts walk.
4. Yes — accessibility improvement / tightening. Accepted with enforce-accessibility walk.
5. Yes — theming token addition / refinement. Accepted with evolve-component-surface walk.
6. Yes — CLI / registry / release automation improvement. Accepted with release-components walk.
7. Yes — docs / playground / CI / dependency maintenance. Accepted.
8. No — out-of-scope growth. General-purpose form validation not Fediverse-specific, routing / state-management concerns, backend logic, payments processing beyond wallet-UX in agent face, non-Fediverse icons at scale. Produces a redirect document.

Gate 2: What is the narrowest possible scope?

If Gate 1 passed:

Prefer:

• New optional props over breaking existing ones
• New component additions over modifying existing shape
• New headless behaviors over modifying existing
• Adapter additions that consume already-pinned contract versions
• Token additions over renaming existing
• Accessibility tightening (higher bar) over loosening
• Dependency bumps within current major versions
• CLI UX improvements that don't change the install contract

Avoid:

• Refactors "while we're in there"
• Breaking changes without major-version changeset + consumer coordination
• Adapter changes without pinned contract-sync
• Token renames (breaking theming)
• Accessibility regressions
• Registry format changes without version coordination
• Mastodon-baseline breaks

Gate 3: Specialist routing

Specialist skills run before enumeration when the change touches:

• Component API or theming tokens → evolve-component-surface
• Adapter + pinned contract sync → sync-contracts
• Accessibility (WCAG 2.1 AA) → enforce-accessibility
• CLI / registry / release automation → release-components
• Framework consumption (FaceTheory) → coordinate-framework-feedback
• Advisor-dispatched brief → review-advisor-brief

Specialist findings feed into enumeration.

Output: the scoped-need document

For Gate 1 verdict "in-mission":

# Scoped Need: <short name>

## Background

<one paragraph>

## Driver

<sim / host / lesser-UI / external consumer / CVE / advisor / Aron-direct>

## Problem

<what is broken, missing, or painful today>

## Surface affected

<primitive / headless / face / adapter / token / icon / CLI / registry / docs / playground / release-automation>

## Component(s) affected (if applicable)

<named — from primitives / headless / faces>

## Classification

<component-addition / component-api-evolution / adapter-change / accessibility / theming / cli-registry / release-automation / docs / dependency-maintenance>

## Narrowest-scope proposal

<the smallest change that addresses the need>

## What this need explicitly does not cover

<bounded scope; watch for scope-creep>

## Success criteria

<observable, testable>

## Specialist routing

- Component API / theming: <not touched / walk via evolve-component-surface>
- Adapter / contract sync: <not relevant / walk via sync-contracts>
- Accessibility: <baseline preserved / walk via enforce-accessibility>
- CLI / registry / release: <not touched / walk via release-components>
- Framework consumption: <idiomatic / signal via coordinate-framework-feedback>
- Advisor brief: <n/a / review via review-advisor-brief>

## Consumer impact

- sim: <no impact / update needed>
- host web: <no impact / update needed>
- lesser-UI: <no impact / update needed>
- External Mastodon-compat: <baseline preserved / explicit drop documented>

## Semver impact

- <major / minor / patch> — changeset impact

## Mastodon-compat posture

- <baseline preserved / intentional Lesser-first drop with documented fallback>

## AGPL posture

- <no change / confirmed AGPL-compatible>

## Open questions

<unresolved>

For Gate 1 verdict "out-of-scope":

# Redirect: <short name>

## Background

<what was asked>

## Why this doesn't belong in greater

<scope bounded to Fediverse UI component library; this is X>

## Appropriate owner

<sim / lesser / host / new repo / scoping with Aron>

## Path for the requesting user

<route to appropriate steward, defer, or new-repo scoping>

## Recommended next step

<specific handoff>

Persist before handoff

Append when scoping surfaces a recurring pattern — a redirect category, a component-evolution decision, a contract-sync pattern, an accessibility finding, a Mastodon-compat boundary. Routine completions aren't memory material. Five meaningful entries beat fifty log-shaped ones.

Handoff

• In-mission, component / theming — evolve-component-surface.
• In-mission, adapter / contract-sync — sync-contracts.
• In-mission, accessibility — enforce-accessibility.
• In-mission, CLI / registry / release — release-components.
• In-mission, framework-feedback — coordinate-framework-feedback.
• In-mission, none of the above — enumerate-changes.
• Advisor-dispatched — review-advisor-brief already ran; authorization included.
• Out-of-scope — redirect is the handoff.
• Resolved to "no change needed" — record and stop.
• User defers — record and stop.