Add Planning Project

/add-planning-project

Add a new project to the PM Planning Suite. Each project gets its own configuration space under .planning-config/projects/<project-name>/.

Prerequisites

• The planning suite must be initialized first (/init-planning-suite).
• If .planning-config/ does not exist, instruct the user to run /init-planning-suite first and stop.

File Creation

All files under .planning-config/ are pre-approved for creation and modification. The user consented when they ran /init-planning-suite. DO NOT ask for permission to create project.json, subdirectories, or any other file under .planning-config/. Write them directly.

Steps

Step 1: Get Project Name

If not provided as input (e.g., passed from /init-planning-suite), prompt: "What is the project name?"

Derive the directory name by sanitizing the project name into a filesystem-safe slug:

• convert to lowercase
• replace any sequence of spaces or non-alphanumeric characters with a single hyphen
• trim leading and trailing hyphens
• if the result is empty, ask the user for a different project name

Examples:

• "Contoso Platform" -> contoso-platform
• "Contoso/Platform: Core" -> contoso-platform-core

If sanitization changes the derived directory name, tell the user: "I'll store this project under .planning-config/projects/<project-dir>/." If the project name was just provided by the init skill in the same session, do not ask the user to confirm it again after showing the derived directory name. Proceed directly.

Check if .planning-config/projects/<project-dir>/ already exists. If it does, inform the user and ask if they want to reconfigure it.

Step 2: Create the Project Directory

Create the entire directory structure immediately. Do not ask the user about individual directories - just create them all:

.planning-config/projects/<project-dir>/
  project.json
  capacity/
  planning/
  specs/
  meetings/

All directories are created in a single step with no prompts. They are part of the standard project scaffold.

Step 3: Gather Project Settings

Walk the user through the project configuration. Accept answers one at a time.

Required Settings

1. ADO organization and project - The approach depends on whether other projects already exist:

   • First project (no other projects in .planning-config/projects/): Ask directly:
     • "What is your Azure DevOps organization URL? (e.g., 'contoso.visualstudio.com' or 'dev.azure.com/contoso')"
     • "What is the ADO project name? (e.g., 'ContosoOS')"
   • Subsequent projects (at least one project already exists): Read the ADO organization and project from the first existing project's project.json and offer to inherit:
     • "Your existing project uses ADO organization {org} and project {project}. Does this new project use the same ADO organization and project? (yes/no)"
     • If yes, inherit both values.
     • If no, ask for both values individually.

2. Area Path - "What Area Path should new work items use? (e.g., 'ContosoOS\Engineering\Platform\Core')"

3. Iteration Path prefix - "What is the Iteration Path prefix? (e.g., 'ContosoOS' if iterations are 'ContosoOS\2604')"

4. Default assignee - "Who should new scenarios be assigned to by default? (email)"

5. Placeholder assignee - "Who should costing deliverables and auto-generated work items be initially assigned to? This is the person or account that holds new items before they are distributed to the team - often a team lead, a shared triage alias, or a dedicated placeholder account. (email)"

Optional Settings

6. Parent objective ID - "Is there a parent Initiative/Objective ID that new scenarios should link to? (Enter an ADO work item ID or 'skip')"

7. Team members (FTE) - "Would you like to define your FTE team members now? Team data is used by several skills: Engineering Team Capacity uses it to calculate available engineer-days, Scenario Original Estimate uses expertise profiles to adjust cost estimates, and WBS Assignments uses it to match deliverables to the right people. You can add or edit members later in project.json. (yes/no/skip)"

   • If yes, offer two entry modes:
     • Batch entry (recommended for 3+ members): "You can paste a table of team members. Format: Name, Email, Role, Expertise, Allocation - one member per line, separated by tabs or commas. Example:

       Jane Smith, jsmith@contoso.com, Senior SWE, backend C# ASP.NET Core, 0.8
       Carlos Rivera, crivera@contoso.com, Data Scientist, Python ML Azure ML Kusto, 0.7
       

       Paste your table, or type 'one-by-one' to enter members individually."
     • Individual entry: Collect for each member:
       • Name - Display name (e.g., "Jane Smith")
       • Email - ADO identity email (e.g., "jsmith@contoso.com")
       • Role - Job title or function (e.g., "Senior SWE", "Data Scientist", "Principal SWE")
       • Expertise areas - Comma-separated list of technologies, domains, or skills (e.g., "backend, C#, ASP.NET Core, Azure Functions")
       • Default allocation - What percentage of this person's time is on this project? Enter 0.0 to 1.0. (e.g., 0.8 for 80%). This is used as the starting point by Engineering Team Capacity; it can be adjusted per planning period.
     • After entry, display the team table for confirmation before saving.
   • If skipped, inform the user: "Skills that need team data (Engineering Team Capacity, WBS Assignments) will prompt you to add team members when you run them."

8. Team members (Vendor) - Same collection flow as FTE above (batch or individual). Vendor members are stored separately and may be treated differently by capacity calculations (see Capacity Model).

   • If skipped, same informational message as FTE.

9. Vendor responsibilities - Only ask this if vendor team members were defined. "Are there specific work areas owned by the vendor team? For example, some teams route all UI work, security/SFI work, or deployment work to vendor members. (yes/no/skip)"

   • If yes, offer batch entry: "You can paste responsibilities as a list. Format: Work Area - Team Member Name, one per line. Example:

     UI work - Rajesh Tallapally
     SFI/Security - Aruna Pother
     Deployments - Sasikala Bestha
     

     Paste your list, or type 'one-by-one' to enter individually."
   • Write to vendor_responsibilities in project.json.

10. Categories - "Would you like to define planning categories for this project? These are used by the Scenario Categorization skill to organize your backlog. (yes/no/skip)"

    • If yes, offer two entry modes:
      • Batch entry: "You can paste categories as a list. Format: Category Name - Description, one per line. Example:

        Core Platform - Foundational platform capabilities, APIs, and services
        Infrastructure - Architecture modernization, tech debt, CI/CD, monitoring
        

        Paste your list, or type 'one-by-one' to enter individually."
      • Individual entry: Collect category name and description one at a time until "done".
    • After entry, display the category list for confirmation.

11. Repositories - "Do you have a local Git repository for this project? Adding a local repository enables the planning suite to automatically build a tech stack profile by scanning your codebase. This tech stack profile is used by the Scenario Original Estimate skill to produce more accurate cost estimates grounded in your actual technology choices, and by WBS Assignments to match deliverables to team members with the right expertise. You can always add one later by editing project.json. (yes/no/skip)"

    • If yes, collect: repo name and local path. Description is optional - if the user does not provide one, use the repo name as the description.
    • After collecting repositories, automatically scan the codebase to populate tech_stack_description:
      • Examine package manifests (package.json, requirements.txt, .csproj, go.mod, Cargo.toml, etc.)
      • Identify languages, frameworks, cloud services, databases, and infrastructure patterns
      • Write a concise summary to tech_stack_description in project.json
      • Show the generated tech stack summary to the user for confirmation
    • If the user skips or says no, leave repositories empty and tech_stack_description empty. Inform them: "You can add repositories later by editing project.json. Skills that use tech stack context will prompt you for a repository at that time."

12. Documentation sources - "Does your project have existing documentation that could help with planning? This could be a SharePoint site, wiki, design docs, spec library, or any other source of project knowledge. The Scenario Description Generator and estimation skills use these sources to produce better descriptions and more accurate estimates. (yes/no/skip)"

    • If yes, offer batch entry: "You can paste documentation sources as a list. Format: Name, URL, Type, Description - one per line. Example:

      Design Specs, https://contoso.sharepoint.com/sites/Platform/Specs, sharepoint, Feature specs and design reviews
      Team Wiki, https://dev.azure.com/contoso/wiki, wiki, Runbooks and operational docs
      

      Paste your list, or type 'one-by-one' to enter individually."
    • Write to documentation_sources array in project.json
    • If skipped, leave empty. Inform: "You can add documentation sources later by editing project.json."

13. Capacity model - "Which capacity calculation model should this project use? This determines how discount days (learning, training, holidays) are applied to your team's available time."

    Present these two options with explanations:

    • Default (recommended for most teams) - Discount days are subtracted from the gross working days first, then the allocation percentage is applied. This means everyone on the team loses the same proportion of discount days regardless of their allocation. Formula: Effective days = (Gross working days - Discount days) x Allocation. Example: 65 gross days - 5 discount days = 60 net days x 0.8 allocation = 48 effective days.

    • Post-allocation, FTE-only - Allocation is applied first, then discount days are subtracted only from FTE members. Vendor team members are not subject to discount days at all (they do not participate in organizational learning days, training, etc.). Formula for FTE: (Gross days x Allocation) - Discount days. Formula for Vendor: Gross days x Allocation. Example FTE: 65 gross days x 0.8 allocation = 52 days - 5 discounts = 47 effective days. Example Vendor: 65 gross days x 0.6 allocation = 39 effective days (no discounts).

    If the user is unsure, recommend "default".

Step 4: Write project.json

Assemble all gathered values into .planning-config/projects/<project-dir>/project.json:

{
  "project_name": "<display name>",
  "ado": {
    "organization": "<org>",
    "project": "<project>",
    "area_path": "<area path>",
    "iteration_path_prefix": "<prefix>",
    "parent_objective_id": null,
    "work_item_types": {
      "scenario": "Scenario",
      "deliverable": "Deliverable"
    }
  },
  "team": {
    "default_assignee": "<email>",
    "placeholder_assignee": "<email>",
    "members_fte": [],
    "members_vendor": [],
    "vendor_responsibilities": {}
  },
  "fiscal_calendar": {
    "fiscal_year_start_month": null,
    "current_fiscal_year": null,
    "current_quarter": null
  },
  "categories": [],
  "capacity_model": "default",
  "repositories": [],
  "tech_stack_description": "",
  "documentation_sources": [],
  "ranking_bands": null,
  "horizontal_budgets": null
}

Fill in all user-provided values. Leave optional fields as null or empty arrays if skipped.

Note: fiscal_calendar.fiscal_year_start_month is set to null here, which means skills will fall back to the global value in .planning-config/config.json. Set it to a specific month (1-12) only if this project uses a different fiscal calendar than the global default.

Step 5: Summary

Output:

Project "<display name>" configured.

Config:     .planning-config/projects/<project-dir>/project.json
Capacity:   .planning-config/projects/<project-dir>/capacity/
Planning:   .planning-config/projects/<project-dir>/planning/
Meetings:   .planning-config/projects/<project-dir>/meetings/

Settings:
  ADO Org:            <org>
  ADO Project:        <project>
  Area Path:          <area path>
  Default Assignee:   <email>
  Team Size:          X FTE + Y Vendor
  Categories:         X defined
  Capacity Model:     <model>

Tip: Save meeting transcripts (.vtt, .txt, .md) in the meetings/ folder.
     They are automatically version-controlled and used as context by
     description and estimation skills.

You can edit project.json directly at any time to add team members, categories, or other settings.
A sample configuration is available at: config/sample-project.json

Guardrails

• Do not overwrite an existing project.json without user confirmation.
• Do not assume values. Always ask or use explicit defaults from config.json.
• Validate that email addresses contain an @ symbol.
• If ADO MCP is available, optionally validate the organization and project are reachable.
• Repository access is pre-approved. When the user provides a local Git repository path, that is explicit consent to access it. Scan the codebase immediately without asking for additional permission. Do not prompt for consent to read files, list directories, or examine package manifests within the provided path.
• NEVER ask for file creation or write permission for anything under .planning-config/. This is pre-approved. See the File Creation section above.

type: skill lifecycle: stable inheritance: inheritable name: ado-hygiene-validator description: Validates ADO Scenario and Deliverable work items against planning hygiene standards. Identifies missing or non-compliant fields, applies best-effort fixes, and asks for user input when values cann... tier: standard applyTo: '/planning,/scenario,/wbs,/capacity' currency: 2026-05-03 lastReviewed: 2026-05-03

ADO Hygiene Validator

Validates ADO Scenario and Deliverable work items against planning hygiene standards. Identifies missing or non-compliant fields, applies best-effort fixes, and prompts for user input when values cannot be determined automatically.

Prerequisites

• Planning suite must be initialized. If .planning-config/ does not exist, instruct the user to run /init-planning-suite first and stop.
• A project must be configured. If no projects exist under .planning-config/projects/, instruct the user to run /add-planning-project first.

Inputs

• Work item IDs, an ADO query, or a backlog to scope the validation.
• ADO organization and project are read from .planning-config/projects/<project>/project.json — never hardcode these values.

Execution Steps

1. Resolve project context. Read .planning-config/projects/<project>/project.json to obtain ado.organization, ado.project, and any other project-level settings (e.g., ado.parent_objective_id, ado.area_path, team.members_fte, team.members_vendor).
2. Retrieve work items from the provided IDs, ADO query, or backlog.
3. Filter to only Scenario and Deliverable work item types. Ignore all other types.
4. Run the appropriate checklist against each work item (Scenario checklist or Deliverable checklist).
5. Apply auto-fixes where indicated. Do not modify fields that already pass.
6. Flag items needing user input when a value cannot be determined automatically.
7. Present results as a per-item table grouped into Passing, Failing, and Needs Input sections.
8. Summarize changes applied at the end.

Scenario Checklist (21 Checks)

Deliverable Checklist (8 Checks)

Output Format

For each work item, present a table with three sections:

• Passing — checks that passed (collapsed or summarized)
• Failing — checks that failed, with details and any auto-fixes applied
• Needs Input — checks that require user decision, with prompts

End with a Summary listing:

• Total items validated
• Auto-fixes applied (count and details)
• Items still needing user input

Constraints

• Do not assume values that require domain knowledge — prompt the user instead.
• Do not modify fields that already pass validation.
• Only process Scenario and Deliverable work item types. Skip all others.
• Report any ADO API validation errors to the user clearly.
• All ADO org/project values come from .planning-config/projects/<project>/project.json — never hardcode.

type: skill lifecycle: stable inheritance: inheritable name: cost-analysis description: Compare AI-generated Scenario Original Estimates against human-entered costing deliverable estimates with per-scenario and portfolio-level variance analysis. tier: standard applyTo: '/planning,/scenario,/wbs,/capacity' currency: 2026-05-03 lastReviewed: 2026-05-03

Cost Analysis

Prerequisites

• Planning suite must be initialized. If .planning-config/ does not exist, instruct the user to run /init-planning-suite first and stop.
• A project must be configured. If no projects exist under .planning-config/projects/, instruct the user to run /add-planning-project first.

Purpose

Compare AI-generated Scenario Original Estimates against human-entered costing deliverable estimates. Produces per-scenario variance and portfolio-level summary to surface estimation alignment or gaps.

Inputs

• ADO query link or work item IDs — a shared query URL or a comma-separated list of Scenario work item IDs.

Steps

1. Resolve Project Context

Load the active project configuration from .planning-config/projects/<project>/project.json. Use the ADO organization, project, and team settings defined there.

2. Parse Input and Execute Query

Accept the user-provided ADO query link or work item IDs. If a query link is provided, execute it to retrieve the list of Scenario work items. If work item IDs are provided, fetch each directly.

3. Identify Scenarios and Expand Children

For each Scenario work item, expand child work items. Locate costing deliverables — these represent the human-entered engineering cost estimates. Costing deliverables are identified by titles containing Costing] (case-insensitive). For backward compatibility, also recognize titles starting with [SWE] or [DS] without the "Costing" keyword.

4. Exclude Cut Deliverables

Filter out any child deliverables tagged or classified as Cut. These are descoped and must not factor into cost comparisons.

5. Extract Cost Data

For each Scenario, extract:

6. Calculate Variance

For each Scenario compute:

• Variance (days) = Costing Total − Scenario Original Estimate
• Variance (%) = ((Costing Total − Scenario Original Estimate) / Scenario Original Estimate) × 100

Sign convention: positive variance means humans estimated higher than the AI estimate; negative means humans estimated lower.

7. Classify Alignment Status

Assign each Scenario one of the following statuses based on the absolute variance percentage:

8. Portfolio Summary

Aggregate across all Scenarios:

• Total AI Estimate — sum of Scenario Original Estimates
• Total Human Estimate — sum of Costing Totals
• Coverage — count and percentage of Scenarios that have costing deliverables
• Overall Variance — portfolio-level days and percentage difference
• Status Distribution — count of Scenarios in each alignment category

9. Insights

Surface systematic estimation patterns:

• Consistent over-estimation or under-estimation direction
• Outlier Scenarios with extreme variance
• Areas or teams with recurring gaps
• Recommendations for calibration

Constraints

• Read-only — this skill does not create, update, or delete any ADO work items.
• No consent gate — because no modifications are made, no user confirmation is required before execution.

type: skill lifecycle: stable inheritance: inheritable name: cost-variance-analysis description: Detailed read-only variance analysis between AI-generated estimates and human costing with summary statistics, largest gaps, and distribution analysis. tier: standard applyTo: '/planning,/scenario,/wbs,/capacity' currency: 2026-05-03 lastReviewed: 2026-05-03

Cost Variance Analysis

Prerequisites

• Planning suite must be initialized. If .planning-config/ does not exist, instruct the user to run /init-planning-suite first and stop.
• A project must be configured. If no projects exist under .planning-config/projects/, instruct the user to run /add-planning-project first.

Purpose

Perform a detailed read-only variance analysis between AI-generated Scenario Original Estimates and human-entered costing deliverable estimates. Produces ranked variance tables, summary statistics, distribution analysis, and identifies the largest estimation gaps.

Inputs

• ADO query link or work item IDs — a shared query URL or a comma-separated list of Scenario work item IDs.

Steps

1. Resolve Project Context

Load the active project configuration from .planning-config/projects/<project>/project.json. Use the ADO organization, project, and team settings defined there.

2. Parse Input and Execute Query

Accept the user-provided ADO query link or work item IDs. If a query link is provided, execute it to retrieve the list of Scenario work items. If work item IDs are provided, fetch each directly.

3. Identify Scenarios and Expand Children

For each Scenario work item, expand child work items. Locate costing deliverables — these represent the human-entered engineering cost estimates. Costing deliverables are identified by titles containing Costing] (case-insensitive). For backward compatibility, also recognize titles starting with [SWE] or [DS] without the "Costing" keyword.

4. Exclude Cut Deliverables

Filter out any child deliverables tagged or classified as Cut. These are descoped and must not factor into cost comparisons.

5. Extract Cost Data

For each Scenario, extract:

6. Per-Scenario Variance Table

Build a ranked variance table sorted by absolute variance descending (largest gaps first). Each row includes:

Sign convention: Positive variance means humans estimated higher than the AI estimate. Negative variance means humans estimated lower.

7. Flag Non-Comparable Items

Separately list Scenarios that cannot be meaningfully compared:

• Missing AI Estimate — Scenario Original Estimate is zero or absent
• Missing Costing — no costing deliverables found
• Partially Costed — only some disciplines present, not all expected disciplines (flag but still include in analysis)

8. Summary Statistics

Produce an aggregate summary across all comparable Scenarios:

9. Distribution Analysis

Analyze the distribution of variance across the portfolio:

• Histogram buckets: ≤−50%, −50% to −20%, −20% to +20% (aligned), +20% to +50%, >+50%
• Count and percentage of Scenarios in each bucket
• Skew direction — whether the portfolio trends toward over- or under-estimation

10. Largest Gaps

Highlight the top 5 (or fewer) Scenarios with the largest absolute variance, including:

• Work item link
• Variance in days and percentage
• Brief note on possible contributing factors (e.g., missing costing discipline, scope complexity)

Constraints

• Read-only — this skill does not create, update, or delete any ADO work items.
• No consent gate — because no modifications are made, no user confirmation is required before execution.

type: skill lifecycle: stable inheritance: inheritable name: costing-deliverable-generator description: Creates costing placeholder deliverables under each Scenario for human cost entry. Supports user-defined disciplines (e.g., SWE, DS, PM, Design). tier: standard applyTo: '/planning,/scenario,/wbs,/capacity' currency: 2026-05-03 lastReviewed: 2026-05-03

Costing Deliverable Generator

Create costing placeholder Deliverable work items under each Scenario. Each costing deliverable represents a discipline (e.g., SWE, DS, PM, Design) and is intended for human cost entry - Original Estimate is left blank.

Prerequisites

• Planning suite must be initialized. If .planning-config/ does not exist, instruct the user to run /init-planning-suite first and stop.
• A project must be configured. If no projects exist under .planning-config/projects/, instruct the user to run /add-planning-project first.

Inputs

Accept any of the following:

• One or more work item IDs (comma-separated or space-separated)
• An ADO query (WIQL or saved query name)

Project Context

Load project configuration from .planning-config/projects/<project>/project.json. Extract:

• ado.organization - ADO organization name
• ado.project - ADO project name
• team.placeholder_assignee - the user to assign costing deliverables to

Discipline Configuration

Before processing scenarios, ask the user to define the costing disciplines for this run.

Prompt: "Costing deliverables let you estimate work by discipline. For example, if your team has Software Engineers and Data Scientists, you might create a costing deliverable for each discipline per scenario. How many costing disciplines do you want per scenario?"

Then for each discipline, ask: "What is the discipline name? (e.g., SWE, DS, PM, Design, QA, Infrastructure)"

The discipline name becomes the prefix in the deliverable title.

Example with 2 disciplines (SWE and DS):

Example with 3 disciplines (SWE, DS, PM):

Title format: [{Discipline} Costing] <scenario title>

The word "Costing" is always included in the title to distinguish costing deliverables from functional deliverables. Downstream skills use this pattern to identify costing deliverables.

Execution Steps

1. Resolve project context - Read .planning-config/projects/<project>/project.json. Load organization, project, and placeholder_assignee.
2. Gather discipline configuration - Ask the user how many disciplines and collect each discipline name. Store the list for use in steps below.
3. Parse input - Determine whether the user provided work item IDs or a query. Retrieve the list of Scenario work item IDs.
4. Fetch Scenarios with relations - For each work item, retrieve full details with relations expanded (use $expand=relations). This is needed to inspect existing child Deliverables.
5. Filter to Scenarios only - Exclude any non-Scenario work item types from the set.
6. Check existing children - For each Scenario, inspect child Deliverable work items:
   • A child whose title contains "Costing]" and starts with [{Discipline} (case-insensitive match) satisfies the requirement for that discipline.
   • Also recognize legacy patterns: a child starting with [SWE] (without "Costing") satisfies a SWE discipline if one was requested. Same for [DS].
   • If a matching child exists in Cut state, treat it as deliberately cut - do not recreate it.
7. Determine what to create - For each Scenario and each discipline, identify whether the costing deliverable is missing, exists, or was cut.
8. Present creation plan - Display a table showing: Scenario ID, Scenario Title, and one column per discipline (create/exists/cut). This is a consent gate - ask the user to confirm before creating any work items.
9. Create deliverables - Upon user confirmation, create each missing Deliverable with:
   • Title: [{Discipline} Costing] <scenario title>
   • Description: Costing deliverable ({discipline}) for: <scenario title>
   • Area Path: Inherited from the parent Scenario
   • Iteration Path: Inherited from the parent Scenario
   • Assigned To: Value from project.json team.placeholder_assignee
   • Original Estimate: Leave blank (for human entry)
   • Parent: Link to the parent Scenario work item
10. Report results - Summarize the completed creations with a table showing: Scenario ID, Scenario Title, and one column per discipline with the new Deliverable ID (or "existed"/"cut").

Constraints

• Never create duplicates. If a costing deliverable for a discipline already exists under a Scenario (any state except nonexistent), do not create another.
• Never modify existing deliverables. This skill only creates new work items; it does not update existing ones.
• Cut state is a deliberate decision. If a costing deliverable exists in Cut state, respect that decision and do not recreate it. Report it as "cut" in the output.
• Leave Original Estimate blank. Costing deliverables are placeholders for human cost entry. Do not write any estimate value.
• Consent gate is required. Always present the creation plan and wait for user confirmation before creating any work items in ADO.
• NEVER ask for file permission under .planning-config/. All writes are pre-approved.

type: skill lifecycle: stable inheritance: inheritable name: cut-line-helper description: Walks ranked scenarios in order, accumulates costing deliverable estimates, and identifies where team capacity is exhausted (the "cut line") with optional horizontal budget validation. tier: standard applyTo: '/planning,/scenario,/wbs,/capacity' currency: 2026-05-03 lastReviewed: 2026-05-03

Cut Line Helper

Prerequisites

• Planning suite must be initialized. If .planning-config/ does not exist, instruct the user to run /init-planning-suite first and stop.
• A project must be configured. If no projects exist under .planning-config/projects/, instruct the user to run /add-planning-project first.

Purpose

Walk ranked Scenarios in priority order, accumulate costing deliverable estimates, and identify the point where team capacity is exhausted — the "cut line." Optionally validates horizontal budgets if configured. Produces a visual ranked table and persists results for downstream skills.

Inputs

• ADO query link — a shared query URL that returns the ranked Scenario work items.
• Project context — the active project from .planning-config/projects/<project>/project.json, which provides the path to capacity data.

Steps

1. Resolve Project Context

Load the active project configuration from .planning-config/projects/<project>/project.json. Extract ADO settings and the capacity file path.

2. Load Capacity

Load team capacity from .planning-config/projects/<project>/capacity/<period>.md.

If the capacity file does not exist, instruct the user to run the Engineering Team Capacity skill first to generate it, and stop.

3. Load Horizontal Budgets (if configured)

Check project.json for horizontal budget configuration. If present, load the budget allocations (e.g., per-area or per-initiative budgets that constrain spending beyond total capacity).

4. Retrieve and Sort Scenarios

Execute the ADO query to retrieve Scenario work items. Sort by OSG.Rank ascending (rank 1 = highest priority).

5. Expand Children and Sum Costs

For each Scenario, find child work items and locate costing deliverables. Costing deliverables are identified by titles containing Costing] (case-insensitive). For backward compatibility, also recognize titles starting with [SWE] or [DS] without the "Costing" keyword. Exclude any deliverables classified as Cut. Sum the Original Estimate values to get the Scenario's engineering cost.

6. Classify Scenarios

Assign each Scenario a classification:

7. Walk Rank Order and Determine Cut Line

Starting from rank 1, accumulate engineering cost for each costed Scenario:

1. Livesite / DRI items are always committed — add their cost first as a baseline.
2. PM Investigation items carry zero engineering cost and are included without affecting capacity.
3. Walk remaining costed Scenarios in rank order, adding each Scenario's cost to the running total.
4. The cut line falls at the point where cumulative cost exceeds available capacity. All Scenarios above the line are committed; all below are at risk or cut.

8. Present Results Table

Display a ranked table with visual indicators:

…(truncated)