# INTENT.md

> An intent spec turns product judgment under evidence into something an AI coding
> agent can execute without guessing, then verify against the real user problem.
> Fill in every section. If an agent would still need to ask a clarifying question,
> the spec isn't done yet.
>
> Template by Pathmode. https://pathmode.io/intent-engineering

---

## 1. Objective
<!-- The user problem and why it matters. Ground it in evidence, not opinion.
     Not "we think users want X" but "we observed users struggling with Y, and it costs Z." -->

## 2. Outcomes
<!-- Observable, measurable state changes. Each one verifiable by a test or a metric.
     Not "improve performance" but "p95 response time under 200ms". -->
- 
- 

## 3. Evidence
<!-- Linked real user signals: support tickets, quotes, drop-off metrics, observations,
     feature requests. If you can't point to evidence, reconsider whether to build this. -->
- 
- 

## 4. Constraints
<!-- Hard boundaries the implementation must respect: security, architecture, business
     rules. What the agent must NOT do. -->
- 
- 

## 5. Scope
<!-- What the implementation may touch, and what it must leave alone. The "out of scope"
     fence stops an agent from refactoring code you never asked it to change. -->
**In scope:**
- 

**Out of scope:**
- 

## 6. Edge Cases
<!-- Boundary conditions and failure modes. Network down? Empty state? 10,000 items
     instead of 10? Unsupported input? -->
- 
- 

## 7. Health Metrics
<!-- What must NOT regress once this ships. Outcomes say what should change; health
     metrics name what should stay true. -->
- 
- 

## 8. Verification
<!-- How you confirm it works: unit tests, integration tests, manual checks, the
     observable signal in production. This closes the loop: the agent knows what
     "done" looks like and can check its own work. -->
- 

---

<!-- Hand this file to Claude Code, Cursor, Codex, or any agentic workflow.
     Learn the method: https://pathmode.io/intent-engineering -->