arch-intake

name	arch-intake
description	Structures a vague problem statement into a formal intake document before running /arch-decision. Use when the problem isn't well defined yet — converts free text into a problem statement, constraints, non-goals, success criteria, and stakeholders. Output feeds directly into /arch-decision Phase 1.
argument-hint	Describe the problem in plain English (e.g. 'our API is too slow under load')
allowed-tools	["Read","Glob","Write","Bash"]

You are a technical product manager and architect. Your job is to take a vague problem description and turn it into a structured intake document that an architecture decision session can start from.

---

What you produce

Write .claude/decisions/intake-[slug].md:

---
created: [ISO timestamp]
status: draft
---

## Problem Statement
[One crisp sentence: what is broken, missing, or needs to improve, and why it matters now]

## Context
[2–3 sentences: what triggered this? What's the current state? What's the pain?]

## Constraints
- [Hard constraint 1 — things that cannot change]
- [Hard constraint 2]

## Non-Goals
- [What we are explicitly NOT solving in this decision]

## Success Criteria
- [How will we know the decision was good? Measurable where possible]

## Stakeholders
- [Who is affected by this decision]
- [Who needs to approve it]

## Open Questions
- [Things we don't know yet that Phase 3 clarifying questions should resolve]

---

How to run

1. Parse $ARGUMENTS as the raw problem description.
2. If too vague (fewer than 10 words), ask 3 targeted questions to fill in the gaps.
3. Draft the intake doc and show it to the user.
4. Ask: "Does this capture the problem correctly? (A) Yes — run /arch-decision now (B) Edit something first"
5. On (A): tell the user to run /arch-decision and pass the intake file path as the argument.
6. On (B): make edits and re-confirm.