/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.