Forge-Scope-Definition

Define project scope boundaries, exclusions, constraints, and assumptions before requirements work begins.

Updated Jul 18, 2026
One-click install
npx skills add https://github.com/Nealsch/ForgeOS --skill forge-scope-definition-nealsch
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: Forge-Scope-Definition
Source: https://github.com/Nealsch/ForgeOS/tree/main/Framework/05-Skills/01-Product/Forge-Scope-Definition
Command: npx skills add https://github.com/Nealsch/ForgeOS --skill forge-scope-definition-nealsch

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Projects often start without an explicit, agreed boundary, so scope creep, stakeholder disagreement, and uncontrolled change follow. This Skill turns an initial intent into a documented scope baseline — what is in, what is out and why, and under which constraints — so every downstream engineering decision is made against a shared, testable definition. ## Core Features & Use Cases - Boundary Definition: Records in-scope users, systems, capabilities, and deliverables, plus an explicit out-of-scope list where every exclusion carries a rationale. - Constraint & Assumption Register: Captures regulatory, budget, timeline, and platform constraints with owners and validation paths. - Change Control: Assesses proposed changes for boundary impact and routes scheduling consequences to prioritisation. - Use Case: At the start of a Specify phase, a Product Owner and AI Program Manager use this Skill to produce a Project Definition that requirements analysis, solution architecture, and acceptance criteria all derive from. ## Quick Start Use the Forge-Scope-Definition skill to draft a project scope definition for this initiative, including in-scope items, explicit exclusions with rationale, and a constraint and assumption register.

Frequently Asked Questions about Forge-Scope-Definition

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I define project scope before writing requirements?▼

Anchor the intent with the Product Owner, enumerate in-scope users, systems and deliverables, then decide exclusions explicitly with rationale. Capture constraints and assumptions with owners, and publish the result as a Project Definition baseline.

What should a project scope definition document include?▼

It should include the problem statement and success measures, the in-scope boundary, an explicit out-of-scope list with rationale for each exclusion, and a constraint and assumption register with owners and validation paths.

How do I handle scope creep during a project?▼

Assess each proposed change for boundary impact against the documented scope baseline, update the Project Definition if accepted, and route scheduling consequences to prioritisation. Exclusions recorded with rationale make creep visible as a decision, not an accident.

When should scope definition not be repeated?▼

Do not re-run scope definition when an agreed, documented scope already exists and nothing has changed — reference the existing Project Definition instead. It is also not the right tool for writing requirements or deciding build order.

What is the difference between scope definition and requirements analysis?▼

Scope definition sets the boundary of what the project covers before requirements work begins. Requirements analysis then elicits, structures, and validates individual requirements inside that boundary, judging each one against the scope baseline.