fork_skill_designlisted

# fork_skill_design — describe fork capabilities Use a fork-local skill when shells need durable knowledge specific to this repository, stack, host, VM, deployment surface, database, or core fork process. Keep global skills limited to Subfloor itself, supplied tools and testing environments, and core Subfloor processes. ## Discover the real capability Read the repo map, tracked configuration, declared dev-kit hooks, and current readiness evidence before drafting. Identify: - the capability and the shells that need it; - its tracked declaration or owning source; - the seat, host, VM, service, or database it reaches; - readiness states and evidence locations; - authority, recovery, and data-tenancy boundaries; and - one observable success receipt. Pass = every operational claim names evidence available in this fork. Do not infer package managers, test policy, credentials, hosts, or deployment steps. ## Apply the purpose test Keep a line only when it explains this fork, a supplied tool or testing environment, or a core fork process. Use an imperative only when variation would break shared state, authority, compatibility, or recovery. Remove generic planning, coding, API, test, database, deployment, VM, and troubleshooting method. ## Draft and persist Write a Planner-owned draft with a lowercase underscore name and `common: false`: ```yaml --- name: repo_capability description: State the capability and when it fires. category: substrate common: false --- ``` Describe l