Feature Discovery

Lazy-loads this repository's feat docs from docs/feat/ against a user query, by matching YAML frontmatter before reading any feat doc in full.

When to Use

• The user asks "what is X?", "how does X work?", or what the toolkit can do
• The user names a part of the toolkit - a check, a spec, a command - and wants the context behind it
• Before implementing a feature, to find out what already exists

Sibling skills: /feat-status for the maturity each feat doc declares, /docs-rules-check for whether a document is well-formed, /code-rules for how to write the code.

Prefetched Feature Catalog

The frontmatter of all feat docs (loaded at skill start):

!awk '/^---$/{p=!p; print FILENAME": "$0; next} p{print FILENAME": "$0}' docs/feat/*.md 2>/dev/null

Fallback: if the block above appears as literal text (the runtime does not auto-execute dynamic context), run it yourself with the Bash tool before proceeding.

An empty catalog is an answer, not a failure. It means no feature has been written up in this repository yet. Say the corpus is empty, answer from the code and from AGENTS.md, and do not rerun the command or go hunting for the feat docs somewhere else.

Workflow

1. Match the user's query against the prefetched catalog using the fields below.
2. Load each matched feat doc and its base chain. For every hyphen-prefix ancestor of its filename, read the corresponding existing .md document in docs/feat/, broadest first, then read the matched document. For example, a match to spec-structure-outline loads spec and then spec-structure, if those files exist. Skip a missing intermediate name and continue with any more specific existing ancestor. The matched document and its base chain count as one match.
3. Follow cross-references in each feat doc's "References" section and load those too when relevant.

Query Matching

Compare query against frontmatter fields:

• name - exact or partial match (e.g. "budget-check", "spec-dialect")
• description - semantic match (e.g. "frontmatter" -> the frontmatter check, "too long" -> the length budget)
• components - the identifiers a feat doc lists for the parts of the toolkit it covers: a checker module, a command surface, a spec. The corpus spec, docs/__meta__/feat.md, fixes that vocabulary; match on the identifier itself rather than on its prefix.

Load multiple feat docs when:

• The query spans several features
• Features cross-reference each other (References section)
• The user is working where two of them meet - a check and the spec it enforces

When NOT to Use

Whether the code actually does what a feat doc says is no skill's job here: read the feat doc and the code and compare them by hand.

Simple file edits that do not need feature context need no discovery at all.