umbel: Skill for Claude Code

Discover: Existing Code -> Feature Polyglots

Owns: feature polyglot creation from observed code, plus catalog components / personas / journey phases inferred from the code.

What this skill assumes

• The codebase exists and is readable — this is a one-time bootstrap that maps existing code into tend features.
• The user accepts that discovered checks default to validates_job: null (code carries no human-intent signal). After discovery, /tend position plants ICPs/Jobs and /tend brainstorm / /tend change anchors checks to them.
• This skill does NOT discover opportunities. Those come from human conversation (/tend position), not from code.
• After this skill, the next leverage move is /tend position (plant the spine), then /tend audit (claim coverage feature-by-feature).

Purpose

Reverse-engineer a feature map from an existing codebase. The input is the repo itself - routes, modules, tests, public exports - and the output is a set of feature polyglots whose slot claims describe what exists today, checks describe what tests already prove, and audit is empty until /tend audit validates them.

tend-discover is a one-time bootstrap for a codebase that has no docs/tend/ files yet. After bootstrap, new features come from /tend brainstorm; changes to existing features go through /tend change.

Output

• docs/tend/overview.html - garden polyglot with catalog (via tend_update_catalog)
• docs/tend/features/<id>.tend.html - one feature polyglot per discovered surface (via tend_create_feature then tend_update_feature)

Rules

• Ask the user for choices and confirmation. Do not proceed on assumptions when intent is ambiguous.
• Ask the user to confirm the component list before creating any feature polyglots.
• All writes go through MCP - never edit .tend.html files as text.
• Checks must be assertions (checkable outcomes), not tasks.
• Infer checks from existing tests where possible; mark inferred ones explicitly with (inferred from test) in the description.
• Every inferred check carries validates, the slot the test seems to prove. Default validates: what if it tests behavior; validates: where if it tests structure; ask the user when ambiguous.
• Mock-aware inference. If a test mocks the function or component the check is about (e.g., vi.fn() returns the value the check describes; the integration boundary is stubbed), the test is not real evidence - it proves the mock returns what you told it to. When inferring a check from such a test, mark the check description with (inferred from mocked test - needs real verification) and propose integration_level: integration (or e2e if a runtime is involved). Do not let the test's "passing" status bias you.
• Default integration_level: unit, but watch for signals. Tests that hit real DBs, real HTTP servers, real browsers, or real filesystems are evidence for integration or e2e checks. Tests that import only the unit under test and call its function directly (no boundaries) are evidence for unit checks.
• Set both dependencies (technical blockers) and enables (user journey edges) where discoverable from the code (import graph, route guards, redirect flows).
• All discovered features default to status: "planned" even though the code exists. Do not set status: "verified" - that requires audit.result === 'pass' with real evidence per check. Discover only claims the code exists; tend-audit confirms it works.
• After completion: tell the user to run /tend audit to verify discovered checks against real evidence; surface any inferred-from-mock or (needs real verification) checks as the priority targets.