Vision Forge

Create a vision document that acts like the CEO for a chosen scope: short, explicit, and useful to external actors. This is not a PRD, roadmap, strategy memo, or task list. It is the standing intent layer that users, contributors, maintainers, partners, and operators can use to understand what the work is for and what does not fit.

Default assumption: VISION.md is not an agent instruction file. Agents may consult it for product intent only when project instructions tell them to. Operational agent rules belong in AGENTS.md, skills, or a separate loop/agent policy.

Scope first

Vision can vary in scope. Before drafting, name the boundary the vision governs and do not mix multiple layers into one mushy doc.

Common scopes:

• Organization / operating system — mission, values, governance, roles, budget, and long-lived operating constraints.
• Product / business line — who the product serves, the durable outcome, positioning, non-goals, and investment boundaries.
• Project / repo — project intent, target users, architecture direction, contribution policy, merge/sign-off gates, and maintenance priorities.
• Feature / subsystem — the target user outcome, local non-goals, constraints, and evidence that the subsystem is working.
• Loop / agent program — allowed autonomy, escalation gates, budgets, reviewer/judge policy, and learning/amendment rules. This is usually a companion policy, not the external VISION.md itself.

Use VISION.md for repo/project-level external intent when that is the convention. For smaller or larger scopes, choose a clearer path such as docs/vision.md, docs/<feature>/vision.md, .brain/areas/<area>.svx, or a section inside a PRD. The artifact name is less important than the scope and audience being explicit.