---
name: scorpio-objective-intake
description: Conduct the objective intake interview that normalizes a business objective into canonical planning artifacts for the objective workflow.
---

# Objective Intake Interview

A structured intake skill for the first stage of `scorpio objective`. It gathers a business objective, constraints, unknowns, and operating mode, then writes the canonical objective brief and normalized parameters for downstream scenario expansion.

## Purpose

This skill exists to turn a conversational objective into a machine-readable planning input without jumping to solution selection.

It must:

1. capture the objective in the operator's words
2. separate facts, assumptions, and unknowns
3. branch cleanly for greenfield and existing-product cases
4. leave downstream strategic search to later skills

## Inputs

Read only:

1. the operator conversation for the current objective
2. optional project context when the objective targets an existing product

Do not depend on downstream proposal artifacts.

## Shared Rules

1. Ask one focused question at a time.
2. Keep responses concise and avoid recaps.
3. Prefer exact wording from the operator when possible.
4. Preserve uncertainty explicitly instead of filling every gap.
5. Do not propose solution packages, rankings, or feature sets as the main output.

## Coverage Targets

Track progress toward minimum intake coverage:

- Objective: the desired business outcome
- Mode: `greenfield` or `existing_product`
- Audience: who the objective is for
- Constraints: business, technical, legal, or operational limits
- Success: how the operator will know the objective worked
- Unknowns: unresolved questions that affect strategy

## Question Progression

Follow this order and stop once the intake is sufficiently grounded:

1. Objective
   - What outcome are we trying to achieve?
2. Mode
   - Is this a greenfield objective or an existing product?
3. Audience
   - Who is this for, and who is not in scope?
4. Constraints
   - What limits should the strategy respect?
5. Success
   - What would make this objectively successful?
6. Unknowns
   - What do we still not know that could change the direction?

If the objective is `existing_product`, also ask about:

1. current product behavior
2. what already works
3. what is broken, weak, or missing
4. compatibility, migration, or adoption constraints

If the objective is `greenfield`, also ask about:

1. the problem space
2. the intended first users
3. the expected differentiation
4. the minimum viable outcome

## Required Outputs

Write the canonical planning artifacts to `{docs.planning}/`:

- `{docs.planning}/OBJECTIVE-BRIEF.md`
- `{docs.planning}/OBJECTIVE-PARAMETERS.json`

If the runtime provides a request-scoped objective directory, mirror those same artifacts there as well, but keep the root canonical files updated in the same run.

## Canonical Brief Shape

`OBJECTIVE-BRIEF.md` should summarize:

1. objective statement
2. mode
3. audience
4. constraints
5. success criteria
6. unknowns
7. assumptions

## Canonical Parameters Shape

`OBJECTIVE-PARAMETERS.json` should follow the canonical schema contract. A recommended shape is:

```json
{
  "version": 1,
  "project_mode": "greenfield | existing_product",
  "business_objective": {
    "summary": "",
    "objective_type": "growth | revenue | retention | activation | engagement | trust | efficiency | other",
    "time_horizon": "",
    "priority": "high | medium | low"
  },
  "desired_outcomes": [
    {
      "metric": "",
      "baseline": null,
      "target": "",
      "deadline": "",
      "notes": ""
    }
  ],
  "target_users": {
    "primary_segments": [],
    "secondary_segments": [],
    "geographies": [],
    "platforms": []
  },
  "constraints": {
    "business_model": "",
    "budget": "",
    "team_size": "",
    "launch_constraints": [],
    "technical_constraints": [],
    "legal_trust_constraints": [],
    "do_not_do": []
  },
  "evidence": {
    "known_facts": [],
    "assumptions": [],
    "unknowns": [],
    "source_quality": "low | medium | high"
  },
  "approval": {
    "operator_notes": "",
    "must_approve_before_tasks": true
  },
  "greenfield_context": {
    "product_idea_summary": "",
    "initial_value_hypothesis": "",
    "intended_distribution": [],
    "intended_monetization": [],
    "mvp_preferences": [],
    "explicit_out_of_scope": []
  },
  "existing_product_context": {
    "current_product_state": "",
    "current_core_features": [],
    "current_user_segments": [],
    "current_distribution": [],
    "current_monetization": [],
    "current_metrics_baseline": [
      {
        "metric": "",
        "value": "",
        "period": ""
      }
    ],
    "known_product_gaps": [],
    "current_strengths": [],
    "do_not_break": [],
    "available_assets": []
  }
}
```

Populate the branch that applies and leave the other branch `null`.

## Greenfield Branch

Use the `greenfield_context` branch when the operator is starting from scratch or from a concept without an existing product surface.

Must capture:

1. the problem space
2. the first user segment
3. the expected wedge or differentiation
4. the minimum viable success threshold
5. the product idea summary that grounds later package search

## Existing-Product Branch

Use the `existing_product_context` branch when the objective is to improve, extend, or reposition an existing product.

Must capture:

1. current product behavior
2. what already works
3. what is failing or insufficient
4. constraints around compatibility, migration, or adoption
5. either a current metrics baseline or an explicit unknown that no baseline exists

## What Not To Do

- Do not write `{docs.tasks}/**`.
- Do not select a scenario winner.
- Do not bundle solution packages.
- Do not score options.
- Do not produce implementation planning artifacts.

## Handoff

When intake is complete, hand the normalized parameters to `scorpio-objective-scenarios`.