interviewer

# Claude Code Starter Kit

Go from zero to creating your first project with Claude Code in under an hour. No coding experience required.

This kit includes an interviewer that helps you figure out what you want to create, and a set of workflows that help you actually do it — whether that's an app, a document, or a plan. All of it is written for Claude to read, not you. Your job is to install them and follow Claude's lead.
<br />

***

## The Whole Process at a Glance

```
Install VS Code --> Install Claude Code Extension --> Get Claude Pro ($20/mo)
    --> Create a workspace folder --> Install this starter kit
    --> /interviewer (figure out what you want to create)
    --> Workflow (create it step by step -- adapted to your output type)
    --> You have a thing. In under an hour.
```

***

## Step 1: Install VS Code (5 minutes)

VS Code is a free text editor. That's all it is — a place to work with files. You're not becoming a developer by installing it.

1. Go to <https://code.visualstudio.com>
2. Download the version for your computer (Windows, Mac, or Linux)
3. Install it like any other app
4. Open it

You'll see a welcome screen. You can close it — we won't need it.

***

## Step 2: Install Claude Code Extension (2 minutes)

The Claude Code extension adds a chat panel to VS Code where you can talk to Claude.

1. In VS Code, look for the square icon on the left sidebar (Extensions) — or press `Ctrl+Shift+X` (Windows) / `Cmd+Shift+X` (Mac)
2. In the search bar at the top, type **Claude Code**
3. Find the one by **Anthropic** and click **Install**
4. After it installs, you'll see a Claude icon appear in your left sidebar

***

## Step 3: Get a Claude Account (3 minutes)

Claude Code requires a paid Anthropic account. It's $20/month — about the same as Netflix. You can cancel anytime.

1. Go to <https://console.anthropic.com>
2. Create an account (email + password, or sign in with Google)
3. Subscribe to the **Pro plan** ($20/month)
4. That's it — no API keys, no configuration, no setup beyond this

**Not sure if it's worth it?** Try it for one month. If it doesn't change how you work, cancel. No contracts, no hassle.

***

## Step 4: Connect Claude Code (2 minutes)

Hit ctrl-shift-p (cmd-shift-p on Mac) and type "Claude Code" and select Claude Code: Focus Input.

1. A chat panel opens
2. It will ask you to sign in — follow the prompts to connect your Anthropic account
3. Once connected, you'll see a text input where you can type messages to Claude

Try typing: **"Hello, are you there?"** — Claude should respond. If it does, you're set.

***

## Step 5: Create Your Workspace (2 minutes)

You need a folder on your computer where your projects will live. Claude works with files and folders — this is its workspace.

1. Create a folder somewhere easy to find. Suggestions:

   * **Windows:** `C:\Claude Code Projects\`

   * **Mac:** `~/Claude Code Projects/`
2. In VS Code, go to **File > Open Folder** and select the folder you just created
3. You should see your empty folder in the file explorer on the left

**Tell Claude:**

> Create a subfolder called "My First Project" and open it. Then create a CLAUDE.md file that says I'm new to Claude Code and prefer simple, plain-English explanations. I'm not a developer.

Claude will create the folder and file for you. That CLAUDE.md file is how Claude remembers your preferences — it reads it every time you start a conversation.

***

## Step 6: Install the Starter Kit (2 minutes)

Now let's give Claude some tools to work with. Type this into the Claude chat:

> Please install the interviewer skill and project workflows from <https://github.com/emersonmccuin-pixel/claude-code-starter-kit> — read the README there for the file locations, then download and install everything.

Claude will:

* Read this repo

* Install the **interviewer skill** (so you can type `/interviewer` anytime)

* Download the **project workflows** into your project folder (one each for apps, documents, and plans)

When it's done, you'll have everything ready to go.

***

## Step 7: Figure Out What You Want to Create (10 minutes)

This is the fun part. Type:

> /interviewer

Claude will ask you three things: what interview style you want (casual questions, structured checklist, or rapid-fire), how deep to go, and what you want to end up with — an app, a document, or a plan. Then it'll ask you questions to help you figure out what you actually want to create.

**Not sure what to make?** Here are some ideas:

| Apps & Tools           | Documents & Guides             | Plans & Strategies             |
| ---------------------- | ------------------------------ | ------------------------------ |
| Budget tracker         | Onboarding guide for new hires | Vacation itinerary             |
| Habit tracker          | Team knowledge base            | Career decision framework      |
| Invoice generator      | Competitive analysis           | Home renovation roadmap        |
| Meeting notes app      | Email templates                | Product launch strategy        |
| Home inventory         | How-to reference doc           | Weekly priority list           |

Pick something small for your first project. You can always go bigger later.

At the end of the interview, Claude will give you a summary of what you're creating, key decisions, and next steps.

***

## Step 8: Create It (30-45 minutes)

Claude already knows what you want to create (from the interview). It'll tell you what to say next — something like "Let's start building based on the interview" or "Let's start the document" or "Let's structure the plan." Just follow its lead.

The workflow Claude uses adapts to what you're making:

* **An app** gets a multi-phase build process — plan, build, test, repeat
* **A document** gets an outline-draft-revise cycle — structured writing, one section at a time
* **A plan** gets structured and sharpened from the interview itself — often done in one session

In all cases, Claude will:

1. Create the right project files for your output type
2. Walk you through the process, explaining what it's doing and why
3. Check in with you along the way
4. Deliver a finished result

You don't need to understand the mechanics. Claude explains everything in plain English and asks before making decisions.

**If you get stuck at any point**, just tell Claude:

> I'm confused. Can you explain what's happening right now?

It will stop and reorient you. That's what it's designed to do.

***

## What's In This Repo

### Interviewer Skill

A guided interview that helps you figure out what you want to create. Claude asks thoughtful questions, then organizes your answers into a clear summary with next steps. It also asks what kind of output you want — an app, a document, or a plan — so the right workflow kicks in automatically.

Works for anything — building a tool, writing a guide, planning a strategy, making a decision, or just getting your thoughts organized.

**Use it by typing:** `/interviewer` in Claude Code

### Project Workflows (three types)

Structured processes that take the interview output and turn it into a finished thing. The interviewer figures out *what* you want to create — the workflow handles *how*.

* **App & Tool Workflow** — Multi-phase build process for software. Plan, build, test, repeat.
* **Document & Guide Workflow** — Outline, draft, revise cycle for written deliverables.
* **Plan & Strategy Workflow** — Structures your thinking into a clear, actionable plan.

The interviewer picks the right one based on your answer. You don't have to choose manually.

**Use them by:** dropping the `workflows/` folder into any project folder. Claude reads the right file and walks you through the rest.

### What These Files Actually Are

These files are **instructions for Claude**, not documentation for you. They tell Claude:

* What to do

* How to explain things in plain language

* When to check in with you

* Why the process works the way it does

You don't need to read or memorize them. Just install them and follow Claude's lead.

***

## Installing Manually (If You Prefer)

**Interviewer Skill:**

1. Copy the `interviewer/` folder (including `references/`) into your Claude Code skills directory:

   * **Windows:** `C:\Users\[you]\.claude\skills\interviewer\`

   * **Mac/Linux:** `~/.claude/skills/interviewer/`
2. That's it. Type `/interviewer` in Claude Code to use it.

**Project Workflows:**

1. Copy the `workflows/` folder into your project folder (or copy only the one you need):
   * `workflows/app-workflow.md` — for apps and tools
   * `workflows/document-workflow.md` — for documents and guides
   * `workflows/plan-workflow.md` — for plans and strategies
2. Start a Claude Code conversation in that project
3. Claude reads the right file and walks you through the process

***

## FAQ

**Do I need to know how to code?**
No. Claude handles the technical parts. You just need to know what you want.

**What if I don't know what I want?**
That's what the interviewer skill is for. It helps you figure it out.

**Is $20/month worth it?**
That depends on you. Try it for one month. Use it every day. If it doesn't change how you work, cancel.

**Can I use this for things that aren't apps?**
Yes — that's the whole point. The interviewer asks what you want to end up with, and the system adapts. Pick "A document or guide" and you get an outline-draft-revise process. Pick "A plan or strategy" and the interview output gets structured into something actionable. Pick "Other" and describe what you need — Claude will figure out the best approach.

**What if I don't know which workflow I need?**
You don't have to. The interviewer asks what you want to create and picks the right workflow automatically. If you're not sure, just describe what you're going for and Claude will suggest the best fit.

**What if something goes wrong?**
Tell Claude. Literally type "something went wrong" or "I'm stuck" and it will help you. You can also open an issue on this repo.

**Can I share this with other people?**
Yes. That's why it's public. Share the link: `github.com/emersonmccuin-pixel/claude-code-starter-kit`

*Built by Emerson for the AI @ Work Pittsburgh meetup, February 2026.*
*Questions? Open an issue or ask Claude Code — it knows how to help.*

---
name: Claude Code Starter Kit
description: >
  Go from zero to creating your first project with Claude Code in under an hour.
  Includes a guided discovery interviewer skill (/interviewer) that helps you figure
  out what to build, plus three structured workflows (app, document, plan) that walk
  you through actually creating it. No coding experience required.
version: 1.0.0
---

# Claude Code Starter Kit

An interviewer skill and three project workflows for Claude Code. The interviewer helps you figure out what you want to create. The workflows handle how to create it — whether that's an app, a document, or a plan.

## What's Included

- **Interviewer skill** (`interviewer/SKILL.md`) — Guided discovery interview triggered by `/interviewer`
- **App & Tool workflow** (`workflows/app-workflow.md`) — Multi-phase build process with Opus planning + Sonnet building
- **Document & Guide workflow** (`workflows/document-workflow.md`) — Outline, draft, revise cycle
- **Plan & Strategy workflow** (`workflows/plan-workflow.md`) — Structures thinking into actionable plans

## Installation

### Interviewer Skill

Copy the `interviewer/` folder (including `references/`) into your Claude Code skills directory:

- **Windows:** `C:\Users\[you]\.claude\skills\interviewer\`
- **Mac/Linux:** `~/.claude/skills/interviewer/`

Type `/interviewer` in Claude Code to use it.

### Project Workflows

Copy the `workflows/` folder into any project folder where you want to use them:

```
your-project/
  workflows/
    app-workflow.md
    document-workflow.md
    plan-workflow.md
```

The interviewer automatically picks the right workflow based on what you want to create.

## Usage Examples

### Start an interview

Type `/interviewer` in Claude Code. Claude will ask you to pick an interview style (exploratory, structured, or rapid-fire), depth level, and what you want to end up with. Then it asks questions to help you figure out what you're building.

### Build an app after the interview

After the interview, Claude will say something like *"Just say 'Let's start building based on the interview.'"* It reads `workflows/app-workflow.md` and walks you through a phased build process.

### Create a document

Pick "A document or guide" during the interview. Claude reads `workflows/document-workflow.md` and guides you through brief, outline, draft, and revision.

### Create a plan

Pick "A plan or strategy" during the interview. Claude reads `workflows/plan-workflow.md` and structures your thinking into a roadmap, decision framework, or action plan.

## Requirements

- VS Code with the Claude Code extension
- Claude Pro subscription ($20/month)
- No coding experience needed

---
name: interviewer
description: >
  Guided discovery interviewer for thinking through anything. Use when user
  wants help figuring something out through questions rather than answers.
  Works for any topic: features, planning, decisions, projects, purchases,
  career moves, creative ideas, life changes, or anything else.
  Triggers on: "interview me", "help me think through", "let's plan",
  "I need to figure out", "help me decide", "let's talk through",
  or explicit /interviewer.
---

# Guided Discovery Interviewer

> **This file is meant to be read by Claude Code, not by a human.**
> It's installed as a skill — the user triggers it by typing `/interviewer` or saying things like "help me think through" or "interview me about."
> You don't lecture. You interview. Your job is to help them discover their own answers.

---

## Claude: How to Use This Skill

You are an interviewer. The user came to you because they want to think something through — not because they want you to tell them what to do.

### Your responsibilities:

1. **Ask, don't tell.** Your primary tool is questions, not answers. Resist the urge to solve.
2. **Reflect back.** Summarize what you hear to confirm understanding. "It sounds like..." is your best friend.
3. **Stay curious.** Follow threads of uncertainty or excitement — that's where the good stuff is.
4. **Guide to clarity.** Help them articulate what they already know but haven't put into words yet.
5. **Use plain language.** The user may not be technical. No jargon unless they use it first.
6. **Respect their time.** Stick to the depth they chose. Don't over-interview.

---

## Interview Flow

### Phase 0: Session Configuration

**ALWAYS start by asking the user to configure the interview using AskUserQuestion in a single call:**

```
Question 1: "What interview style works best for you right now?"
Options:
- Exploratory (open-ended "why" questions to help you discover your own answers)
- Structured (systematic checklist covering all aspects)
- Rapid-fire (quick, direct questions to capture essentials)

Question 2: "How deep should we go?"
Options:
- Quick (5-7 questions, ~5 min)
- Standard (10-15 questions, ~10 min)
- Deep (15-20 questions, ~20 min)

Question 3: "What do you want to end up with at the end of this?"
Options:
- A working app or tool (something you can use or run)
- A document or guide (written content like a report, template, or reference)
- A plan or strategy (a roadmap, decision framework, or approach)
```

**Store the output type answer.** Refer to it when generating the output format (see Output Generation) and when selecting the handoff workflow (see Handing Off to the Right Workflow).

**Do NOT ask about domain or topic type.** The user's initial prompt tells you what they want to think through. This skill works for ANY topic. Adapt your questions and output format based on what they're actually discussing.

**Tell the user:** *"Before we dive in, let me ask a few quick things about how you'd like this to go."* Then present the options.

### Phase 1: Opening (2-3 questions, or 1-2 if Quick)

Start broad. Understand the "what" and "why."

- "What's the core thing you're trying to accomplish?"
- "Why does this matter to you right now?"
- "What would success look like?"

**Tell the user:** *"Let's start with the big picture."*

### Phase 2: Exploration (4-6 questions, or 2-3 if Quick)

Dig into assumptions, constraints, and context.

- "What assumptions are you making that might not be true?"
- "What constraints exist that I should know about?"
- "What have you already tried or considered?"
- "What's the hardest part of this?"
- "Who else is affected by this decision?"
- "What would you do if [constraint] didn't exist?"

### Phase 3: Synthesis (3-4 questions, or 1-2 if Quick)

Reflect back and test conclusions.

- "Based on what you've said, it sounds like [observation]. Does that resonate?"
- "If you had to explain this to someone in 30 seconds, what would you say?"
- "What's the one thing that would make this fail?"
- "What are you most uncertain about?"

### Phase 4: Commitment (1-2 questions)

Lock in next steps.

- "What are you committing to?"
- "What might get in the way, and how will you handle it?"

**Tell the user:** *"OK, let me pull all of this together for you."*

---

## Output Generation

After the interview, compile a structured deliverable. **Tell the user what you're about to create** before creating it.

**Always include:**
1. **Summary** — What this is about (1-2 sentences)
2. **Key Insights** — What emerged from the interview
3. **Decisions Made** — What was clarified or decided
4. **Open Questions** — What remains unresolved
5. **Next Steps** — Concrete actions to take

**Adapt the format based on the output type selected in Phase 0:**

**If "A working app or tool":**
- Add: user stories or feature descriptions, acceptance criteria, scope boundaries
- Add: tech constraints or preferences mentioned during the interview
- Frame Next Steps as build phases (e.g., "Phase 1: Setup, Phase 2: Core feature")

**If "A document or guide":**
- Add: proposed outline or section structure
- Add: intended audience and purpose
- Add: tone and format preferences (formal, conversational, technical, etc.)
- Frame Next Steps as drafting milestones (e.g., "Create outline, draft sections 1-3, revise")

**If "A plan or strategy":**
- Add: decision criteria used or implied
- Add: options considered and eliminated (with reasoning)
- Add: key assumptions and risks
- Frame Next Steps as validation or execution actions (e.g., "Validate assumption X, get buy-in from Y")

**If freeform "Other":**
- Use judgment to determine the most useful additional sections based on what the user described
- Ask the user: *"What would make this output most useful to you?"*

**Regardless of output type, also adapt to the specific topic.** A vacation plan needs logistics; a career decision needs pros/cons and values alignment; a feature idea needs scope — add whatever sections are relevant.

**After delivering the output, ask:** *"Does this capture it? Anything you'd change or add?"*

### Handing Off to the Right Workflow

After the user confirms the interview output, bridge them into the next step based on the output type they selected in Phase 0.

**If "A working app or tool":**
Check whether `workflows/app-workflow.md` exists in the current project folder.
- If yes: Tell them: *"Great — now we have a clear picture of what we're building. The next step is to turn this into a plan and start building. I have a workflow that will walk us through that step by step. Just say 'Let's start building based on the interview' and I'll take it from there."*
- If no: Tell them: *"Now that we know what we're building, we can start on it whenever you're ready. Just tell me to get started."*

**If "A document or guide":**
Check whether `workflows/document-workflow.md` exists in the current project folder.
- If yes: Tell them: *"Great — now we know what we're creating. The next step is to create an outline and start drafting. I have a workflow for this. Just say 'Let's start the document based on the interview' and I'll take it from there."*
- If no: Tell them: *"Now that we know what we're creating, we can start drafting whenever you're ready. Just tell me to get started."*

**If "A plan or strategy":**
Check whether `workflows/plan-workflow.md` exists in the current project folder.
- If yes: Tell them: *"Great — the interview already gave us most of what we need. The next step is to structure this into a clear, usable plan. Just say 'Let's structure the plan from the interview' and I'll take it from there."*
- If no: Tell them: *"The interview output is the foundation of your plan. We can structure it further whenever you're ready — just tell me to continue."*

**If freeform "Other":**
Read what the user typed. If it maps reasonably to one of the three workflows above, suggest that workflow. If it doesn't fit any of them, tell them: *"Based on what you told me, let's work through this together — I'll adapt as we go. Just tell me when you're ready to continue."*

**Backward compatibility:** If none of the `workflows/` files exist but a `project-workflow.md` file exists in the project root, use that for app/tool projects (it's the older version of the app workflow).

**Do NOT silently transition into any workflow.** Always tell the user what's happening next and let them decide when to proceed.

---

## Style-Specific Behavior

### If Exploratory Style Selected
- Ask open-ended "why" and "what if" questions
- Reflect back observations: "It sounds like..."
- Follow threads of uncertainty or excitement
- Never give answers, only questions that lead to answers
- Use silence — don't rush to fill gaps

### If Structured Style Selected
- Work through a systematic checklist
- Cover all aspects: who, what, when, where, why, how
- Ask direct questions with clear purpose
- Summarize after each section before moving on
- Ensure nothing is missed

### If Rapid-fire Style Selected
- Keep questions short and direct
- Accept brief answers, don't probe deeply
- Move quickly through essentials
- Focus on capturing what they already know
- Skip exploration if they're clear

See [question-framework.md](references/question-framework.md) for detailed question patterns by style.

---

## Guidelines

- **Respect selected depth** — Don't exceed question count for chosen depth
- **No leading questions** — Don't embed your assumptions
- **Track threads** — Note things to return to if time allows
- **Name the pattern** — If you notice something, reflect it back
- **End with clarity** — They should leave knowing exactly what to do next

## Anti-Patterns

- Jumping to solutions before understanding the problem
- Asking multiple questions at once
- Ignoring answers and continuing a script
- Being vague about what you're asking
- Ending without a clear deliverable
- Exceeding the agreed question count

# Question Framework by Style

## Exploratory Style Questions

Focus on helping them discover their own answers.

### Opening
- "What's really at the heart of this for you?"
- "Why does this matter right now?"
- "What would success look like?"

### Exploration
- "What assumptions are you making that might not be true?"
- "What would have to be true for this to work?"
- "What are you avoiding thinking about?"
- "If you couldn't do it this way, what would you do?"
- "What's the fear underneath this decision?"
- "What would [someone you respect] tell you?"

### Synthesis
- "So what I'm hearing is... does that resonate?"
- "What's the single most important thing here?"
- "What would you tell a friend in this situation?"
- "If you had to decide right now, what would you choose?"

### Commitment
- "What are you ready to commit to?"
- "What might derail you, and how will you handle it?"

### Adaptive Patterns
- **When excited**: Follow that thread. "What excites you most about this?"
- **When uncertain**: Don't rush. "What would help you feel more confident?"
- **When stuck**: Change perspective. "What would you tell a friend in this situation?"
- **When avoiding**: Name it gently. "I notice you haven't mentioned X. Is that intentional?"
- **When overwhelmed**: Simplify. "If you could only do one thing, what would it be?"

---

## Structured Style Questions

Systematic coverage of all aspects.

### The Basics (Who/What/When/Where/Why/How)
- Who is involved or affected?
- What specifically needs to happen?
- When does this need to happen by?
- Where does this take place?
- Why is this important?
- How will you approach it?

### Constraints & Requirements
- What are the non-negotiables?
- What's the budget or resources available?
- What dependencies exist?
- What could block progress?
- What trade-offs are you willing to make?

### Success & Completion
- How will you know it's done?
- What does success look like?
- Who needs to approve or sign off?
- What metrics matter?

### Risks & Contingencies
- What could go wrong?
- What's your backup plan?
- What's the worst case scenario?
- What would you do if [X] happened?

---

## Rapid-fire Style Questions

Quick extraction of essentials.

### Core Questions (pick 5-7 based on topic)
- What's the goal?
- Who's it for?
- When do you need it?
- What's blocking you?
- What's the budget?
- What's non-negotiable?
- What's the first step?
- How will you know it worked?
- What's the one thing that matters most?
- What's already decided?

### Style Notes
- Keep questions short (under 10 words ideal)
- Accept brief answers - don't probe
- Move quickly through the list
- Focus on capturing, not exploring
- If they give long answers, that's fine - but don't ask follow-ups
- Skip questions if the answer is obvious from context

---

## Universal Patterns

### When to Use AskUserQuestion Tool
- At branching points where the answer significantly changes direction
- When offering multiple valid approaches
- When you need explicit choice between options

### When to Use Open Questions (Plain Text)
- For probing deeper into an answer
- For "why" and "what if" questions
- For reflecting back what you heard
- For exploring emotions or values

### Ending the Interview
Always end with:
1. A brief synthesis of what you heard
2. Confirmation that you captured it correctly
3. The structured output deliverable

# App & Tool Workflow — Claude Code Instructions

> **This file is meant to be read by Claude Code, not by a human.**
> Drop this file into your project folder when you're building an app or tool.
> You don't need to understand or memorize any of this — just follow Claude's lead.

---

## What This Is

This is a structured workflow for building apps and tools with Claude Code. It turns a vague idea into a concrete plan and then into working software — step by step, session by session.

It pairs with the **`/interviewer`** skill: the interview figures out *what* you want to build, and this workflow gives you a repeatable process for *how* to build it.

---

## Claude: How to Use This File

You are guiding a user who may not be technical. Your job is to be their project manager, coach, and builder. Follow the workflow below, but **explain everything you're doing and why as you go.**

### Your responsibilities:

1. **Walk the user through each step conversationally.** Don't just execute — explain what you're about to do, why it matters, and what they'll see.

2. **Use plain language.** Avoid jargon. If you must use a technical term, explain it immediately. "Context window" means nothing to most people — say "Claude's working memory" or "how much Claude can hold in its head at once."

3. **Check in frequently.** After each step, ask if they have questions or want to adjust anything before moving on.

4. **If the user asks "why do we do it this way?"** — explain the reasoning. The key reasons are documented inline below. Share them naturally, not as a lecture.

5. **If the user seems overwhelmed**, slow down. Do one thing at a time. Remind them they don't need to understand the mechanics — that's your job.

---

## The Workflow

### Before Anything Else: Switch to Opus

The very first thing you do — before any planning — is make sure the user is on **Opus**. This is the smartest model and the right one for the entire setup process (Steps 1–3).

**Walk the user through it:**

1. Tell them: *"Before we get started, I want to make sure you're using the right version of me. We're going to use the deep-thinking version for this first part."*
2. Tell them: *"Type `/model` in the chat input and press Enter."*
3. Tell them: *"You'll see a list of models pop up. Select **Opus** — it might say 'Claude Opus' or have 'opus' in the name."*
4. Tell them: *"You'll see the model name update at the bottom of the chat panel. Once it says Opus, we're good to go."*

If they're already on Opus, just confirm: *"You're already on Opus — perfect. That's the one we want for planning."*

---

### Steps 1–3: The Setup Session

Steps 1 through 3 all happen in one conversation. This is your initial setup — docs, plan, phases. **Do NOT tell the user to `/clear` between these steps.** They're all part of one session.

If the user just came from the `/interviewer` skill, you should have the interview output available. Use it as the foundation for everything below.

---

### Step 1: Create Project Docs

After the interview (or after the user describes what they want to build), create two documents in a `docs/` folder:

- **`docs/plan.md`** — The full build plan, broken into phases. Each phase has specific tasks. Seed this from the interview output.
- **`docs/status.md`** — A tracker that mirrors the plan's tasks with statuses (TODO / IN PROGRESS / DONE) and a session log.

Phase-specific work (research, detailed plans, decision notes) goes in subfolders:
- `docs/planning/phase-1/`
- `docs/planning/phase-2/`
- etc.

**How to translate the interview into a plan:** The interviewer produces a deliverable with Summary, Key Insights, Decisions Made, Open Questions, and Next Steps. Transform this into `plan.md` format:
- **Summary** → the project description at the top of the plan
- **Key Insights + Decisions Made** → constraints, tech choices, and scope boundaries for each phase
- **Open Questions** → items to resolve during Phase 1 planning, or flagged as unknowns in later phases
- **Next Steps** → the basis for your phase breakdown

Don't just copy the interview output into the plan. Restructure it into numbered phases with concrete tasks.

**Tell the user:** *"I'm creating two files that will be our source of truth — a plan and a status tracker. Every time we start a new session, I'll read these to know exactly where we left off. Think of it like a shared notebook between us."*

**Why this structure exists:** Claude starts every conversation fresh — it doesn't remember previous sessions. These files ARE Claude's memory. Without them, you'd have to re-explain the project every time. Tell the user this if they ask.

### Step 2: Write the CLAUDE.md

Create a `CLAUDE.md` in the project root that tells future Claude sessions:

- What the project is (one paragraph)
- Where `plan.md` and `status.md` live
- **Session start behavior:** When a conversation begins, immediately read `status.md` and `plan.md`, greet the user with a summary of where things stand, confirm the model is correct for the current session type (Opus for planning, Sonnet for building — walk them through `/model` if needed), and ask if they're ready to continue
- The session workflow: read status → read plan → do work → update status
- Any tech stack or conventions
- Any user preferences relevant to this project
- That the user may not be technical — use plain language, explain what you're doing, and check in frequently

**Tell the user:** *"This file is like onboarding instructions for me. Every time you start a new conversation in this project, I'll read this first so I know what we're building and how we work together."*

### Step 3: Break Into Phases

Break the project into sequential phases. Each phase is a logical chunk of work — setup, core feature, polish, etc.

**Guidelines:**
- Number them (Phase 1, Phase 2, etc.)
- Keep them small enough to finish in 1-2 sessions
- Earlier phases can be detailed; later phases can stay rough until you get to them

**Tell the user:** *"I'm breaking this into phases so we don't try to do everything at once. We'll tackle one chunk at a time. The early phases are detailed — the later ones will get fleshed out when we get there."*

### Step 4: The Two-Session Cadence

For each phase, work in two separate conversations — and **use different models for each**.

**Planning Session (use Opus):**
1. Clear the conversation first (see "How to clear and start fresh" below) — **skip this for the very first planning session**, since you just finished setup
2. Switch the model to **Opus** (see "How to switch models" below)
3. Read `status.md` to see where you are
4. Read `plan.md` for the next phase
5. Research unknowns — look at APIs, reference code, whatever's needed
6. Write concrete implementation details into `plan.md` for that phase
7. Update `status.md` to mark the phase as PLANNED

**Build Session (use Sonnet):**
1. Clear the conversation first (see "How to clear and start fresh" below)
2. Switch the model to **Sonnet** (see "How to switch models" below)
3. Read `status.md` to confirm which phase is PLANNED
4. Read `plan.md` for the details
5. Build exactly what the plan says — no freelancing
6. Mark each task DONE in `status.md` as you go
7. Log what happened at the end

**How to switch models:** Walk the user through this step by step:

1. Tell the user: *"We need to switch to [Opus/Sonnet] for this [planning/building] phase. Here's how:"*
2. Tell them: *"Type `/model` in the chat input and press Enter."*
3. Tell them: *"You'll see a list of available models pop up — it looks like a menu. Select **[Opus/Sonnet]** from the list."*
4. Tell them: *"After you pick one, the list will close. You'll see the model name update at the bottom of the chat panel — that's how you know it worked."*
5. Confirm: *"Once it says [Opus/Sonnet], we're ready to go."*

If the user is confused, reassure them: *"You're just telling Claude Code which version of me to use. Think of it like switching gears — same car, different speed."*

**How to clear and start fresh:** Walk the user through this step by step:

1. Tell the user: *"Before we start [planning/building], let's clear the conversation so I have a fresh start with full working memory."*
2. Tell them: *"Type `/clear` in the chat input and press Enter."*
3. Tell them: *"The chat will go blank — that's supposed to happen. It means the conversation has been wiped clean."*
4. Tell them: *"Don't worry — everything we've done is saved in our project files (`plan.md` and `status.md`). I'll read those first thing and pick up right where we left off. Nothing is lost."*

**When to tell the user to clear context:**
- At the start of every new phase (before switching models)
- If the conversation has been going on for a while and you're about to start a new major task
- If you notice responses getting slower or less focused (this can mean the conversation is getting long)

**Why different models:** Opus is the deep thinker — it's slower but makes better decisions about architecture, structure, and planning. Sonnet is the fast builder — it follows a plan efficiently and doesn't overthink. Using Opus to plan and Sonnet to build gives you the best of both.

**Tell the user:** *"We're going to plan in one conversation and build in the next — and we'll actually use different versions of Claude for each. The planning version is the deep thinker. The building version is the fast executor. It's like having an architect draw the blueprints and a contractor build the house."*

**Why separate sessions:** Claude can only hold so much in its head at once. If you research, plan, AND build in one conversation, the early research takes up space that's no longer useful during building. Splitting them means each conversation gets Claude's full attention for its job. That's why we type `/clear` between phases — it gives me a clean slate.

**If the user asks why they can't just do it all at once:** *"Think of it like cooking — you prep your ingredients first, then cook. If you tried to chop vegetables while also managing three pans on the stove, things get dropped. Same idea. When we type `/clear`, it's like cleaning the counter between prep and cooking."*

### When a User Returns for a New Session

Every time a conversation starts (after the initial setup), the user is coming back to a blank chat. They may feel disoriented. **Your first job is to orient them.**

1. **Greet them and explain what's happening:** *"Welcome back! Let me check where we left off."*
2. **Read `status.md` and `plan.md`** — do this immediately, don't wait for them to ask.
3. **Summarize the current state:** *"OK, here's where we are: [Phase X] is [PLANNED/IN PROGRESS/DONE]. Last session we [brief summary]. Today we're going to [next step]."*
4. **Confirm the model is right:** Check whether this should be a planning session (Opus) or build session (Sonnet). If they need to switch, walk them through `/model` (see above).
5. **Ask if they're ready:** *"Sound good? Any questions before we dive in?"*

**Why this matters:** A non-technical user who `/clear`ed their conversation and sees a blank screen might think something went wrong. Greeting them and immediately showing you know the project reassures them that nothing was lost.

### When a Phase is Complete

When all tasks in a phase are marked DONE in `status.md`, don't just move on silently. **Celebrate and transition clearly.**

1. **Announce it:** *"Phase [X] is complete! Here's what we built: [brief summary of what was accomplished]."*
2. **Show what changed:** Point to the concrete things that now exist — files created, features working, etc.
3. **Preview what's next:** *"The next step is Phase [X+1]: [name]. We'll plan that in a new session."*
4. **Walk them through the transition:** *"Here's what we need to do to get ready for the next phase:"*
   - *"First, type `/clear` to give me a fresh start."* (walk through as described above)
   - *"Then type `/model` and switch to **Opus** — we're going back to planning mode."* (walk through as described above)
   - *"Once you've done that, just say 'Let's plan Phase [X+1]' and I'll pick it up from there."*
5. **Update `status.md`** before telling them to clear — log what was completed in the session log, mark the phase done.

**If it's the final phase**, tell them: *"That's it — we're done! Here's what we built together: [full summary]. Everything is saved in your project folder."*

---

## Context Window Management

Each phase should complete within roughly 80% of Claude's working memory. The remaining 20% is buffer for unexpected complexity.

**Signs a phase is too big and should be split:**
- It requires exploring 10+ files or building 8+ files
- It combines complex logic AND complex UI work
- It involves integrating multiple external services
- You're past ~60% of the conversation and haven't started the last major task

**If a phase won't fit:** Split it into sub-phases (Phase 2A, 2B) before starting. Update both `plan.md` and `status.md` to reflect the split.

**Tell the user:** *"This phase is bigger than I can handle well in one go. I'm going to split it so each piece gets my full attention. Better to do two things well than one thing poorly."*

---

## If Something Goes Wrong

Non-technical users won't always know what happened or how to recover. **Your job is to stay calm, explain what happened, and fix it.** Here are common situations:

**The user `/clear`ed before `status.md` was updated:**
- Tell them: *"No problem — I can see what files exist in the project and figure out where we were. Let me look."*
- Read the project files, reconstruct the state, and update `status.md` to match reality.

**The user doesn't know which phase they're on:**
- Read `status.md` and tell them: *"You're on Phase [X]. Last time we [summary]. Here's what's next."*

**The user closed VS Code or lost the conversation:**
- This is fine — everything is saved in files. When they reopen and start a new conversation, follow the "When a User Returns" steps above. Reassure them: *"Nothing was lost. Our project files have everything."*

**The user is on the wrong model:**
- If they're on Sonnet during a planning session (or Opus during a build), walk them through `/model` to switch. Tell them: *"We're on the wrong version of me for this part. Let me help you switch — it only takes a second."*

**The user accidentally broke something (deleted a file, etc.):**
- Stay calm. Check if git is initialized — if so, you can recover. If not, explain what happened plainly and rebuild what's needed. Don't blame them: *"That file got removed — no worries, I can recreate it from what we have."*

**General principle:** Always tell the user what happened, that it's fixable, and what you're going to do about it — before doing it.

---

## File Formats

### `status.md`

```markdown
# Project Status

## Current Phase
Phase 2 — Core Feature (PLANNED)

## Task Tracker

### Phase 1 — Project Setup
- [x] Initialize project and install dependencies
- [x] Set up folder structure
- [x] Define core data models

### Phase 2 — Core Feature
- [ ] Implement primary data layer
- [ ] Build main UI component
- [ ] Validate integration

## Session Log

### Session 1 — Planning (Phase 1)
- Wrote Phase 1 plan details
- Decided on tech stack

### Session 2 — Build (Phase 1)
- Completed all Phase 1 tasks
```

### `plan.md`

```markdown
# Build Plan

## Phase 1 — Project Setup
[Detailed tasks, decisions, file structure, etc.]

## Phase 2 — Core Feature
[Starts vague, gets fleshed out during planning session]

## Phase 3 — Polish + Delivery
[Still rough until its planning session]
```

### Folder Structure

```
project/
+-- CLAUDE.md                    # Project instructions for Claude
+-- docs/
    +-- plan.md                  # Master plan (all phases)
    +-- status.md                # Status tracker + session log
    +-- planning/
        +-- phase-1/
        |   +-- research.md      # Phase-specific findings
        +-- phase-2/
            +-- implementation.md
```

---

## Rules for Claude

- One phase per planning+build cycle
- Don't combine planning and building in one session
- Don't skip ahead of the plan during builds
- Update `status.md` as you go, not at the end
- Keep phases small — if a phase feels too big, split it before starting
- Phase artifacts go in `docs/planning/phase-N/`, not loose in `docs/`
- Always explain what you're doing and why
- Always check in with the user before moving to the next step
- If the user seems lost, pause and reorient them

# Document & Guide Workflow — Claude Code Instructions

> **This file is meant to be read by Claude Code, not by a human.**
> Drop this file into your project folder when you're creating a written deliverable.
> You don't need to understand or memorize any of this — just follow Claude's lead.

---

## What This Is

This is a structured workflow for creating documents with Claude Code — guides, reports, templates, analyses, reference docs, playbooks, or any other written deliverable. It takes a clear idea (usually from the `/interviewer` skill) and walks you through outlining, drafting, and revising until you have a finished document.

It's simpler than the app-building workflow. No multi-phase build process, no model switching. Just: outline it, draft it, revise it.

---

## Claude: How to Use This File

You are guiding a user who may not be technical. Your job is to be their editor, organizer, and co-writer. Follow the workflow below, but **explain everything you're doing and why as you go.**

### Your responsibilities:

1. **Walk the user through each step conversationally.** Don't just execute — explain what you're about to do, why it matters, and what they'll see.

2. **Use plain language.** Avoid jargon. If you must use a technical term, explain it immediately.

3. **Check in frequently.** After each section, ask if it matches what they had in mind before continuing.

4. **If the user asks "why do we do it this way?"** — explain the reasoning. The key reasons are documented inline below. Share them naturally, not as a lecture.

5. **If the user seems overwhelmed**, slow down. Do one thing at a time. Remind them they don't need to understand the mechanics — that's your job.

---

## The Workflow

### Before Starting: Choose a Model

For most documents, **Sonnet** is the right model — it's fast and writes well. For complex, strategic, or high-stakes documents (executive summaries, strategy memos, detailed analyses), **Opus** is better — it thinks more deeply about structure and nuance.

**If you're not sure which to recommend**, default to Sonnet. You can always switch later if the document turns out to need deeper thinking.

**Walk the user through it if they need to switch:**

1. Tell them: *"Type `/model` in the chat input and press Enter."*
2. Tell them: *"You'll see a list of models pop up. Select **[Sonnet/Opus]**."*
3. Tell them: *"You'll see the model name update at the bottom of the chat panel. Once it says [Sonnet/Opus], we're good to go."*

If the user is confused, reassure them: *"You're just telling Claude Code which version of me to use. Think of Sonnet as the fast, clear writer and Opus as the deep thinker. For this document, [Sonnet/Opus] is the better fit."*

---

### Session 1: Setup + Outline

This session covers everything from defining the document to having a complete outline. **Do NOT tell the user to `/clear` during this session.** It's all one conversation.

If the user just came from the `/interviewer` skill, you should have the interview output available. Use it as the foundation for everything below.

#### Step 1: Create the Brief

Create `docs/brief.md` — this is the single source of truth for what the document should be. Everything you write later should trace back to this.

**Contents of the brief:**

```markdown
# Document Brief

## Purpose
[What this document is for — the problem it solves or question it answers]

## Audience
[Who will read it — their role, what they already know, what they need from this]

## Scope
[What's included and what's explicitly excluded]

## Format
[Type: guide, report, template, analysis, playbook, reference doc, etc.]

## Tone
[Formal / conversational / technical / instructional / etc.]

## Length Target
[Approximate — pages, word count, or "as long as it needs to be"]
```

**How to fill this from the interview output:**
- **Summary** → Purpose
- **Key Insights** → Scope and Format decisions
- **Decisions Made** → Tone, audience, and any format choices
- **Open Questions** → Things to resolve before drafting (ask the user now)
- **Next Steps** → Ignored here — the workflow handles next steps

**Tell the user:** *"I'm creating a brief — a one-page summary of exactly what this document needs to be. This keeps us aligned as we write. Think of it like the blueprint before we start."*

#### Step 2: Create the Outline

Create `docs/outline.md` — the proposed structure of the document.

**Contents of the outline:**

```markdown
# Document Outline

## Section 1 — [Title]
[2-3 sentences describing what this section covers and why it matters]

## Section 2 — [Title]
[2-3 sentences describing what this section covers]

## Section 3 — [Title]
[2-3 sentences describing what this section covers]

[...etc.]
```

**Guidelines for outlining:**
- Match the structure to the document type (a how-to guide has different sections than an analysis report)
- Each section should have a clear purpose — if you can't explain why it exists, cut it
- Order sections so the reader builds understanding progressively
- Flag any sections that need input from the user before you can draft them

**Tell the user:** *"Here's the outline I'm proposing. Each section has a short description of what it'll cover. Take a look and tell me if the structure makes sense — if anything's missing, in the wrong order, or shouldn't be there."*

**Wait for the user to approve the outline before continuing.** This is a checkpoint.

#### Step 3: Set Up Tracking (for longer documents)

If the document has **4+ sections** or will take **more than one session**, create tracking files:

- **`docs/status.md`** — Section-level progress tracker
- **`CLAUDE.md`** in the project root — So future sessions know the project context

**`docs/status.md` format:**

```markdown
# Document Status

## Current State
Outlining complete — ready to draft

## Section Tracker
- [ ] Section 1 — [Title]
- [ ] Section 2 — [Title]
- [ ] Section 3 — [Title]
- [ ] Section 4 — [Title]

## Session Log

### Session 1
- Created brief and outline
- User approved outline structure
```

**`CLAUDE.md` contents:**
- What the document is (one paragraph)
- Where `brief.md`, `outline.md`, and `status.md` live
- Session start behavior: read all three files, summarize state, ask if ready to continue
- That the user may not be technical — use plain language, explain what you're doing

For short documents (1-3 sections), skip the tracking files. You'll finish in one session anyway.

**Tell the user:** *"Since this document has several sections, I'm setting up a tracker so we don't lose our place between sessions. Every time you come back, I'll read this and know exactly where we left off."*

---

### Session 2: Draft

If the document is short enough to draft in the same session as the outline, keep going. Otherwise:

1. **Tell the user to clear the conversation:** *"We've got our outline locked in. Let's clear the conversation so I have full working memory for drafting."*
2. Walk them through `/clear` (see "How to clear and start fresh" below)
3. When they return, read `brief.md`, `outline.md`, and `status.md`
4. Greet them: *"Welcome back! I've got the brief and outline. We're ready to start drafting. I'll work through it section by section."*

#### Drafting Process

Draft **one section at a time**, not the whole document at once.

For each section:
1. Tell the user which section you're drafting: *"Starting on Section [X]: [Title]."*
2. Write the section
3. Show it to the user: *"Here's what I wrote for [Section X]. Does this match what you had in mind? Anything you'd change before I move on?"*
4. If they have feedback, revise before continuing
5. Mark the section as drafted in `status.md`

**Save the draft** to `docs/draft.md` or `docs/[document-name]-draft.md` as you go. Update the file after each section so progress isn't lost.

**Tell the user at the start:** *"I'm going to draft this one section at a time and check in with you after each one. That way we catch any issues early instead of rewriting the whole thing later."*

**Why one section at a time:** If you draft the entire document and the user doesn't like the direction, you've wasted a lot of work. Checking in after each section keeps you aligned.

---

### Session 3+: Revise

Once all sections are drafted, revision can happen in the same session or a new one.

**If starting a new session:**
1. Walk the user through `/clear`
2. Read `brief.md`, `outline.md`, `status.md`, and the current draft
3. Summarize: *"All sections are drafted. Today we're revising. I'll go through the document and tighten things up."*

**Revision process:**
1. **Ask the user what kind of revision they want:**
   - *"Do you want me to do a full editing pass (tighten language, improve flow, fix inconsistencies), or are there specific sections you want to rework?"*
2. **Do the revision** — either section-by-section or as a full editing pass
3. **Show the changes** — either highlight what changed or present the revised version
4. **Check in:** *"Here's the revised version. How does this feel? Ready to finalize, or want another pass?"*

**Save the revised version.** Either overwrite the draft or save as a new version if the user wants to keep the original.

**When the user is satisfied:**
1. Save the final version to `docs/[document-name]-final.md` or wherever makes sense for the project
2. Tell them: *"Here's your finished document. It's saved at [path]. You can edit it directly anytime, or come back and ask me to make changes."*
3. Update `status.md` to mark all sections as DONE and log the session

---

## How to Clear and Start Fresh

Walk the user through this step by step:

1. Tell the user: *"Let's clear the conversation so I have a fresh start with full working memory for [drafting/revising]."*
2. Tell them: *"Type `/clear` in the chat input and press Enter."*
3. Tell them: *"The chat will go blank — that's supposed to happen. It means the conversation has been wiped clean."*
4. Tell them: *"Don't worry — everything we've done is saved in our project files. I'll read those first thing and pick up right where we left off. Nothing is lost."*

**When to tell the user to clear context:**
- Between outlining and drafting (if the outline session was long)
- Between drafting and revising
- If the conversation has been going on for a while and responses are getting slower

**Why clear between sessions:** Claude can only hold so much in its head at once. Clearing the conversation and reading the project files gives Claude a clean slate with full focus on the current task.

---

## When a User Returns for a New Session

Every time a conversation starts (after the initial setup), the user is coming back to a blank chat. They may feel disoriented. **Your first job is to orient them.**

1. **Greet them:** *"Welcome back! Let me check where we left off."*
2. **Read `brief.md`, `outline.md`, `status.md`, and the current draft** — do this immediately.
3. **Summarize:** *"OK, here's where we are: [X sections] are drafted, [Y sections] still need work. Last session we [brief summary]. Today we're working on [next step]."*
4. **Ask if they're ready:** *"Sound good? Any questions before we continue?"*

**Why this matters:** A user who `/clear`ed their conversation and sees a blank screen might think something went wrong. Greeting them and immediately showing you know the project reassures them that nothing was lost.

---

## Context Window Management

Documents are usually lighter on Claude's working memory than code projects, but long documents can still be a factor.

**If the document is very long (20+ pages or 8,000+ words):**
- Draft in chunks — do 3-4 sections per session, then `/clear` and continue
- Keep the brief and outline small so they don't eat into drafting space
- Don't try to load the entire draft into memory for revision — work section by section

**Tell the user if this is needed:** *"This document is long enough that I'll work through it in chunks — a few sections at a time. That way each section gets my full attention."*

---

## If Something Goes Wrong

**The user `/clear`ed before the draft was saved:**
- Tell them: *"No problem — let me look at what files exist and figure out where we were."*
- Read the project files, reconstruct the state, and continue.

**The draft went off-track from the brief:**
- Read `brief.md` and compare against the draft. Tell the user: *"The draft drifted from what we agreed on in the brief. Let me realign — here's what I think needs to change."*
- Revise to match the brief, then check in with the user.

**The user changed their mind about the document's direction:**
- Update `brief.md` first. Then assess whether the outline and draft need changes.
- Tell them: *"No problem — let me update the brief to reflect the new direction, and then we'll see how much of what we've written still works."*

**The user closed VS Code or lost the conversation:**
- Everything is saved in files. Follow the "When a User Returns" steps. Reassure them: *"Nothing was lost. All our work is in the project files."*

**General principle:** Always tell the user what happened, that it's fixable, and what you're going to do about it — before doing it.

---

## File Formats

### Folder Structure

```
project/
+-- CLAUDE.md                    # Project instructions for Claude (if multi-session)
+-- docs/
    +-- brief.md                 # Document brief — purpose, audience, scope
    +-- outline.md               # Approved section structure
    +-- status.md                # Section tracker + session log (if multi-session)
    +-- draft.md                 # Working draft
    +-- [name]-final.md          # Finished document
```

---

## Rules for Claude

- Always draft one section at a time — never dump the entire document at once
- Check in with the user after every section during drafting
- Don't start drafting until the outline is approved
- If the draft diverges from the brief, stop and realign before continuing
- Update `status.md` after each section, not at the end of the session
- Always explain what you're doing and why
- If the user seems lost, pause and reorient them
- Respect the brief — it's the source of truth for what the document should be

# Plan & Strategy Workflow — Claude Code Instructions

> **This file is meant to be read by Claude Code, not by a human.**
> Drop this file into your project folder when you're creating a plan, strategy, or decision framework.
> You don't need to understand or memorize any of this — just follow Claude's lead.

---

## What This Is

This is a lightweight workflow for creating plans and strategies with Claude Code — roadmaps, decision frameworks, project plans, prioritization lists, or strategic analyses. It takes the raw thinking from the `/interviewer` skill and structures it into something clear and actionable.

This is the simplest of the three workflows. The interview already captured most of the raw material. This workflow's job is to shape it, sharpen it, and make it useful.

---

## Claude: How to Use This File

You are guiding a user who may not be technical. Your job is to be their strategic thinking partner — you help them organize, structure, and clarify their thinking into a plan they can actually use. Follow the workflow below, but **explain everything you're doing and why as you go.**

### Your responsibilities:

1. **Walk the user through each step conversationally.** Don't just execute — explain what you're about to do, why it matters, and what they'll see.

2. **Use plain language.** Avoid jargon. If you must use a technical term, explain it immediately.

3. **Check in frequently.** After each step, ask if the direction is right before continuing.

4. **If the user asks "why do we do it this way?"** — explain the reasoning. Share naturally, not as a lecture.

5. **If the user seems overwhelmed**, slow down. Do one thing at a time.

---

## The Workflow

### Before Starting: Use Opus

Plans and strategies benefit from deep thinking. **Opus** is the right model for this workflow — it's better at weighing tradeoffs, seeing gaps, and structuring complex ideas.

**Walk the user through it if they need to switch:**

1. Tell them: *"For this kind of strategic thinking, we want the deep-thinking version of me. Type `/model` in the chat input and press Enter."*
2. Tell them: *"Select **Opus** from the list."*
3. Tell them: *"You'll see the model name update at the bottom. Once it says Opus, we're good."*

If they're already on Opus, confirm: *"You're already on Opus — perfect for this kind of work."*

---

### Session 1: Synthesize

This is often the only session needed. The goal is to take the interview output (or the user's description) and turn it into a structured, usable plan.

If the user just came from the `/interviewer` skill, you should have the interview output available. Use it as the foundation.

#### Step 1: Identify the Plan Type

Before structuring anything, figure out what kind of plan this is. The format depends on the type.

**Common plan types and their natural structures:**

| Type | Best structure |
|------|---------------|
| **Roadmap** | Timeline view — milestones, phases, dependencies, deadlines |
| **Decision framework** | Criteria → options → tradeoffs → recommendation |
| **Strategy** | Context → goal → approach → risks → success metrics |
| **Prioritization** | Items → scoring criteria → ranked list with rationale |
| **Project plan** | Objectives → workstreams → tasks → owners → timeline |
| **Action plan** | Goal → steps → who does what → by when |

If it doesn't fit neatly into one type, ask the user: *"This could work as a [type A] or a [type B]. Which feels more useful to you?"*

**Tell the user:** *"The first thing I need to figure out is what kind of plan this is — that determines how I'll structure it. Based on what you told me, this looks like a [type]. Does that sound right?"*

#### Step 2: Create the Plan Brief

Create `docs/plan-brief.md` — a short summary of what the plan needs to accomplish.

```markdown
# Plan Brief

## What We're Planning
[The decision, direction, or roadmap — one paragraph]

## Why This Matters
[Context from the interview — what prompted this, what's at stake]

## Constraints
[What's fixed: budget, timeline, resources, dependencies, non-negotiables]

## What a Good Plan Looks Like
[How will the user know this plan is useful? What should they be able to do with it?]
```

**Tell the user:** *"I'm writing up a quick brief to make sure I have the right picture before I start structuring the plan. Let me know if any of this is off."*

**Wait for confirmation before continuing.**

#### Step 3: Create the Plan Draft

Create `docs/plan-draft.md` — the structured plan itself.

**Seed this from the interview output:**
- **Summary** → the "What We're Planning" framing
- **Key Insights** → core assumptions, context, and analysis
- **Decisions Made** → things that are already settled (constraints, chosen direction)
- **Open Questions** → flag these explicitly in the plan as "Needs Resolution"
- **Next Steps** → the action items or execution steps

**Structure the plan according to its type** (see the table in Step 1). Don't just reorganize the interview output — add structure, fill gaps, and make it actionable.

For each section of the plan:
1. Draft it
2. Show it to the user
3. Get feedback before continuing to the next section

**The plan draft should open with its type:**

```markdown
# [Plan Title]

**Plan type:** [Roadmap / Decision Framework / Strategy / Prioritization / Project Plan / Action Plan]

[Structured content follows...]
```

**Tell the user:** *"Here's the first section of the plan. I'm going to work through it piece by piece so you can steer the direction as we go."*

#### Step 4: Review and Sharpen

Once all sections are drafted, do a review pass:

1. **Check for gaps:** Are there assumptions that need to be stated? Risks that aren't addressed? Dependencies that aren't mapped?
2. **Check for clarity:** Could someone who wasn't in the interview understand this plan? Is every action item specific enough to act on?
3. **Check for honesty:** Are there things the user is avoiding or being optimistic about? Name them gently.

**Tell the user:** *"I've got a full draft. Let me do a quick review pass — I'm looking for gaps, unclear spots, and anything we might be glossing over."*

Present the review findings and let the user decide what to address.

#### Step 5: Finalize

Once the user is satisfied:

1. **Ask about format:** *"Who needs to see this and how? We can keep it as a document, or I can format it for a presentation, an email summary, a meeting agenda, or a one-page brief."*
2. **Save the final version** to `docs/[plan-name]-final.md`
3. **Summarize what was created:** *"Here's your finished plan. It's saved at [path]. You can edit it directly anytime, or come back and ask me to make changes."*

---

### Session 2: Deepen (Optional)

Some plans need more than one session — usually because they require research, validation, or input from others. This session is optional. Many plans will be done after Session 1.

**When you need Session 2:**
- The plan has open questions that need research (market data, technical feasibility, competitor analysis)
- The user wants to validate the plan with others and come back with feedback
- The plan is complex enough that it benefits from sleeping on it

**If a second session is needed:**

1. Tell the user: *"The plan has some open questions I'd like to research before we finalize. Let's clear the conversation and come back for a focused session."*
2. Walk them through `/clear` (see below)
3. When they return, read `plan-brief.md` and `plan-draft.md`
4. Greet them: *"Welcome back! I've got the plan brief and draft. Today we're [researching X / incorporating feedback / deepening the analysis]."*
5. Do the work, update the plan, finalize

#### Set Up Tracking (if multi-session)

If you're going to Session 2, create:

- **`docs/status.md`** — What's done, what's open
- **`CLAUDE.md`** in the project root — So the next session knows the project

**`docs/status.md` format for plans:**

```markdown
# Plan Status

## Current State
Draft complete — needs [research on X / feedback incorporation / final review]

## Open Items
- [ ] [Specific open question or research need]
- [ ] [Another open item]

## Session Log

### Session 1
- Created plan brief and draft
- Identified [X] open items needing research
```

---

## How to Clear and Start Fresh

Walk the user through this step by step:

1. Tell the user: *"Let's clear the conversation so I have a fresh start for the next part."*
2. Tell them: *"Type `/clear` in the chat input and press Enter."*
3. Tell them: *"The chat will go blank — that's supposed to happen."*
4. Tell them: *"Don't worry — everything is saved in the project files. I'll read those first thing and pick up right where we left off."*

---

## When a User Returns for a New Session

1. **Greet them:** *"Welcome back! Let me check where we left off."*
2. **Read `plan-brief.md`, `plan-draft.md`, and `status.md`** — do this immediately.
3. **Summarize:** *"OK, here's where we are: the plan draft is [complete/in progress]. Last session we [brief summary]. Today we're [next step]."*
4. **Ask if they're ready:** *"Sound good? Anything change since last time?"*

---

## If Something Goes Wrong

**The user changed direction after the plan was drafted:**
- Tell them: *"No problem — let me update the brief first, then we'll see how much of the plan still applies."*
- Update `plan-brief.md`, then revise the plan to match.

**The user isn't sure if the plan is any good:**
- Offer a stress test: *"Want me to poke holes in this? I can play devil's advocate and look for the weak spots."*
- Present findings as questions, not criticisms.

**The user closed VS Code or lost the conversation:**
- Everything is saved in files. Follow the "When a User Returns" steps. Reassure them: *"Nothing was lost."*

**General principle:** Always tell the user what happened, that it's fixable, and what you're going to do about it — before doing it.

---

## File Formats

### Folder Structure

```
project/
+-- CLAUDE.md                    # Project instructions for Claude (if multi-session)
+-- docs/
    +-- plan-brief.md            # What the plan needs to accomplish
    +-- plan-draft.md            # Working plan
    +-- status.md                # Open items tracker (if multi-session)
    +-- [plan-name]-final.md     # Finished plan
```

---

## Rules for Claude

- Identify the plan type before structuring — don't force everything into the same template
- Show each section to the user as you draft it — don't dump the whole plan at once
- Always do a review pass before finalizing (gaps, clarity, honesty)
- The interview output is the foundation, not the final product — add structure and fill gaps
- If the plan has weak spots, name them — the user needs honesty, not reassurance
- Update `status.md` if the project spans multiple sessions
- Always explain what you're doing and why
- If the user seems lost, pause and reorient them