Data Framing

> Part of the data-scientist skill suite. Install data-scientist for full lifecycle orchestration and routing.

Data Framing

Purpose

Clarify and structure vague, high-level, or strategic data requests before any analysis begins. The posture is curious and structured: ask the right questions to find the real decision, the correct metric, the right audience, and the appropriate analysis path — before the team spends time on the wrong thing.

This skill does not run analysis. It frames it. The output is a framing brief, an analysis intake summary, a recommended workflow path, and a handoff packet for the next skill.

When To Use This Skill

Use data-framing when:

• The request is vague: "analyze this," "find insights," "help me with this dataset."
• The business decision, question, or outcome is unclear.
• The audience or stakeholder is unknown.
• The metric, target, or outcome variable is not specified.
• The grain or unit of analysis is not defined.
• The time window is unspecified or ambiguous.
• The deliverable type is unclear (dashboard? report? model? SQL? one-pager?).
• The user says "build a model" without a target, grain, or prediction point.
• The user says "make a dashboard" without knowing what decision it supports or who sees it.
• The user says "what should we measure for X?"
• The request involves a new project intake with no prior context.

When Not To Use This Skill

| Situation | Use instead | |---|---| | Simple conceptual questions ("what is correlation?") | Answer directly | | Already clear, narrow tasks | Answer directly or route to the right specialist | | User has already specified question, data, target, grain, timeframe, deliverable | Go directly to the appropriate specialist | | Inspecting a known dataset | data-explorer | | Defining a known metric | metric-analyst |

Relationship to Parent Skill

| Responsibility | Owner | |---|---| | Deciding to route to data-framing | Parent data-scientist (workflow/specialist-routing.md) | | Clarifying the business decision and question | This skill | | Identifying audience and stakeholder | This skill | | Clarifying metric, target, grain, time window, deliverable | This skill | | Proposing analysis paths | This skill | | Handoff to the next specialist | This skill | | Running the analysis, cleaning, or modeling | Downstream specialist skills |

Entry Gates

Before producing framing output, confirm or state as assumptions:

1. Enough to identify the likely decision or question — what problem is the user trying to solve?
2. Likely data source or domain — even a rough category (customer data, sales data, events log, survey responses) is enough.
3. Likely deliverable type — is the user expecting a report, dashboard, model, SQL query, or exploration?

If none of these are answerable, ask one open question before proceeding.

Framing Workflow

1. Identify the business or research decision.

What decision will this analysis inform? Who will make it? What changes if the analysis shows one result vs. another?

1. Clarify the target outcome or metric.

What does success look like? Is there a KPI, outcome variable, target label, or business metric at the center of this?

1. Clarify the audience or stakeholder.

Who receives the output? What is their technical level? What do they need to act on the result?

1. Clarify the data source and availability.

What data exists? What tables, files, or systems are available? Is there a data dictionary?

1. Clarify the grain or unit of analysis.

What does one row represent? Customer, order, session, product, week, market?

1. Clarify the time window.

What period is in scope? Historical baseline? Forecast horizon? Cohort window?

1. Clarify the deliverable type.

Dashboard? Executive memo? Model? SQL query? EDA report? Slide deck?

1. Identify constraints, risks, and success criteria.

Data access limits, team skill constraints, deadline, sensitivity, regulatory considerations, and what "good enough" looks like.

1. Propose 2–4 analysis paths when the request is broad.

Each path should name: the analytic approach, the data it requires, what it produces, and when it applies.

1. Recommend the next skill handoff.

After framing, name the next skill in the sequence.

Question Behavior

• Ask questions only when missing details would materially change the analysis path.
• For broad projects, ask grouped high-value questions — not one question at a time.
• If the user requests speed ("don't ask, just go"), state assumptions and proceed to the next appropriate skill.
• Do not ask endless questions. One round of focused questions is the limit before making reasonable assumptions and proceeding.
• Never block on information that can be assumed from context.

Output Formats

• Framing brief — structured summary: decision, audience, metric/target, grain, time window, deliverable, constraints, recommended path.
• Analysis intake summary — a short structured document suitable for sharing with a team.
• Recommended workflow path — which skills to use, in what order, and why.
• Handoff packet — the structured context passed to the next skill (see workflow/handoff-contracts.md in the parent skill).

Framing Brief Template

**Framing Brief**

Decision/question: [what will this analysis decide or answer?]
Audience: [who receives the output and at what level of detail?]
Metric/target: [KPI, outcome variable, or key measure]
Grain: [one row = one what?]
Time window: [period in scope]
Data source: [tables, files, or systems available]
Deliverable: [dashboard / report / model / SQL / EDA / other]
Constraints: [access, timeline, team skill, sensitivity]
Assumptions: [what was assumed due to missing information]
Recommended path: [next skill and rationale]

Recommended Handoff Paths

| After framing, route to… | When… | |---|---| | data-explorer | Real data is available and must be inspected before analysis | | metric-analyst | The core need is KPI definition or SQL metric logic, and data is already known | | experiment-analyst | The decision hinges on a test result or causal comparison | | dashboard-designer | The deliverable is a dashboard and metric definitions are already known | | insight-reporter | The deliverable is a stakeholder communication and analysis already exists | | production-analytics | The deliverable is an operational or scheduled pipeline | | Stay in data-scientist | The task involves modeling or forecasting that requires the parent skill |

Usually hands off to data-explorer when real data is involved.

Hard Rules

• Do not run analysis from this skill — framing only.
• Do not invent findings. The output is a structure for analysis, not analysis itself.
• Do not block on missing details that can be assumed from context.
• If the user says not to ask unless blocking, state assumptions and hand off.
• Always name the next skill in the recommended path.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: DAlanMtz
• Source: DAlanMtz/data-scientist
• License: MIT

Install and usage instructions live in the source repository linked above.