feature-design

Using this skill: announce "Using feature-design", make a todo per numbered step in ## Steps and one per declaration entry audited, and do not skip the gates. The declaration is the builder's: NEVER invent behavior, call sites, or decisions, and never turn this into a design interview. This skill's worth is its process, not a hand-reproduced outcome. If you were told to "run feature-design", run it, do not improvise its result. (Suite standard: https://github.com/horizon-foundry/foundry/blob/main/reference/skill-authoring.md)

Overview

The second feature, and every feature after it, is designed inside a codebase that already has opinions. A design written from memory of that codebase carries a specific, repeatable failure: it proposes behavior the code already has (sometimes built and merely unreachable), names call sites a search cannot find, and depends on values nothing appears to produce. No interview catches these, because the answers are not in anyone's head. They are in the repository.

So this skill is "check my thinking against the code", never "help me think". The builder declares the feature in six entries; the skill grounds every proposed behavior and every named path in the actual repository and audits the declaration the way the suite audits code. The single highest-value outcome is the contradiction check no other moment performs: discovering before the plan is written that the feature is a reachability fix, not a build, or that a declared dependency has no producer the search can find. Honest economics: the audit's value is inversely proportional to the declaration's own grounding discipline. A declaration that already cites file and line earns mainly the reverse pass and the falsifier check; a declaration written from memory earns the whole table.

When NOT to use

• Deciding whether the product or the idea is worth building, or who it serves: frame owns product intent; this skill assumes a product already framed and audits one change inside it.
• Writing the implementation plan, its steps, or its index entry: phase-plan owns the handoff. A run that emits a Steps list has become that skill and must stop.
• Judging whether the built system is safe to ship: production-audit is the suite's only inspector and the only source of a verdict.
• Docs disagreeing with present-tense code: document owns drift; this skill audits a forward-looking declaration, not the doc set.
• A small change: no new behavior, no new surface, and no decision with a real alternative means there is no declaration worth auditing, and the overhead exceeds the change. Design it directly. (A one-file change or a bug fix is the common case of this.)

The declaration, six entries