bart-think

name	bart-think
description	Use when the user wants to think through a problem before planning. Invoke when the user says "let me think about this", "help me think through", "I need to figure out", "what should I build", "explore this idea", or runs /bart-think. This skill guides structured problem exploration, captures decisions, and writes a bart-format plan directly — no conversion step needed.
version	2.0.0

Bart Think — Guided Problem Exploration

You guide users through structured thinking before planning. Unlike bart-plan (which converts existing plans), you help users discover what to build through conversation, then write a bart-format plan directly.

Tool Restrictions

CRITICAL: During Phases 1–4, you MUST NOT use Edit, Write, or Bash tools. You are in conversation mode only. The system will block these tool calls, but you should not attempt them. Only use file-writing tools in Phase 5 to write the plan file.

Read-only tools (Read, Glob, Grep) are allowed at any phase for research.

Input

Topic: $ARGUMENTS

If a topic is provided, start with that context. Otherwise, begin with open-ended discovery.

Workflow

Phase 1: Open-Ended Discovery

Start by understanding what the user wants to build or solve. Ask one clear, open-ended question:

• If topic provided: "You want to work on [topic]. Tell me more — what's the current state and what outcome are you after?"
• If no topic: "What are you building or trying to solve? Give me the context."

React to their answer. Don't use a generic checklist. Pick up on what they said and ask follow-up questions that demonstrate you understood their specific problem. 2-3 rounds of back-and-forth is typical before moving to Phase 2.

Phase 2: Gray Area Identification

Once you understand the problem, surface 2-5 domain-specific ambiguities — things that could go either way and would affect the plan. These should NOT be generic categories like "error handling" or "testing strategy". They should be specific to THIS problem.

Present as a numbered list:

Based on what you've described, I see these gray areas we should resolve:

1. [Specific ambiguity about their problem]
2. [Another specific ambiguity]
3. [A third one if needed]

Which of these do you want to discuss? (or add others I missed)

Let the user pick which areas matter. Skip ones they say are obvious.

Phase 3: Deep-Dive Each Area

For each selected gray area, ask 3-4 concrete choice questions — not open-ended, but framed as options:

For [gray area]:
- Option A: [concrete approach] — [tradeoff]
- Option B: [concrete approach] — [tradeoff]

Which fits your situation better?

Testing gray area: If the testing approach hasn't been discussed by the end of Phase 3, surface it as an additional gray area: "How should tests be structured for this project?" Offer concrete options based on what you can infer from the codebase (existing test framework, test locations, naming patterns). This ensures the ## Testing section in the plan is grounded in user decisions, not guesswork.

After each area, classify the decision:

• Locked: User made a clear choice — this is a constraint
• Discretionary: User said "you decide" or "whatever works" — Claude has freedom
• Deferred: User said "not now" or "later" — explicitly excluded from scope

Phase 4: Scope Guardrail

Before writing the plan, summarize the total scope:

Here's what we're building:

**In scope:**
- [thing 1]
- [thing 2]
- [thing 3]

**Explicitly deferred:**
- [thing user said "not now" to]

**Decisions:**
- [locked decision 1]
- [locked decision 2]
- [discretionary items Claude will decide]

Does this look right? Anything to add or remove?

If the user tries to expand scope significantly, push back: "That sounds like a separate effort. Let's finish this first and tackle that next."

Phase 5: Write Plan

Once scope is confirmed, write a single plan file that combines decisions, requirements, and workstream tasks.

Before writing the plan, discover the project's test setup by examining package.json, existing test files, CI config, or any test configuration files. Use read-only tools (Read, Glob, Grep) to find:

• Test command — look in package.json scripts (test, test:unit, etc.), Makefile, or CI config
• Test framework — identify from dependencies (vitest, jest, pytest, go test, etc.)
• Conventions — check where existing tests live, naming patterns (e.g., *.test.ts, *_test.go)

Use this information to populate the ## Testing section in the plan output.

Then, discover available specialists:

bart specialists --history 2>/dev/null || echo "No specialists found"

Propose specialist assignments for each task (same process as bart-plan Step 3c — present a table and ask for confirmation before writing).

Output: .bart/plans/<YYYY-MM-DD>-<slug>/plan.md

Write directly in bart format — this is the key advantage over bart-plan. No conversion needed.

# Plan: [Title]

## Decisions

### Locked
- [Decision]: [Choice made] — [rationale]

### Discretionary
- [Area]: Claude decides — [any guidance user gave]

### Deferred
- [Thing]: Not in scope for this effort

## Requirements
- [REQ-01] [Requirement derived from locked decisions and scope]
- [REQ-02] [Another requirement]

## Testing
Test command: [discovered from repo or discussed during thinking]
Framework: [discovered or discussed]
Conventions: [discovered from repo or discussed]

## [Section Name]
### [Task title] [REQ-XX]
[Description based on decisions made during thinking]

**Test first:**
- Create `tests/path/to/test.ts`
- Test: [description of what the test verifies]
```typescript
// Complete test code here

• Run: [test command] -- tests/path/to/test.ts
• Expected: FAIL (function not defined / behavior not implemented)

Implementation:

• Modify path/to/file.ts
• [Description of implementation steps]

Verify:

• Run: [test command] -- tests/path/to/test.ts
• Expected: PASS

Files: path/to/file.ts, tests/path/to/test.ts

[specialist-name] [Task title] [REQ-XX]

[Description with specialist tag if applicable]

Test first:

• Create tests/path/to/other.test.ts
• Test: [description of what the test verifies]

// Complete test code here

• Run: [test command] -- tests/path/to/other.test.ts
• Expected: FAIL

Implementation:

• Modify path/to/other-file.ts
• [Description of implementation steps]

Verify:

• Run: [test command] -- tests/path/to/other.test.ts
• Expected: PASS

Files: path/to/other-file.ts, tests/path/to/other.test.ts

The `## Decisions` section must appear before `## Requirements`. The `## Testing` section must appear between `## Requirements` and the first workstream section. The bart plan parser skips `## Decisions`, `## Requirements`, and `## Testing` when calculating workstream boundaries — they are metadata, not workstreams.

### Phase 6: Auto-Invoke Review

After writing the plan file, **do NOT signal completion**. Instead, immediately invoke the `bart-think-review` skill to review the plan output:

Plan written to .bart/plans//plan.md

Invoking bart-think-review to validate the plan before proceeding...

Then invoke the skill:

/bart-think-review .bart/plans//plan.md

This auto-chains into the review phase — the user does not need to manually trigger it.

## Key Principles

1. **React, don't interrogate** — Each question should build on the user's last answer, not follow a script
2. **Domain-specific, not generic** — Gray areas should be unique to THIS problem, not reusable templates
3. **Concrete choices, not open questions** — "Option A or B?" beats "What do you think about X?"
4. **Scope is sacred** — Once confirmed, defend it. New ideas go to "deferred"
5. **Write bart format directly** — No intermediate steps, no conversion needed
6. **Specialist-aware** — Discover and assign specialists before writing the plan
7. **No tools during conversation** — Phases 1–4 are conversation only. No Edit, Write, or Bash calls
8. **Single output file** — Decisions live inside plan.md, not in a separate CONTEXT.md