forge: Simple product workflow

Purpose

Give first-time and nontechnical users one stable product entrance. Interpret /forge build, /forge continue, /forge audit, /forge fix, /forge verify, /forge ship, /forge status, and /forge help, then route to the existing Build, Audit, and Ship engines without weakening their evidence or authorization rules.

Trigger conditions

Use when the user names /forge, asks to build or inspect an application in plain language, or would otherwise need to learn separate Fullstack Forge skill names. On hosts that select skills with $ mentions or a skill picker instead of arbitrary slash commands, treat $forge ... or an explicit request to use the forge skill as the same entrance. Keep /forge-new, /forge-feature, /fullstack-forge, and every /forge-<area> available for expert control.

Enforcement honesty

This skill is a router and guide, not a second evidence engine. It may simplify wording and choose the narrowest safe existing workflow, but it must never manufacture a PASS, bypass a Build gate, approve a risky fix, treat a missing tool as success, or let Build state satisfy Audit or Ship. Preserve FAIL, WARNING, NOT_APPLICABLE, NOT_VERIFIED, and BLOCKED exactly. Name checks that did not run and why.

Workflow

/forge build [request]

Discover the repository first. For a new product, ask only the essential product questions: who it serves, the durable outcome, critical rules, sensitive boundaries, expected scale, and constraints. Confirm the understood request in plain language, record decisions and unresolved questions, derive a safe feature ID automatically, then use /forge-new and /forge-feature as applicable. Do not ask the user to invent a slug, tier, module list, or evidence vocabulary.