Add Feature

Always use the skill load-plain-reference to retrieve the ***plain syntax rules — but only if you haven't done so yet.

This skill is the continuous-loop counterpart of the full QA workflow in forge-plain. Where that workflow bootstraps an entire project from scratch, add-feature adds a single feature to an existing set of .plain specs.

Core principle: one question → one answer → write specs

This skill runs as a tight, granular loop. Each iteration is a single question to the user, followed by an immediate write to a .plain file. No multi-question batches, no upfront interview, no "I'll gather a few things and then author." The cycle is:

Ask one focused question.
User answers.
Immediately write the resulting spec snippet to disk — even if you suspect it's incomplete or partly wrong.
Ask the next question, which often refines, extends, or corrects what you just wrote.

Writing eagerly is the point. A spec that's mostly right and gets corrected two questions later is better than a spec that waits for "enough" context before being written. The user can read what's on disk after every step and see exactly where things stand. Wrong-on-first-attempt specs are expected and welcome — you'll fix them in place on the next iteration. The questions themselves should be shaped to produce immediately writable content: a single attribute, a single behavior, a single edge case, a single constraint — not open-ended design questions that can't be turned into a snippet.

One question at a time — but dig as deep as the topic needs. "One question per iteration" is a rule about the AskUserQuestion call, not about the topic. If the user's answer is vague, ambiguous, or leaves real choices open, your next question should drill into that same topic — same loop, just another iteration. Keep drilling until the topic is concrete enough to produce a writable snippet. Only then move on to the next topic. Stopping too early and writing on top of a vague answer is worse than asking one more focused follow-up on the same thing.