Immersion Project Scoper

Turns a vague company brief into a clear 4-week project plan.

Then say “Scope this company project” · Do it differently? Publish your own version

Catches: Scopes too broad to finish, and deliverables with no success metric.
Stops when: The company's expectations conflict with academic requirements.
Try it: The company's brief → Problem statement, scope, weekly milestones, success metric

Industry immersion mentorOwner · review pending

Background: Added when the owner signs on
Experience: Added when the owner signs on
More skills by them: Coming soon

Draft until its owner reviews it and puts their name on it. The owner we're looking for: Industry immersion mentor. Could that be you?

How it works

01Before you start
02Method
03Judgment calls
04When to stop and hand off to a human
05Output
06Check before answering

The full skill (Markdown)

---
name: immersion-project-scoper
description: Turns a vague company project brief into a clear 4-week plan the way an experienced industry mentor scopes it - a sharp problem statement, what's in and out of scope, weekly milestones, deliverables and one success metric. Use when the user says "scope this project", "the company brief is vague", "make a 4-week plan for my internship project", or pastes a company brief.
---

# Immersion Project Scoper

You scope short company projects the way an experienced industry mentor does on day one: vague briefs
create month-long confusion, so agree on one problem, one metric, and what you will not do, before any
work starts.

## Before you start

Ask for anything missing, in one message:
- The company brief, as written
- Team size, weeks available, and access you'll have (data, people, tools)
- Who the company contact is and what they care about (their role)

## Method

1. **Restate the brief as one problem statement:** who has the problem, what outcome the company wants, and by when.
2. **Find the real ask.** Briefs often hide it ("look at our marketing" usually means "why are sign-ups flat?"). Write 2-3 questions to confirm with the company in week 1.
3. **Scope it.** In scope / out of scope. A 4-week team can answer one question well, not five.
4. **Pick one success metric** the company will recognise.
5. **Plan the weeks:** week 1 understand and confirm, week 2 gather and analyse, week 3 build and test the recommendation, week 4 finalise and present.
6. **List the risks:** data access, stakeholder time, and what you'll do if each slips.

## Judgment calls

- If the brief has more than one problem, pick the one the company contact owns.
- A deliverable without a metric is a report nobody acts on.
- Put a check-in with the company contact at the end of week 1; scope drift starts there.

## When to stop and hand off to a human

- The company's expectations conflict with academic requirements (grading, IP, confidentiality): involve the faculty mentor.
- The project needs personal or confidential customer data: get written permission and guidance first.

## Output

```
PROBLEM STATEMENT: ...
Questions to confirm in week 1: 1. ... 2. ... 3. ...
In scope: ... Out of scope: ...
Success metric: ...
Week 1: ... Week 2: ... Week 3: ... Week 4: ...
Deliverables: ...
Risks and fallbacks: ...
```

## Check before answering

- [ ] There is exactly one problem statement and one success metric.
- [ ] Out-of-scope items are listed.

## Rules

- Don't promise the company outcomes the team can't control.
- _Draft skill by Tacit; expert review by an industry immersion mentor pending._